Template to create a type and instantiate it

2016-02-04 Thread cy via Digitalmars-d-learn
I'm guessing I have to use a "mixin" mixin for this, but... 
there's no way to do something like this is there?


template TFoo(T) {

struct T {
  int a;
  int b;
}

T obj;
}

TFoo!Derp;
Derp bar;

Neither templates, nor mixin templates seem capable of this. Easy 
enough to use mixin, with tokenized string literal format, I 
think. I just hesitate to make opaque string evaluation a thing 
if some more meaningful method exists.


Re: Template to create a type and instantiate it

2016-02-04 Thread Rikki Cattermole via Digitalmars-d-learn

On 05/02/16 8:41 PM, cy wrote:

I'm guessing I have to use a "mixin" mixin for this, but... there's no
way to do something like this is there?

template TFoo(T) {

struct T {
   int a;
   int b;
}

T obj;
}

TFoo!Derp;
Derp bar;

Neither templates, nor mixin templates seem capable of this. Easy enough
to use mixin, with tokenized string literal format, I think. I just
hesitate to make opaque string evaluation a thing if some more
meaningful method exists.


That code is completely wrong anyway.
But you could do:

alias Derp = TFoo;
Derp obj;

struct TFoo {
int a, b;
}

Of course you can make TFoo a template so that alias could initiate it 
with your arguments.


Re: Detecting exception unwinding

2016-02-04 Thread cy via Digitalmars-d-learn
On Wednesday, 3 February 2016 at 11:09:00 UTC, Ola Fosheim 
Grøstad wrote:
Is there some reliable way to detect that a destructor is 
called because of exception unwinding?


I basically want to change behaviour within a destructor based 
on whether the destructor is called as a result of a regular or 
an exceptional situation.


E.g. commit changes to a database on regular destruction, or 
inhibit logging during exception unwinding.


I think you might be talking about two very different concepts 
here. Unwinding only happens within the context of a certain 
scope. That's where it gets the backtrace from. If you construct 
an object, then save it somewhere globally, then return from the 
function, then go back into the event loop, then whatever... you 
no longer have your original scope. There can be no exceptional 
situation, nor can there be "regular destruction" because the 
scope has already unwound. Saving your object globally keeps it 
from being destructed, and you might use reference counting in 
that case I guess, but ultimately, when an exception occurs, your 
object will have nothing to do with it at all.


That might be your situation, in which case you simply do this:

bool fail = false;
...
class Foo {
...
  ~this() {
if(!fail) writeln(shakespeare);
...
  }
...
}

int main() {
  scope(failure) fail = true;
  ...
}

When your program exits due to an uncaught exception, it can't 
unwind higher than main, so "scope(failure)" for main will apply 
to all uncaught exceptions that kill the program.  Any globally 
stored variables destructed after that will see fail as being 
true.


The other situation is easier, and probably what you're trying to 
do, so sorry for wasting your time. If you have a local variable 
in a local scope, then when you leave that scope normally, the 
variable will be destroyed, as well as when you fail out of it. 
You want to find out whether you are leaving that scope normally 
in the destructor, and it's not anything about whether the 
program is dying or not, but instead it's making sure your local 
objects with global state clean up before they die.


If that's what you're doing then you do this:

void some_routine() {
  ...
  Foo foo;
  scope(failure) foo.fail = true;
  ...proceed normally...
}

When some_routine exits normally, foo has not set fail, and it 
will be destroyed knowing that. When some_routine errors out, 
"scope(failure)" will set the fail on foo, and then when foo is 
destroyed it can do so quietly.


But again, two different situations. If you try to do this:

Foo foo;
void some_routine() {
  scope(failure) foo.fail = true;
  ...no exceptions...
}
void failure_routine() {
  ...
  throw new SomeException();
  ...
}

int main() {
  some_routine();
  failure_routine();
}

...then fail will never be set, since you exited some_routine 
before throwing any exceptions. Thus why you set "scope(failure)" 
on the main function, if you're concerned about globals being 
destructed due to program failure. You set "scope(failure)" on 
the local function when you're concerned about locals complaining 
as they destruct when the function returns from an exceptional 
situation. If you want the former and do the latter, then your 
globals will not see that any exception occurred. If you want the 
latter and do the former, then any local variables will destruct 
long before main reaches "scope(failure)"


YMMV. I haven't tested any of this, and I'm kind of shaky at D 
too.


Re: print function

2016-02-04 Thread cy via Digitalmars-d-learn

On Thursday, 4 February 2016 at 15:32:48 UTC, Artur Skawina wrote:

   void print(A...)(A a) {
  foreach (N, ref e; a)
 write(e, N==A.length-1?"\n":" ");
   }



will be unrolled at compile time


