Re: Stacktraces in static constructors

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
This is a big problem for me because, in my application, I've 
realized unittests as functions called from within static 
shared module constructors to elide the problem of unittests 
being enabled recursively, which slows down iterative 
compilation time enormously.


Doh, correction. I hade made the wrong assumption about separate 
compilation of unittests. It *only* instantiates unittests in the 
module I compile and *not* in the unittests contained in the 
imported modules.


Sorry for disturbance,
Per

Re: Ascii string literal.

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 7 May 2016 at 01:37:30 UTC, Jonathan M Davis wrote:
In general, it's better to use representation than to cast, 
because representation gets the constness right, whereas if you 
cast, there's always the risk that you won't.



Yeah, if it is a general thing, but here it is a simple function 
statically typed to string...

Re: Ascii string literal.

[Jonathan M Davis via Digitalmars-d-learn]

On Fri, 06 May 2016 21:57:22 +
"Adam D. Ruppe via Digitalmars-d-learn"
 wrote:

> On Friday, 6 May 2016 at 21:39:35 UTC, Anonymouse wrote:
> > Is this different from what std.string.representation does?
>
> No, it does the same thing, but with your own function the
> intention may be clearer (or you could do a template to avoid any
> function or custom types too)

In general, it's better to use representation than to cast, because
representation gets the constness right, whereas if you cast, there's always
the risk that you won't.

- Jonathan M Davis

Re: Ascii string literal.

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 6 May 2016 at 21:39:35 UTC, Anonymouse wrote:

Is this different from what std.string.representation does?


No, it does the same thing, but with your own function the 
intention may be clearer (or you could do a template to avoid any 
function or custom types too)

Re: Ascii string literal.

[Anonymouse via Digitalmars-d-learn]

On Friday, 6 May 2016 at 20:29:35 UTC, Adam D. Ruppe wrote:

On Friday, 6 May 2016 at 20:01:27 UTC, Alexandru Ermicioi wrote:

Is it possible somehow to convert implicitly a string literal


Not implicitly (well, unless you just use string, ascii is a 
strict subset of utf-8 anyway), but you could do it explicitly 
easily.


immutable(ubyte)[] ascii(string s) { return 
cast(typeof(return)) s; }


Is this different from what std.string.representation does?

Re: Ascii string literal.

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 6 May 2016 at 20:01:27 UTC, Alexandru Ermicioi wrote:

Is it possible somehow to convert implicitly a string literal


Not implicitly (well, unless you just use string, ascii is a 
strict subset of utf-8 anyway), but you could do it explicitly 
easily.


immutable(ubyte)[] ascii(string s) { return cast(typeof(return)) 
s; }



Then use it like

ascii("your string")

or make it a template and use ascii!"your string" or "your 
string".ascii whatever.


You could (and imo should!) also make a struct to hold the new 
type.

Ascii string literal.

[Alexandru Ermicioi via Digitalmars-d-learn]

Good day,

Is it possible somehow to convert implicitly a string literal 
into an ubyte array?

For example:

void do(immutable(ubyte)[] asciiString) {
// Do something with ascii string.
}

And from another section of code, calling it like:

do("Some ascii string");
---

If no, is there an us-ascii string literal that consists of 
ubytes and not chars?


It's just in some of my code should work only with ascii strings, 
and it will be cumbersome to convert to ubyte array a string 
literal each time a function accepting an ubyte array is called.


Thank you.

Re: Async or event library

[Jay Norwood via Digitalmars-d-learn]

The tnfox cross-platform toolkit had some solution for per-thread 
event loops.  I believe this was the demo:


https://github.com/ned14/tnfox/blob/master/TestSuite/TestEventLoops/main.cpp

Re: Accepting function or delegate as function argument

[Gary Willoughby via Digitalmars-d-learn]

On Wednesday, 4 May 2016 at 15:23:20 UTC, Rene Zwanenburg wrote:

On Wednesday, 4 May 2016 at 14:54:39 UTC, chmike wrote:
Two constructors, one accepting a function and the other one 
accepting a delegate would do the job for the API. Is there a 
simple method to convert a function pointer into a delegate 
pointer that is also efficient ?


http://dlang.org/phobos/std_functional.html#.toDelegate

You can also make your constructor a template, constrain it on 
isCallable if you wish, and then use toDelegate. If the 
argument is already a delegate toDelegate will avoid doing 
extra work.


import std.functional;
import std.stdio;
import std.traits;

class Foo(K,T)
{
private T delegate(K) m_factory;

public this(T)(T factory) if (isCallable!(T))
{
this.m_factory = toDelegate(factory);
}

public T bar(K key)
{
return this.m_factory(key);
}
}

string dummyFactory(string key)
{
return "Hello " ~ key;
}

void main()
{
auto foo = new Foo!(string, string)();

writeln(foo.bar("world"));
}