Mind if I elaborate on this a bit? If that is unrolled, I 
understand it will unroll into several calls to write, as in 
print("1","2","3") => write("1"," ");write("2"," 
");write("3","\n");


And presumably, write() unrolls its arguments too. Each string 
argument to write() unrolls to a put(). And put("abc") unrolls 
into put("a");put("b");put("c"), each of which that call the C 
routine fwrite with a length 1.


So the above print, if you did print("hi","there") it would become
write("hi"," "); write("there","\n")
which would become
put("hi");put(" ");put("there");put("\n");
which would become
put("h");put("i");put(" 
");put("t");put("h");put("e");put("r");put("e");put("\n");


And then it compiles.

Any literal string you pass to std.stdio.write will be expanded 
into 1 fwrite invocation per character. And 
std.format.formattedWrite is called on aggregate types like 
lists, which stringifies each value, and passes the string to 
put(), resulting in again, 1 fwrite per character.


Why put() doesn't just call fwrite without expanding into 1 
character strings, I have no idea. Something with wide 
characters, I guess? But even then it could use one fwrite for 
normal characters. It's not like

fwrite("a",1,1,stdout);fwrite("b",1,1,stdout);
will fail any less if the output stream dies before "b" than
fwrite("ab",2,1,stdout);

Why put() doesn't call the C "fputc" function for 1 character 
strings, I *really* have no idea.


Seems to me some fancy code generation producing write("a"," ", 
"b", " ", "c", "\n") or even put("a b c\n") would still expand 
into 1 put() per character, before it finished compiling.


tl;dr speed demons use std.stream.InputStream.read() whenever you 
can, and std.stream.OutputStream.write() its result. Don't expect 
std.stdio to let you have nice things. std.file.write is always 
preferable if you can generate the whole file beforehand.


Re: std.signals crashes GtkD gui application when SpinButton tied to signal.

2016-02-04 Thread Enjoys Math via Digitalmars-d-learn

On Friday, 5 February 2016 at 06:52:11 UTC, Enjoys Math wrote:


I have two spin buttons connected to the width and height of 2d 
objects in a scene.  Using


mixin std.signals.Signal!(double, double) dimentionChanged;

and there is a growing delay that happens not caused by the 
rendering code, the transform code, or the triggering code (I 
used a timer to measure).


Then switching over to a D delegate, the issue went away.

It starts to freeze the gui app so that you can't do much at 
all.


Thus std.signals can't handle a large number of signals maybe 
50 / second.  It causes some weird delays to happen.


Would anyone like to see my source code?

You need:
Visual D
GtkD-3.(latest) (32-bit)
Gtk Runtime


Wait it's happening again.  It's sporadic I guess.


std.signals crashes GtkD gui application when SpinButton tied to signal.

2016-02-04 Thread Enjoys Math via Digitalmars-d-learn


I have two spin buttons connected to the width and height of 2d 
objects in a scene.  Using


mixin std.signals.Signal!(double, double) dimentionChanged;

and there is a growing delay that happens not caused by the 
rendering code, the transform code, or the triggering code (I 
used a timer to measure).


Then switching over to a D delegate, the issue went away.

It starts to freeze the gui app so that you can't do much at all.

Thus std.signals can't handle a large number of signals maybe 50 
/ second.  It causes some weird delays to happen.


Would anyone like to see my source code?

You need:
Visual D
GtkD-3.(latest) (32-bit)
Gtk Runtime


Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread tcak via Digitalmars-d-learn

On Friday, 5 February 2016 at 06:23:09 UTC, Daniel Kozak wrote:

V Fri, 05 Feb 2016 03:47:40 +
tcak via Digitalmars-d-learn 
napsáno:


[...]


Did you try catch Throwable instead of Exception?


Undid the fix, and wrapped the problem causing function call with 
try-catch-Throwable, it is caught now. I always used Exception 
before, thinking that it was the base of all exceptions.


Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread Daniel Kozak via Digitalmars-d-learn
V Fri, 05 Feb 2016 03:47:40 +
tcak via Digitalmars-d-learn 
napsáno:

> On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote:
> > On 02/04/2016 12:25 PM, tcak wrote:
> >  
> > > void threadFunc(){
> > >  scope(exit){
> > >  writeln("Leaving 2: ", stopRequested);
> > >  }
> > >
> > >
> > >  while( !stopRequested ){
> > > /* THERE IS NO "RETURN" HERE AT ALL */
> > >  }
> > >
> > >  writeln("Leaving 1: ", stopRequested);
> > > }
> > >
> > >
> > >
> > > While loop is running, suddenly "Leaving 2: false" is seen.  
> >
> > That would happen when there is an exception.
> >  
> > > Checked with
> > > exception, but there is nothing.  
> >
> > If a thread is terminated with an exception, its stack is 
> > unwound and unlike the main thread, the program will not 
> > terminate. I think this is due to an exception.
> >  
> > > GDB doesn't show any error.  
> >
> > I think putting a break point at exception construction would 
> > be helpful but it will be simpler to put a try-catch block that 
> > covers the entire body of threadFunc().
> >  
> > > There is no
> > > "Leaving 1: .." message at all.
> > >
> > > Is there any known reason for a thread to suddenly stop like  
> > this?
> >
> > I am still betting on an exception. :)
> >
> > Ali  
> 
> Yup, it is exception it seems like, but with a weird result. 
> Check the new codes:
> 
> void threadFunc(){
>   scope(exit){
>   writeln("Leaving 2: ", stopRequested);
>   }
> 
>   scope(failure){
>   writeln("Failure");
>   }
> 
>   try{
>   while( !stopRequested ){
> 
>   }
> 
>   writeln("Leaving 1: ", stopRequested);
>   }
>   catch( Exception ex ){
>   writeln("Caught the exception");
>   }
> }
> 
> Now, the thread stops with:
> 
> Failure
> Leaving 2: false
> 
> 
> There is no "Caught the exception". And believe me other then the 
> codes inside while loop, main structure as seen in the above code.
> 
> By testing many times, I understood that the problem occurs when 
> too many requests are received suddenly (by pressing F5 many 
> times again and again produces the exception).
> 
> But the question is why try-catch is not able to catch it, and 
> just scope(failure) can?

Did you try catch Throwable instead of Exception?



Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread Daniel Kozak via Digitalmars-d-learn
V Fri, 05 Feb 2016 05:48:27 +
tcak via Digitalmars-d-learn 
napsáno:

> On Friday, 5 February 2016 at 03:47:40 UTC, tcak wrote:
> > On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote:  
> >> On 02/04/2016 12:25 PM, tcak wrote:
> >>  
> >> > [...]  
> >>
> >> That would happen when there is an exception.
> >>  
> >> > [...]  
> >>
> >> If a thread is terminated with an exception, its stack is 
> >> unwound and unlike the main thread, the program will not 
> >> terminate. I think this is due to an exception.
> >>  
> >> > [...]  
> >>
> >> I think putting a break point at exception construction would 
> >> be helpful but it will be simpler to put a try-catch block 
> >> that covers the entire body of threadFunc().
> >>  
> >> > [...]  
> >> this?
> >>
> >> I am still betting on an exception. :)
> >>
> >> Ali  
> >
> > Yup, it is exception it seems like, but with a weird result. 
> > Check the new codes:
> >
> > void threadFunc(){
> > scope(exit){
> > writeln("Leaving 2: ", stopRequested);
> > }
> >
> > scope(failure){
> > writeln("Failure");
> > }
> >
> > try{
> > while( !stopRequested ){
> >
> > }
> >
> > writeln("Leaving 1: ", stopRequested);
> > }
> > catch( Exception ex ){
> > writeln("Caught the exception");
> > }
> > }
> >
> > Now, the thread stops with:
> >
> > Failure
> > Leaving 2: false
> >
> >
> > There is no "Caught the exception". And believe me other then 
> > the codes inside while loop, main structure as seen in the 
> > above code.
> >
> > By testing many times, I understood that the problem occurs 
> > when too many requests are received suddenly (by pressing F5 
> > many times again and again produces the exception).
> >
> > But the question is why try-catch is not able to catch it, and 
> > just scope(failure) can?  
> 
> Okay. The cause of problem has been solved with good-old 
> writeln("DEBUG"); method :)
> 
> Cause is trying to access outside of array (e.g. array[$]). But I 
> didn't like that fact that scope(failure) is called for that 
> properly, but no other error was seen.
> 
> Environment: MonoDevelop, Linux x64, DMD 2.070, MonoD, running in 
> Debug mode.

This is wierd, IMHO it is a bug.



Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread tcak via Digitalmars-d-learn

On Friday, 5 February 2016 at 03:47:40 UTC, tcak wrote:

On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote:

On 02/04/2016 12:25 PM, tcak wrote:

> [...]

That would happen when there is an exception.

> [...]

If a thread is terminated with an exception, its stack is 
unwound and unlike the main thread, the program will not 
terminate. I think this is due to an exception.


> [...]

I think putting a break point at exception construction would 
be helpful but it will be simpler to put a try-catch block 
that covers the entire body of threadFunc().


> [...]
this?

I am still betting on an exception. :)

Ali


Yup, it is exception it seems like, but with a weird result. 
Check the new codes:


void threadFunc(){
scope(exit){
writeln("Leaving 2: ", stopRequested);
}

scope(failure){
writeln("Failure");
}

try{
while( !stopRequested ){

}

writeln("Leaving 1: ", stopRequested);
}
catch( Exception ex ){
writeln("Caught the exception");
}
}

Now, the thread stops with:

Failure
Leaving 2: false


There is no "Caught the exception". And believe me other then 
the codes inside while loop, main structure as seen in the 
above code.


By testing many times, I understood that the problem occurs 
when too many requests are received suddenly (by pressing F5 
many times again and again produces the exception).


But the question is why try-catch is not able to catch it, and 
just scope(failure) can?


Okay. The cause of problem has been solved with good-old 
writeln("DEBUG"); method :)


Cause is trying to access outside of array (e.g. array[$]). But I 
didn't like that fact that scope(failure) is called for that 
properly, but no other error was seen.


Environment: MonoDevelop, Linux x64, DMD 2.070, MonoD, running in 
Debug mode.


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote:
[...]

Apologies for spamming. This is an improved implementation:

@property
Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t 
to)() @safe const

if (from <= to && to <= Types.length)
{
return typeof(return)(field[from .. to]);
}

///
unittest
{
Tuple!(int, string, float, double) a;
a[1] = "abc";
a[2] = 4.5;
auto s = a.slice!(1, 3);
static assert(is(typeof(s) == Tuple!(string, float)));
assert(s[0] == "abc" && s[1] == 4.5);

Tuple!(int, int, long) b;
b[1] = 42;
b[2] = 101;
auto t = b.slice!(1, 3);
static assert(is(typeof(t) == Tuple!(int, long)));
assert(t[0] == 42 && t[1] == 101);
}

These questions still remain:

1. Removing 'ref' from the return type
2. Adding 'const' to the function signature
3. Is the new implementation less efficient for correctly 
aligned tuples?

4. @trusted -> @safe?



Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

On Friday, 5 February 2016 at 05:18:01 UTC, Saurabh Das wrote:

[...]


PS: Additionally, '@trusted' can now be substituted with '@safe'.


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote:

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


Is this a possible fixed implementation? :

@property
Tuple!(sliceSpecs!(from, to)) slice(size_t from, size_t 
to)() @trusted const

if (from <= to && to <= Types.length)
{
auto sliceMixinGenerator()
{
string rv;
for(auto i=from; irv ~= "returnValue[" ~ (i-from).to!string ~ 
"]=field[" ~ i.to!string ~"];";

}
return rv;
}
alias ReturnType = typeof(return);
ReturnType returnValue;
mixin(sliceMixinGenerator());
return returnValue;
}