Re: How the heck is onInvalidMemoryOperationError() nothrow?

[Jeremy DeHaan via Digitalmars-d-learn]

On Friday, 6 May 2016 at 03:24:23 UTC, tsbockman wrote:

On Friday, 6 May 2016 at 02:57:59 UTC, Jeremy DeHaan wrote:

[...]


From the spec 
(https://dlang.org/spec/function.html#nothrow-functions):
"Nothrow functions can only throw exceptions derived from 
class Error."


Throwing an Error is, for many purposes, considered 
fundamentally different than throwing an Exception because 
Error objects aren't meant to be caught by user code. Throwing 
an Error is supposed to just be a way of crashing the program 
with a nice message and stack trace.


A key benefit of this distinction, is that it enables the use 
of `assert()` statements in `nothrow` code.


Oh, interesting. That makes sense, thanks.

Re: Async or event library

[rikki cattermole via Digitalmars-d-learn]

On 07/05/2016 12:08 AM, chmike wrote:

Excuse the naive question rikki, why does the window event loop have to
be single threaded ? The question is just to expose the rationale.

Is it to avoid the synchronization overhead to access the window data ?
In this case there is indeed a lot of data. Is there another reason ?

In some applications and event types the synchronization overhead is
small compared to the benefit of executing tasks in parallel on
different cores.

It is indeed none trivial and could be an interresting phd study subject.


The window event loop doesn't have to be single threaded, but it is 
thread limited. Specifically it cannot be on other threads. If you 
attempt to work with another threads window, it is more or less 
undefined behavior across the board.


Even with Cocoa (OSX's way for GUI's) is considered thread-unsafe 
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

And that is far higher level then X11 or WinAPI does it.

Re: parameter pack to inputRange

[Alex Parrill via Digitalmars-d-learn]

On Friday, 6 May 2016 at 05:00:48 UTC, Erik Smith wrote:
Is there an existing way to adapt a parameter pack to an input 
range? I would like to construct an array with it.  Example:


void run(A...) (A args) {
 Array!int a(toInputRange(args));
}


Use std.range.only: http://dlang.org/phobos/std_range.html#only

void run(A...)(A args) {
auto rng = only(args);
// ...
}

Re: Async or event library

[Kagamin via Digitalmars-d-learn]

On Friday, 6 May 2016 at 12:08:29 UTC, chmike wrote:
In some applications and event types the synchronization 
overhead is small compared to the benefit of executing tasks in 
parallel on different cores.


GUI generates too many messages that are handled too fast - 
synchronization overhead would be too big. That's not counting 
concurrency bugs.

Re: Async or event library

[chmike via Digitalmars-d-learn]

Excuse the naive question rikki, why does the window event loop 
have to be single threaded ? The question is just to expose the 
rationale.


Is it to avoid the synchronization overhead to access the window 
data ? In this case there is indeed a lot of data. Is there 
another reason ?


In some applications and event types the synchronization overhead 
is small compared to the benefit of executing tasks in parallel 
on different cores.


It is indeed none trivial and could be an interresting phd study 
subject.

Re: Async or event library

[rikki cattermole via Digitalmars-d-learn]

Me and Dicebot have just had a quick conversion on IRC about this.
To recap, I'm talking about event loops for windowing.
For an event loop for e.g. socket based systems like Vibe.d it is a 
different story.


For windowing you have the limitation of having to be on the same thread 
as the one that created the window. You just can't do anything, drawing 
a window even processing the event itself can't be done from another thread.


Where as with a socket based event loop you expect other threads to 
handle it.


So basically you've got to make the event loop implementation be 
separated out into a per thread and per process aware.
Most importantly if you do e.g. windowing you must activate the per 
thread event loop.


This is not an easy topic to discuss or solve sadly.

Re: Async or event library

[rikki cattermole via Digitalmars-d-learn]

On 06/05/2016 11:21 PM, Dicebot wrote:

On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote:

Event loops needs to be thread local not per process.
So many API's such as WinAPI for e.g. GUI's have this requirement in
it that its just not worth fighting over.


It is implementation detail. You can have global event loop and
internally distribute work between per-thread event loops - only event
callbacks defined within existing task need to be bound to same worker
thread. From the developer convenience PoV scheduler / event loop
abstraction has to be process-global, I wouldn't consider anything else.


If you do it per process, it sounds rather messy with synchronization ext.

Re: Async or event library

[Dicebot via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote:

Event loops needs to be thread local not per process.
So many API's such as WinAPI for e.g. GUI's have this 
requirement in it that its just not worth fighting over.


It is implementation detail. You can have global event loop and 
internally distribute work between per-thread event loops - only 
event callbacks defined within existing task need to be bound to 
same worker thread. From the developer convenience PoV scheduler 
/ event loop abstraction has to be process-global, I wouldn't 
consider anything else.

Re: Async or event library

[Dicebot via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote:
At the bottom of the wiki page there is an innocent question 
regarding TLS which is quite devastating. A worker thread pool 
system would not support affinity between threads and callback 
context. Unfortunately, D relies on Thread Local Storage for 
semi global data. This would be error prone. I saw such error 
case with people using TLS with Corba.


It is possible to set thread CPU affinity. Usage of TLS is also 
crucial in high performance fiber-based async systems (as soon as 
you have multiple threads) - for example, to implement lock-free 
TLS cache for all fibers running on that worker thread.

Re: Async or event library

[Kagamin via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 08:19:26 UTC, chmike wrote:
At the bottom of the wiki page there is an innocent question 
regarding TLS which is quite devastating. A worker thread pool 
system would not support affinity between threads and callback 
context. Unfortunately, D relies on Thread Local Storage for 
semi global data. This would be error prone. I saw such error 
case with people using TLS with Corba.


You can declare global data with shared qualifier:

int data; //TLS
shared int data; //global

On Thursday, 5 May 2016 at 08:28:36 UTC, chmike wrote:
I would like to add that the switchable TLS is only a half 
backed solution. It would't work in a multi core context where 
threads are truly executing in parallel. Two such threads might 
get the same TLS context which would invalidate its implicit 
predicate.


If TLS doesn't work, it's a bug in TLS implementation. I don't 
think such bug exists. AFAIK TLS works fine on multicore systems.

Re: Async or event library

[rikki cattermole via Digitalmars-d-learn]

On 06/05/2016 9:40 PM, chmike wrote:

On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote:

Event loops needs to be thread local not per process.
So many API's such as WinAPI for e.g. GUI's have this requirement in
it that its just not worth fighting over.


I don't understand. Do you mean that these event loops are single
threaded and thus don't allow multi threaded use and parallel event
handling ?

Single threaded model avoids the overhead of synchronization. That would
be another strong argument in favor of single threaded event loop. And
another one is that single threaded application is much easier to get
right than multi threaded applications.

On the other side, WinAPI is old and the actual hardware evolution goes
toward multi core computers and massive true parallelism. At CERN we use
16 core computers. Of course it's good to be backward compatible with
existing APIs but D should be designed to best match the future of
computing I think.

So it seam the question boils down to determine if it's possible to have
the best in both worlds.

I agree that event loops working in isolation is the most simple API
from the user perspective and is the most efficient since
synchronization can be avoided. But worker thread pools has also its
advantages when the app is running on a multicore computer.


Not even close :)

API's such as WinAPI are designed so that an event loop is per thread. 
This limitation is quite useful. You can see these limitations in X11 as 
well.


E.g. you can't go around drawing in another thread for a window.

For example WinAPI's GetMessage function has "Retrieves a message from 
the calling thread's message queue." 
https://msdn.microsoft.com/en-nz/library/windows/desktop/ms644936(v=vs.85).aspx


We can't fight stuff like this, its just not possible :)

Re: Async or event library

[chmike via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 09:21:04 UTC, rikki cattermole wrote:

Event loops needs to be thread local not per process.
So many API's such as WinAPI for e.g. GUI's have this 
requirement in it that its just not worth fighting over.


I don't understand. Do you mean that these event loops are single 
threaded and thus don't allow multi threaded use and parallel 
event handling ?


Single threaded model avoids the overhead of synchronization. 
That would be another strong argument in favor of single threaded 
event loop. And another one is that single threaded application 
is much easier to get right than multi threaded applications.


On the other side, WinAPI is old and the actual hardware 
evolution goes toward multi core computers and massive true 
parallelism. At CERN we use 16 core computers. Of course it's 
good to be backward compatible with existing APIs but D should be 
designed to best match the future of computing I think.


So it seam the question boils down to determine if it's possible 
to have the best in both worlds.


I agree that event loops working in isolation is the most simple 
API from the user perspective and is the most efficient since 
synchronization can be avoided. But worker thread pools has also 
its advantages when the app is running on a multicore computer.

Tree in ddox-generated pages

[VlasovRoman via Digitalmars-d-learn]

Hey guys!
I have project with 3.5k strings of code. Now I'm writing 
documentation for this.
I'm using scod, ddox based generator, but after generation I get 
pages where all my modules is not grouped by packages. What i'm 
doing wrong? Thanks.

Re: Strange stack variable corruption error after calling extern(C) function

[cc via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 09:42:00 UTC, Benjamin Thaut wrote:

On Wednesday, 4 May 2016 at 17:53:32 UTC, cc wrote:


The OS is Win64 though the program is being compiled as 32-bit 
and I'm using the 32-bit distributed DLL.
fmod.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS 
Windows


Tried int and long as the return type, same issue both ways.  
Tried void too just in case, same thing though.


Could you please post the definition of FMOD_RESULT. Its 
possible that the create sound function returns it on stack and 
not inside a register. This is usually the case if FMOD_RESULT 
is defined as a struct in C/C++. But its hard to say. In your 
case I would actually look at the disassembly and step through 
it to see where its going wrong and messing up the stack.


In fmod_common.h:

typedef enum
{
FMOD_OK,/* No errors. */
FMOD_ERR_ALREADYLOCKED, /* Tried to call lock a 
second time before unlock was called. */

...
FMOD_RESULT_FORCEINT = 65536/* Makes sure this enum is 
signed 32bit. */

} FMOD_RESULT;


In D I defined it as  enum FMOD_RESULT : int { ... }

Re: parameter pack to inputRange

[Dicebot via Digitalmars-d-learn]

On Friday, 6 May 2016 at 06:08:24 UTC, Dicebot wrote:
Unless parameter list is very (very!) long, I'd suggest to 
simply copy it into a stack struct. Something like this:


auto toInputRange (T...) (T args)
{
struct Range
{
T args;
size_t index;

T[0] front () { return args[index]; }
void popFront () { ++index; }
bool empty () { return index >= args.length; }
}

return Range(args, 0);
}


(note that you can actually make it random access range and not 
just input range, I simply have not defined required methods)

Re: parameter pack to inputRange

[Dicebot via Digitalmars-d-learn]

Unless parameter list is very (very!) long, I'd suggest to simply 
copy it into a stack struct. Something like this:


auto toInputRange (T...) (T args)
{
struct Range
{
T args;
size_t index;

T[0] front () { return args[index]; }
void popFront () { ++index; }
bool empty () { return index >= args.length; }
}

return Range(args, 0);
}

Re: what's the right way to get char* from string?

[ZombineDev via Digitalmars-d-learn]

On Thursday, 5 May 2016 at 07:49:46 UTC, aki wrote:

Hello,

When I need to call C function, often need to
have char* pointer from string.

"Interfacing to C++" page:
https://dlang.org/spec/cpp_interface.html
have following example.

extern (C) int strcmp(char* string1, char* string2);
import std.string;
int myDfunction(char[] s)
{
return strcmp(std.string.toStringz(s), "foo");
}

but this is incorrect because toStringz() returns immutable 
pointer.

One way is to write mutable version of toStringz()

char* toStringzMutable(string s) @trusted pure nothrow {
auto copy = new char[s.length + 1];
copy[0..s.length] = s[];
copy[s.length] = 0;
return copy.ptr;
}

But I think this is common needs,
why it is not provided by Phobos?
(or tell me if it has)

Thanks,
aki


In this particular case, if you `import core.stdc.string : 
strcmp`, instead of providing your own extern declaration it 
should work, because in there the signature is correctly typed as 
`in char*` which is essentially the same as `const(char*)` which 
can accept both mutable, const and immutable arguments. Also it 
has the correct attributes so you can call it from `pure`, 
`nothrow` and `@nogc` code.


As others have said, when you do need to convert a string slice 
to a pointer to a null terminated char/wchar/dchar string, 
`toUTFz` can be very useful.


But where possible, you should prefer functions that take an 
explicit length parameter, so you can avoid memory allocation:


```
string s1, s2;
import std.algorithm : min;
import core.stdc.string : strncmp;
strncmp(s1.ptr, s2.ptr, min(s1.length, s2.length));
// (`min` is used to prevent the C function from
// accessing data beyond the smallest
// of the two string slices).
```

Also string slices that point to a **whole** string literal are 
automatically null-terminated:


```
// lit is zero-terminated
string lit = "asdf";
assert (lit.ptr[lit.length] == '\0');
assert (strlen(lit.ptr) == lit.length);
```

However you need to be very careful, because as soon as you make 
a sub-slice, this property disappears:


```
// slice is not zero-terminated.
string slice = lit[0..2];
assert (slice.ptr[length] == 'd');
assert (strlen(slice.ptr) != slice.length);
```

This means that you can't be sure that a string slice is 
zero-termninated unless you can see it in your code that it 
points to a string literal and you're sure that it would never be 
changed to point to something else (like something returned from 
a function).

Re: parameter pack to inputRange

[Erik Smith via Digitalmars-d-learn]

On Friday, 6 May 2016 at 05:20:50 UTC, Ali Çehreli wrote:

On 05/05/2016 10:00 PM, Erik Smith wrote:
Is there an existing way to adapt a parameter pack to an input 
range? I

would like to construct an array with it.  Example:

void run(A...) (A args) {
  Array!int a(toInputRange(args));
}



Just initialize an array with the arguments:

void run(A...) (A args) {
writeln([args]);
}

Ali


That's allocating a dynamic array though, right?  It seems like 
there should be a non-GC adaptor for this purpose (especially 
since I'm using std.container.array).


erik