///
unittest
{
Tuple!(int, string, float, double) a;
a[1] = "abc";
a[2] = 4.5;
auto s = a.slice!(1, 3);
static assert(is(typeof(s) == Tuple!(string, float)));
assert(s[0] == "abc" && s[1] == 4.5);

Tuple!(int, int, long) b;
b[1] = 42;
b[2] = 101;
auto t = b.slice!(1, 3);
static assert(is(typeof(t) == Tuple!(int, long)));
assert(t[0] == 42 && t[1] == 101);
}

I'm unsure about:
1. Removing 'ref' from the return type
2. Adding 'const' to the function signature
3. Is the new implementation less efficient for correctly aligned 
tuples?




Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread tcak via Digitalmars-d-learn

On Thursday, 4 February 2016 at 22:27:31 UTC, Ali Çehreli wrote:

On 02/04/2016 12:25 PM, tcak wrote:

> void threadFunc(){
>  scope(exit){
>  writeln("Leaving 2: ", stopRequested);
>  }
>
>
>  while( !stopRequested ){
> /* THERE IS NO "RETURN" HERE AT ALL */
>  }
>
>  writeln("Leaving 1: ", stopRequested);
> }
>
>
>
> While loop is running, suddenly "Leaving 2: false" is seen.

That would happen when there is an exception.

> Checked with
> exception, but there is nothing.

If a thread is terminated with an exception, its stack is 
unwound and unlike the main thread, the program will not 
terminate. I think this is due to an exception.


> GDB doesn't show any error.

I think putting a break point at exception construction would 
be helpful but it will be simpler to put a try-catch block that 
covers the entire body of threadFunc().


> There is no
> "Leaving 1: .." message at all.
>
> Is there any known reason for a thread to suddenly stop like
this?

I am still betting on an exception. :)

Ali


Yup, it is exception it seems like, but with a weird result. 
Check the new codes:


void threadFunc(){
scope(exit){
writeln("Leaving 2: ", stopRequested);
}

scope(failure){
writeln("Failure");
}

try{
while( !stopRequested ){

}

writeln("Leaving 1: ", stopRequested);
}
catch( Exception ex ){
writeln("Caught the exception");
}
}

Now, the thread stops with:

Failure
Leaving 2: false


There is no "Caught the exception". And believe me other then the 
codes inside while loop, main structure as seen in the above code.


By testing many times, I understood that the problem occurs when 
too many requests are received suddenly (by pressing F5 many 
times again and again produces the exception).


But the question is why try-catch is not able to catch it, and 
just scope(failure) can?


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

On Thursday, 4 February 2016 at 17:52:16 UTC, Marco Leise wrote:

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


Thank you.

I understood why this is happening from your explanation in the 
bug report.




Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread Ali Çehreli via Digitalmars-d-learn

On 02/04/2016 12:25 PM, tcak wrote:

> void threadFunc(){
>  scope(exit){
>  writeln("Leaving 2: ", stopRequested);
>  }
>
>
>  while( !stopRequested ){
> /* THERE IS NO "RETURN" HERE AT ALL */
>  }
>
>  writeln("Leaving 1: ", stopRequested);
> }
>
>
>
> While loop is running, suddenly "Leaving 2: false" is seen.

That would happen when there is an exception.

> Checked with
> exception, but there is nothing.

If a thread is terminated with an exception, its stack is unwound and 
unlike the main thread, the program will not terminate. I think this is 
due to an exception.


> GDB doesn't show any error.

I think putting a break point at exception construction would be helpful 
but it will be simpler to put a try-catch block that covers the entire 
body of threadFunc().


> There is no
> "Leaving 1: .." message at all.
>
> Is there any known reason for a thread to suddenly stop like this?

I am still betting on an exception. :)

Ali



Re: print function

2016-02-04 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote:
Unfortunately there is no such thing and it is unlikely to 
exist in the next decade.


Well, it is probably not the best point in time to have absolute 
beginners use D anyway. But a well commented library, that don't 
focus on performance and teach good habits using the non-advanced 
D feature subset, can go a long way if the design is explained in 
a companion tutorial. A "build your own pythonesque library" 
tutorial wrapped up as a zip-file with a sensible main-file 
template that is ready to compile.


That way newbies can just unzip it into a new directory when they 
start a new project "resetting" former mistakes.






Re: What reasons are known a thread stops suddenly?

2016-02-04 Thread ikod via Digitalmars-d-learn

On Thursday, 4 February 2016 at 20:25:27 UTC, tcak wrote:

Is there any known reason for a thread to suddenly stop like 
this?


Your listener object can be GC-ed. Check if you have any live ref 
to it.


What reasons are known a thread stops suddenly?

2016-02-04 Thread tcak via Digitalmars-d-learn
I have implemented a standalone HTTP server. So everything is in 
single executable. Requests come, for responding a new thread is 
started, etc.


To listen new socket connections, and socket events, a single 
thread is used (Call this event listener thread).


Everything works perfectly. Firefox asks for page, all HTML, JS, 
CSS, Image requests come and responded properly.


Now, when I start the executable, instead of calling the page on 
Firefox by pressing F5 for refresh, if I press Ctrl+Shift+F5, 
Firefox asks for same requests as always do, but that event 
listener thread suddenly stops.


You might say that is a programming error of mine, but problem is 
as follows:


void threadFunc(){
scope(exit){
writeln("Leaving 2: ", stopRequested);
}


while( !stopRequested ){
/* THERE IS NO "RETURN" HERE AT ALL */
}

writeln("Leaving 1: ", stopRequested);
}



While loop is running, suddenly "Leaving 2: false" is seen. 
Checked with exception, but there is nothing. GDB doesn't show 
any error. There is no "Leaving 1: .." message at all.


Is there any known reason for a thread to suddenly stop like this?


Re: print function

2016-02-04 Thread Artur Skawina via Digitalmars-d-learn
On 02/04/16 18:53, ixid via Digitalmars-d-learn wrote:
> On Thursday, 4 February 2016 at 17:34:33 UTC, Artur Skawina wrote:
>> On 02/04/16 16:32, Artur Skawina wrote:
>> but that seems too expensive, when the use is just in toy programs and 
>> debugging.
> 
> I hadn't really considered the relative cost-benefit, it's just a habit to 
> try to hardcode things at compile time. =) It certainly seems to make sense 
> to do it that way.

Just to clarify -- *all* versions work at CT; the static-foreach
will be unrolled at CT, and the mixin argument will be fully
evaluated at CT too. The only difference is in a) readability, b)
the `write` template instantiations (and potential re-use).

Using the std lib `write*` templates has a huge cost; for any
kind of /real/ programs, that care about performance at all, they
are better avoided. (But it probably doesn't matter if you already
heavily rely on GC and don't print much, other than that they add
tons of code to the executable)


artur


Re: Octree implementation?

2016-02-04 Thread Marco Leise via Digitalmars-d-learn
Am Mon, 01 Feb 2016 02:56:06 +
schrieb Tofu Ninja :

> Just out of curiosity, does anyone have an octree implementation 
> for D laying around? Just looking to save some time.

I have one written in Delphi that you could prune till it fits.

-- 
Marco



Re: print function

2016-02-04 Thread ixid via Digitalmars-d-learn

On Thursday, 4 February 2016 at 17:34:33 UTC, Artur Skawina wrote:

On 02/04/16 16:32, Artur Skawina wrote:
but that seems too expensive, when the use is just in toy 
programs and debugging.


I hadn't really considered the relative cost-benefit, it's just a 
habit to try to hardcode things at compile time. =) It certainly 
seems to make sense to do it that way.


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Marco Leise via Digitalmars-d-learn
https://issues.dlang.org/show_bug.cgi?id=15645


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Marco Leise via Digitalmars-d-learn
Am Thu, 04 Feb 2016 15:17:54 +
schrieb Saurabh Das :

> On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote:
> > This code:
> > [...]
> 
> Update: Simplified, this also doesn't work:
> 
> void main()
> {
>  import std.typecons;
>  auto tp = tuple(10, false, "hello");
> 
>  auto u0 = tp.slice!(0, tp.length);
>  auto u1 = tp.slice!(1, tp.length);
>  auto u2 = tp.slice!(2, tp.length);
> 
>  static assert(is(typeof(u0) == Tuple!(int, bool, string)));
>  static assert(is(typeof(u1) == Tuple!(bool, string)));
>  static assert(is(typeof(u2) == Tuple!(string)));
> 
>  assert(u2[0] == "hello");
>  assert(u0[2] == "hello");
>  assert(u1[1] == "hello");// This fails
> }
> 
> rdmd erasetype.d
> core.exception.AssertError@erasetype.d(16): Assertion failure
> 
> Any ideas?

Yes this is a clear bug, I'll report a bug and post the issue
number later.

-- 
Marco



Re: print function

2016-02-04 Thread Artur Skawina via Digitalmars-d-learn
On 02/04/16 16:32, Artur Skawina wrote:
> 
>void print(A...)(A a) {
>   foreach (N, ref e; a)
>  write(e, N==A.length-1?"\n":" ");
>}

BTW, that was *deliberately* written that way as a compromise
between efficiency and template bloat. It can of course be
done like

   void print(alias SEP=" ", alias EOL="\n", A...)(A a) {
  
mixin(`write(`~iota(A.length).map!(a=>"a["~text(a)~"],")().join("SEP,")~"EOL);");
   }

but that seems too expensive, when the use is just in toy
programs and debugging.


artur


Re: print function

2016-02-04 Thread bachmeier via Digitalmars-d-learn

On Thursday, 4 February 2016 at 15:10:18 UTC, Kagamin wrote:

On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote:
Unfortunately there is no such thing and it is unlikely to 
exist in the next decade.


There is 
http://forum.dlang.org/post/mtsd38$16ub$1...@digitalmars.com


The important feature is the one that it doesn't offer - it's not 
part of the default installation. Without that, it doesn't help 
new users much. It's not even listed on the "Getting Started" for 
that matter.


Re: print function

2016-02-04 Thread sigod via Digitalmars-d-learn

On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
It would be nice to have a simple writeln that adds spaces 
automatically like Python's 'print' in std.stdio, perhaps 
called print.


It seems Andrei decided to add such function: 
http://forum.dlang.org/thread/n8vr0l$ist$1...@digitalmars.com


Re: print function

2016-02-04 Thread Artur Skawina via Digitalmars-d-learn
On 02/04/16 15:02, ixid via Digitalmars-d-learn wrote:
> On Thursday, 4 February 2016 at 13:46:46 UTC, Dejan Lekic wrote:
>> On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
>>> It would be nice to have a simple writeln that adds spaces automatically 
>>> like Python's 'print' in std.stdio, perhaps called print.

> I have written an attempt at it but my point was that a print function would 
> be a good addition to the standard library rather than asking someone to 
> write an implementation for me.
> 
> string makePrintString(T)(T length) {
> import std.conv : to;
>
> string s = "writeln(";
> foreach( i; 0 .. length) {
> s ~= "a[" ~ i.to!string ~ "]";
> if(i != length - 1)
> s ~= ",\" \",";
> else s ~= ");";
> }
>
> return s;
> }   
> 
> void print(A...)(A a) {   
> static if(a.length) {
> mixin(makePrintString(a.length));
> } else writeln;
> }

   void print(A...)(A a) {
  foreach (N, ref e; a)
 write(e, N==A.length-1?"\n":" ");
   }


artur


Re: Non-English characters in code - "character 0x2212 is not a valid token"

2016-02-04 Thread sigod via Digitalmars-d-learn

On Thursday, 28 January 2016 at 14:45:36 UTC, Adam D. Ruppe wrote:

On Thursday, 28 January 2016 at 14:39:46 UTC, sigod wrote:

I tried to compile your code on dpaste (2.070.0) and got this:


dpaste has an input mangling bug with some characters as a 
result of the form submission over the web.


Oh, I see.

Is there any place where one can report bugs on dpaste?


Re: Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

On Thursday, 4 February 2016 at 12:28:39 UTC, Saurabh Das wrote:

This code:
[...]


Update: Simplified, this also doesn't work:

void main()
{
import std.typecons;
auto tp = tuple(10, false, "hello");

auto u0 = tp.slice!(0, tp.length);
auto u1 = tp.slice!(1, tp.length);
auto u2 = tp.slice!(2, tp.length);

static assert(is(typeof(u0) == Tuple!(int, bool, string)));
static assert(is(typeof(u1) == Tuple!(bool, string)));
static assert(is(typeof(u2) == Tuple!(string)));

assert(u2[0] == "hello");
assert(u0[2] == "hello");
assert(u1[1] == "hello");// This fails
}

rdmd erasetype.d
core.exception.AssertError@erasetype.d(16): Assertion failure

Any ideas?


Re: print function

2016-02-04 Thread Kagamin via Digitalmars-d-learn

On Thursday, 4 February 2016 at 14:25:21 UTC, bachmeier wrote:
Unfortunately there is no such thing and it is unlikely to 
exist in the next decade.


There is http://forum.dlang.org/post/mtsd38$16ub$1...@digitalmars.com


Re: print function

2016-02-04 Thread bachmeier via Digitalmars-d-learn
On Thursday, 4 February 2016 at 11:04:15 UTC, Ola Fosheim Grøstad 
wrote:

On Thursday, 4 February 2016 at 10:59:50 UTC, Mike Parker wrote:
IMO, while giving beginner's a helping hand is a great thing, 
I don't think it's a good basis to use as a design for a 
standard library.


Yes, better to have a "beginners toolkit" 
starting-point-codebase and build a tutorial around it.


That would be a reasonable argument if such a thing existed and 
was included with the compiler.


import newbie;

void main() {
  print("Jack", "Black");
}

Unfortunately there is no such thing and it is unlikely to exist 
in the next decade.


Re: print function

2016-02-04 Thread ixid via Digitalmars-d-learn

On Thursday, 4 February 2016 at 13:46:46 UTC, Dejan Lekic wrote:

On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
It would be nice to have a simple writeln that adds spaces 
automatically like Python's 'print' in std.stdio, perhaps 
called print.


There are many implementations of string interpolation in D 
(that is what you want, basically). One of them is given in 
Phillipe's excellent book about templates: 
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .


I have written an attempt at it but my point was that a print 
function would be a good addition to the standard library rather 
than asking someone to write an implementation for me.


string makePrintString(T)(T length) {
import std.conv : to;

string s = "writeln(";
foreach( i; 0 .. length) {
s ~= "a[" ~ i.to!string ~ "]";
if(i != length - 1)
s ~= ",\" \",";
else s ~= ");";
}

return s;
}   

void print(A...)(A a) { 
static if(a.length) {
mixin(makePrintString(a.length));
} else writeln;
}


Re: print function

2016-02-04 Thread Dejan Lekic via Digitalmars-d-learn

On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
It would be nice to have a simple writeln that adds spaces 
automatically like Python's 'print' in std.stdio, perhaps 
called print.


There are many implementations of string interpolation in D (that 
is what you want, basically). One of them is given in Phillipe's 
excellent book about templates: 
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.md#simple-string-interpolation .


Re: Counting time difference.

2016-02-04 Thread holo via Digitalmars-d-learn

On Wednesday, 3 February 2016 at 22:45:03 UTC, sigod wrote:

On Wednesday, 3 February 2016 at 22:27:07 UTC, holo wrote:
When i start same program on server in different timezone 
difference is much higher (more than hour). Why it is 
happening? Timezones shouldnt have influence on such equation.


Try using `Clock.currTime(UTC())`. And make sure all instances 
produce timezone independent timestamps.


Thank you, now i see that AWS is getting back Time in UTC so that 
solved problem.


@Jonathan M Davis

like i wrote above using UTC time helped me. Thank you for 
information about that monotonic clock will check it too for 
learning purpose.


//holo


Is this a bug in std.typecons.Tuple.slice?

2016-02-04 Thread Saurabh Das via Digitalmars-d-learn

This code:

void main()
{
import std.typecons;
auto tp = tuple!("a", "b", "c")(10, false, "hello");

auto u0 = tp.slice!(0, tp.length);
auto u1 = tp.slice!(1, tp.length);
auto u2 = tp.slice!(2, tp.length);

static assert(is(typeof(u0) == Tuple!(int, "a", bool, "b", 
string, "c")));
static assert(is(typeof(u1) == Tuple!(bool, "b", string, 
"c")));

static assert(is(typeof(u2) == Tuple!(string, "c")));

assert(u2.c == "hello");
assert(u0.c == "hello");
assert(u1.c == "hello");// This assert fails. Why?
}

core.exception.AssertError@erasetype.d(16): Assertion failure

4   erasetype   0x000100ce8128 
_d_assert + 104
5   erasetype   0x000100cd12fe void 
erasetype.__assert(int) + 38
6   erasetype   0x000100cd12aa _Dmain 
+ 250
7   erasetype   0x000100cf7297 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
8   erasetype   0x000100cf71cf void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 55
9   erasetype   0x000100cf723c void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() + 44
10  erasetype   0x000100cf71cf void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 55
11  erasetype   0x000100cf7121 
_d_run_main + 497
12  erasetype   0x000100cd133f main + 
15
13  libdyld.dylib   0x7fff8a1345c8 start 
+ 0

14  ??? 0x 0x0 + 0

Why does 'u1' behave differently? I'm thinking it's a bug, but I 
haven't worked much with tuples, so maybe I'm missing something?


Thanks,
Saurabh



Re: print function

2016-02-04 Thread ixid via Digitalmars-d-learn

On Thursday, 4 February 2016 at 11:04:23 UTC, cym13 wrote:

On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote:
Do you think your knowledge and experience is a good model for 
how a new user who hasn't done much if any programming before 
would approach this?


A design choice had to be made and made it was. Adding another 
function now (or worse, changing the existing ones) would only 
bring more confusion for beginners and unconsistency to the 
language. I firmly believe that no matter what your experience 
you have having one and preferably only one way to do things is 
more important to ease the learning process than having spaces 
or not.


That's a nonsensical argument given the number of printing and 
writing functions that exist.


Re: print function

2016-02-04 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 4 February 2016 at 10:59:50 UTC, Mike Parker wrote:
IMO, while giving beginner's a helping hand is a great thing, I 
don't think it's a good basis to use as a design for a standard 
library.


Yes, better to have a "beginners toolkit" starting-point-codebase 
and build a tutorial around it.




Re: print function

2016-02-04 Thread cym13 via Digitalmars-d-learn

On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote:
Do you think your knowledge and experience is a good model for 
how a new user who hasn't done much if any programming before 
would approach this?


A design choice had to be made and made it was. Adding another 
function now (or worse, changing the existing ones) would only 
bring more confusion for beginners and unconsistency to the 
language. I firmly believe that no matter what your experience 
you have having one and preferably only one way to do things is 
more important to ease the learning process than having spaces or 
not.


Re: print function

2016-02-04 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 4 February 2016 at 10:18:35 UTC, ixid wrote:
On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis 
wrote:
I would normally expect someone to do that with writefln, 
which would be cleaner. e.g.


writefln("%s %s %s %s", a, b, c, d);

Personally, I've never felt the need for a function like 
you're describing.


- Jonathan M Davis


Do you think your knowledge and experience is a good model for 
how a new user who hasn't done much if any programming before 
would approach this?


IMO, while giving beginner's a helping hand is a great thing, I 
don't think it's a good basis to use as a design for a standard 
library.


Re: Detecting exception unwinding

2016-02-04 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Thursday, 4 February 2016 at 10:03:13 UTC, Jonathan M Davis 
wrote:
On Wednesday, February 03, 2016 23:55:42 Ali Çehreli via 
Digitalmars-d-learn wrote:

std::uncaught_exception used to be considered useless:


I think that the only case I've ever had for it was for a unit 
testing framework where I wanted to use RAII to print something 
when the tests failed (and thus an exception was thrown) but 
not print if they succeeded, and if I were to do that in D, I'd 
just use scope(failure).


Well, yes, it is useful for logging. It is useful to know if an 
invariant is broken during regular unwinding (serious error) or 
exceptional situations (might be unavoidable).


But I think Herb Sutters major point was that if you had multiple 
destructors it could not detect where the exceptions originate 
from. So C++17 has a new function that returns the number of 
uncaught expressions:


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf



Re: print function

2016-02-04 Thread ixid via Digitalmars-d-learn
On Thursday, 4 February 2016 at 10:05:15 UTC, Jonathan M Davis 
wrote:
I would normally expect someone to do that with writefln, which 
would be cleaner. e.g.


writefln("%s %s %s %s", a, b, c, d);

Personally, I've never felt the need for a function like you're 
describing.


- Jonathan M Davis


Do you think your knowledge and experience is a good model for 
how a new user who hasn't done much if any programming before 
would approach this?


Re: print function

2016-02-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, February 04, 2016 00:40:55 ixid via Digitalmars-d-learn wrote:
> On Thursday, 4 February 2016 at 00:30:03 UTC, cym13 wrote:
> > On Thursday, 4 February 2016 at 00:23:07 UTC, ixid wrote:
> >> It would be nice to have a simple writeln that adds spaces
> >> automatically like Python's 'print' in std.stdio, perhaps
> >> called print.
> >
> > Sounds way too redundant to me.
>
> Normally you'd be right but printing out data is such a common
> thing, especially for beginners. It's the kind of thing that can
> make their early experience of a language a lot more positive.
>
> writeln(a, " ", b, " ", c, " ", d);
>
> Is very clunky. Programming languages are like cereal, you need
> sugar to get the kids hooked.

I would normally expect someone to do that with writefln, which would be
cleaner. e.g.

writefln("%s %s %s %s", a, b, c, d);

Personally, I've never felt the need for a function like you're describing.

- Jonathan M Davis



Re: std.socket question

2016-02-04 Thread tcak via Digitalmars-d-learn

On Thursday, 4 February 2016 at 06:40:15 UTC, sanjayss wrote:
Are the functions lastSocketError() and wouldHaveBlocked() from 
std.socket thread-safe? i.e. can they be reliably used to see 
the status of the last socket call when sockets are being 
read/written in multiple threads?


Not directly read the code for a while (but did before), those 
two functions
call C functions, and they are thread-safe by default. The 
WOULD-HAVE-BLOCKED
is understood by checking errno which comes from core.stdc.errno. 
If you read
that function's documents, you will see that it is marked as 
thread-safe.


http://linux.die.net/man/3/errno
... errno is thread-local; setting it in one thread does not 
affect its value in any other thread. ...


Re: Detecting exception unwinding

2016-02-04 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, February 03, 2016 23:55:42 Ali Çehreli via Digitalmars-d-learn 
wrote:
> std::uncaught_exception used to be considered useless:

I think that the only case I've ever had for it was for a unit testing
framework where I wanted to use RAII to print something when the tests
failed (and thus an exception was thrown) but not print if they succeeded,
and if I were to do that in D, I'd just use scope(failure).

- Jonathan M Davis




Re: How do you check if object o has base type B?

2016-02-04 Thread Gary Willoughby via Digitalmars-d-learn

On Thursday, 4 February 2016 at 05:51:22 UTC, Enjoys Math wrote:

Consider:

class C {

}

class B : C {

}

class A : B {

}

class D : C {

}

C[] objList;

how do we test if objLis[k] is of base type "B"?

Ie for [new A(), new B(), new D(), new C()] would give output 
[true, true, false, false].


?

Thank you! :D


if (cast(B)objLis[k])
{
// It's an instance.
}


Re: Get the return type of the function

2016-02-04 Thread tsbockman via Digitalmars-d-learn

On Thursday, 4 February 2016 at 07:11:44 UTC, xtreak wrote:

On Thursday, 4 February 2016 at 05:50:05 UTC, tsbockman wrote:
See my PR for a workaround: 
https://github.com/D-Programming-Language/phobos/pull/3969/files


Thanks a lot for the patch. It will be helpful if you could 
explain the workaround as I am a newbie in D language.


Explanation here: 
https://github.com/tsbockman/phobos/commit/be7c55fbea7f37987e9f965f968c54b4a3f7342b#commitcomment-15878936


Re: Detecting exception unwinding

2016-02-04 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Wednesday, 3 February 2016 at 21:35:38 UTC, Jonathan M Davis 
wrote:

https://issues.dlang.org

At least that way, it's kept track of, though I certainly have 
no idea when it might be implemented (presumably when someone 
needs it enough that they take the time to do so).


Thanks, I think I will wait with filing an enhancement request as 
I think there are more pressing issues to be dealt with.  I 
should look into creating my own runtime anyway.




Re: Detecting exception unwinding

2016-02-04 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

On Thursday, 4 February 2016 at 07:55:42 UTC, Ali Çehreli wrote:

std::uncaught_exception used to be considered useless:

  http://www.gotw.ca/gotw/047.htm

Does that apply to D?


I've read that one, but Herb Sutter does not provide an argument, 
just a claim that having different semantics on the exceptional 
path to be somehow immoral.




Re: DMD OSX / Segfault 11

2016-02-04 Thread Robert M. Münch via Digitalmars-d-learn

On 2016-02-03 13:29:15 +, anonymous said:

Still missing "class". I know I'm being pedantic, but if you're being 
sloppy here, how do I know that you're not being sloppy where it 
matters?


You are right, sorry. I was to focused on the problem part...



If anything, you should be casting between Value* and BaseOperator*
(both pointer types) if you want to do something with pointers.


I tried this, but that doesn't work either.


Yeah, you can't check if the downcast succeeded this way. Casts between 
pointers always succeed (and then fail horribly at run-time).


Aha, that's my missing link. I didn't know that and it makes it all clear.

IMO that's a not to underestimate trap. Since I can use the . notation 
instead of -> when using pointers, I would have expected that casting 
will work the same with both variants as well...



But am I not getting a copy then? I want to avoid copying objects as
much as possible.


No, you're not getting a copy. Classes are reference types. That means, 
variables of class types are references already. They're pointers in 
disguise.


Ok. Seems I was really confused. Thanks a lot.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: DMD OSX / Segfault 11

2016-02-04 Thread Robert M. Münch via Digitalmars-d-learn

On 2016-02-03 14:35:16 +, Steven Schveighoffer said:


On 2/3/16 8:17 AM, Robert M. Münch wrote:

On 2016-02-02 18:59:35 +, Steven Schveighoffer said:


If this is valid D, I'm not sure what it means :)


There was one type, the rest I stripped totally away as IMO it's not
relevant for the actual problem.



Very relevant: what are you declaring? A class, struct, template, enum?


;-) Ok... that's really missing. A class.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Detecting exception unwinding

2016-02-04 Thread Ali Çehreli via Digitalmars-d-learn

On 02/03/2016 03:47 AM, Ola Fosheim Grøstad wrote:

On Wednesday, 3 February 2016 at 11:41:28 UTC, Jonathan M Davis wrote:

AFAIK, there is no way to detect whether an exception is in flight or
not aside from the cases where scope(failure) or catch would catch the
exception, and from what I recall of the last time that someone asked
this question, the consensus was that it couldn't be done - but maybe
I'm remembering incorrectly. I am pretty sure that this was asked
within the last few months though, so if you search D.Learn, you can
probably find that discussion.


:-/

I am looking for something like this:

http://en.cppreference.com/w/cpp/error/uncaught_exception

It is useful for certain types of libraries where you want to cancel out
effects "undo commits" when exceptional situations arise.




std::uncaught_exception used to be considered useless:

  http://www.gotw.ca/gotw/047.htm

Does that apply to D?

Ali