Re: Fiber based UI-Toolkit

2017-07-10 Thread bauss via Digitalmars-d-learn

On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote:

On 2017-07-09 23:12, bauss wrote:

I believe OSX (possibly macOS too.) only allows it from the 
main thread.


Yes, that's correct. But what's the difference between OSX and 
macOS ;)


Well besides that it's newer versions of the OS, then nothing 
much I guess. It could potentially change such specs though.


Re: Fiber based UI-Toolkit

2017-07-10 Thread Gerald via Digitalmars-d-learn

On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote:

On 2017-07-10 15:37, Gerald wrote:

Having said that, I'm in the camp where this doesn't make much 
sense. Using fibers on the main UI thread is likely going to 
result in a blocked UI whenever a fiber takes too long to do 
its work. History has shown that cooperative multi-tasking 
typically doesn't work well for UI applications.


It's that basically the whole idea of async/await? Seems like 
Microsoft is pushing quite heavily for that in GUI code.


Thanks for the link, I'm not active with .Net so I had to go look 
it up. Reminds me a lot of the way node.js works. If all your 
async activity is IO bound maybe it works fine and I'm wrong 
about this.



My past experience has been that it's challenging to determine 
the appropriate times to yield particularly with a lot of async 
activity happening. However with it baked into the framework and 
a simplified API maybe it becomes less of an issue.


I'll have to do more reading on it, again thanks for the pointer.





Re: Why no offsetof for static struct?

2017-07-10 Thread Mike Parker via Digitalmars-d-learn

On 7/11/2017 6:14 AM, FoxyBrown wrote:

On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:


No, it isn't. Static members are stored in an entirely different place 
than non-static members. They are really just global variables in 
memory with their in-source name being nested somewhere else.



This is not true, just because there isn't any official statement, or 
even if denied, does not make it true. I have proof:


auto GetStaticAddress(T)()
{
 mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
 return p;
}


Returns the address of a struct's static members.

It's pretty obvious, the compiler seems to instantiate the static 
members simply as a sort of "singleton". They are laid out with the same 
relative offsets as the struct(which is obvious, as that is the most 
natural way). That is all that is needed to treat the memory the static 
variables use as the struct in which they are part of. No need to make 
it any more complex than that.




Every variable has an address. That includes static members of a struct. 
But their location has absolutely no relationship to any instance of a 
struct. They have a fixed location in memory. Consider:


module Foo;
int x;
struct Bar {
static int y;
int z;
}

There is effectively no difference between x and y here. The only 
difference is that Bar is part of y's namespace, so you can access them 
like so:


Foo.x;
Foo.Bar.y;

y's location has no relationship to any instance of Bar, and the 
declaration of the Bar type has no address. Of course you can take the 
address of y, as , but you can also take the address of x. Take y 
out of Bar and the only difference is that you no longer need Bar as 
part of the namespace.  On the other hand:


Bar b;
writeln(b.z);

As an instance of Bar, b *does* have a location in memory. And z *does* 
have an offset that is relative to that location.


So y.offsetof does not exist, because there is no instance of Bar to 
which it can have a relative address.





Re: Debugging D applications from VS code with webfreak.debug

2017-07-10 Thread Domain via Digitalmars-d-learn

On Friday, 24 February 2017 at 13:19:53 UTC, FR wrote:

On Friday, 24 February 2017 at 03:15:11 UTC, Jerry wrote:
You can use the C++ plugin, which provides a debugger. Just 
make sure you aren't using optlink, I don't think it generates 
compatible files. Also you might need to use "-gc" which 
generates debug names to be in C format.


https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools

You might also need to enable breakpoints anywhere in VS code 
user setting file.



Awesome! After finding the right combination of flags (-g and 
-m64 fed to dmd via dflags-dmd in my dub.json) this works quite 
nicely. Thanks a lot!

Is there anywhere I can contribute this as documentation?


I cannot debug my app with mago-mi. I click debug button, but 
nothing happen. I have installed cpptools, mago-mi, 
webfreak.debug, and I have tried vscode-dlang and code-d. My 
launch.json:


{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "mago-mi",
"request": "launch",
"target": "${workspaceRoot}/bin/exp.exe",
"cwd": "${workspaceRoot}",
"preLaunchTask": "build"
}
]
}


stacktrace for InvalidMemoryOperationError

2017-07-10 Thread crimaniak via Digitalmars-d-learn

Hi!

I have vibe.d application and long-standing error in it.
For the current moment, I have logs for stdout, stderr, and 
additional log to write exceptions I catch. This error gives me 
only the short line in stderr log:


core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid 
memory operation


Also, I use registerMemoryErrorHandler(); (see 
http://vibed.org/docs#handling-segmentation-faults )


What else can I do to have the stack trace for this error?

I can't debug it because I don't have it on my developer's 
machine.


Re: Cannot dup an associative array but why?

2017-07-10 Thread Jean-Louis Leroy via Digitalmars-d-learn

On Monday, 10 July 2017 at 19:11:37 UTC, Ali Çehreli wrote:

On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote:
> Is there something special about ClassInfo that confuses?
Look at this
> example:
>
> struct Foo
> {
>
> }
>
> class Bar
> {
> }
>
> void main()
> {
>   Foo*[Bar] a;
>   auto aa = a.dup; // OK
>   Foo*[ClassInfo] b; // Error: static assert  "cannot call
> Foo*[TypeInfo_Class].dup because Foo* is not copyable"

I think you're hitting the same TypeInfo.init issue again. :/ 
This is the assert that fails inside object.dup:


static assert(is(typeof({ V v = aa[K.init]; })),
"cannot call " ~ T.stringof ~ ".dup because " ~ 
V.stringof ~ " is not copyable");


Jean-Louis, a little more patience please. :) Hopefully this 
will be resolved with 2.075, which you should be able to test 
yourself already. (?) 2.075 is in its fourth beta release.


Ali


Howdy Ali ;-)

Aaaah...those rough edges you were talking about at CppNow?

FYI, having a lot of fun. See 
https://github.com/jll63/meth.d/blob/experiments/source/meth/examples/adventure.d


At the time being, I'm hijacking ClassInfo.deallocator. I hope it 
will live through the next iteration of D.


Re: Why no offsetof for static struct?

2017-07-10 Thread Ali Çehreli via Digitalmars-d-learn

On 07/10/2017 02:14 PM, FoxyBrown wrote:
> On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:
>> On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:
>>> Cannot get the offset of static members of a struct
>>
>> That's because static members do not have an offset. They are not part
>> of the struct in memory, just in name.
>>
>>> We can clearly get a pointer to the static struct X
>>
>> There's barely any such thing as a static struct. That's just a struct
>> that stands without outside context which is almost all structs,
>> actually, so the term isn't special.
>>
>>> since  is effectively the address of X(regardless nomenclature
>>> and terminology issues in D trying to hide this).
>>
>> No, it isn't. Static members are stored in an entirely different place
>> than non-static members. They are really just global variables in
>> memory with their in-source name being nested somewhere else.
>
>
> This is not true, just because there isn't any official statement, or
> even if denied, does not make it true. I have proof:
>
> auto GetStaticAddress(T)()
> {
> mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
> return p;
> }
>
>
> Returns the address of a struct's static members.

Yes but that address is not offset from the beginning of any struct 
object. What would be its relationship to the following two objects?


import std.stdio;

auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

struct S {
static int s;
int m;
}

void main() {
writeln("S.s is at ", GetStaticAddress!S);
auto a = S();
auto b = S();
writeln("a   is at ", );
writeln("b   is at ", );
}

Prints

S.s is at 7F6D68484710
a   is at 7FFEADF41B68
b   is at 7FFEADF41B6C

So there is no offset of S.s to speak of (i.e. number of bytes from the 
beginning of) neither from a nor b.


> It's pretty obvious, the compiler seems to instantiate the static
> members simply as a sort of "singleton".

Makes sense.

> They are laid out with the same
> relative offsets as the struct(which is obvious, as that is the most
> natural way). That is all that is needed to treat the memory the static
> variables use as the struct in which they are part of. No need to make
> it any more complex than that.

S.s is sitting in memory all by itself without are relation to any other 
S members.


> Just because D obfuscates that static structs have addresses, doesn't
> mean they don't.

I assume you mean "static members". Then, yes, of course they have 
addresses. And you don't even need a function like GetStaticAddress():


writeln("S.s is at ", );

> No need to perpetuate a misnomer. Static structs and
> classes have addresses.

Again, I think you mean "static members of" or "instances of" structs 
and classes.


Ali



Re: Why no offsetof for static struct?

2017-07-10 Thread FoxyBrown via Digitalmars-d-learn

On Monday, 10 July 2017 at 20:13:46 UTC, Adam D. Ruppe wrote:

On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:

Cannot get the offset of static members of a struct


That's because static members do not have an offset. They are 
not part of the struct in memory, just in name.



We can clearly get a pointer to the static struct X


There's barely any such thing as a static struct. That's just a 
struct that stands without outside context which is almost 
all structs, actually, so the term isn't special.


since  is effectively the address of X(regardless 
nomenclature and terminology issues in D trying to hide this).


No, it isn't. Static members are stored in an entirely 
different place than non-static members. They are really just 
global variables in memory with their in-source name being 
nested somewhere else.



This is not true, just because there isn't any official 
statement, or even if denied, does not make it true. I have proof:


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}


Returns the address of a struct's static members.

It's pretty obvious, the compiler seems to instantiate the static 
members simply as a sort of "singleton". They are laid out with 
the same relative offsets as the struct(which is obvious, as that 
is the most natural way). That is all that is needed to treat the 
memory the static variables use as the struct in which they are 
part of. No need to make it any more complex than that.


Just because D obfuscates that static structs have addresses, 
doesn't mean they don't. No need to perpetuate a misnomer. Static 
structs and classes have addresses.


No, it might not be officially supported and the compiler may end 
up doing something funky, but it works, and works as it should, 
and should become part of D because it is useful:


auto GetOpts(T)(string[] args)
{   
import std.getopt, std.meta, std.traits;
auto t = GetStaticAddress!(T)();

string combine()
{
string s = "";
foreach(m; AliasSeq!(__traits(allMembers, T)))
{
mixin("enum a = __traits(getAttributes, T."~m~")[0];");
mixin("s ~= \"`"~a~"`, &"~T.stringof~"."~m~", \";");
}
return s;
}

enum s = combine();
mixin("return getopt(args, "~s~");");
}

struct X
{
align(1):
__gshared public static:
@("A") bool A;
@("B") string B;  
@("C") string[] C;
};


which allows us to do

GetOps!X(args)

vs

getop(args, "A", , "B", , "C", );


replaces the overly verbose getopt. Tell me that isn't useful and 
tell me that static structs don't have addresses!






Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

2017-07-10 Thread ketmar via Digitalmars-d-learn

NoBigDeal256 wrote:

Do you happen 
to have a link to the bug report for this specific issue that I could 
look at? I looked at the known bugs list and couldn't find anything 
related to this.


nope. it is a kind of "known bug nobody bothered to report". ;-)


Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

2017-07-10 Thread NoBigDeal256 via Digitalmars-d-learn

On Monday, 10 July 2017 at 20:31:12 UTC, ketmar wrote:

NoBigDeal256 wrote:

I'm currently learning D and started working on one of my 
first projects which is an API wrapper. I'm currently having 
an issue with my program getting a InvalidMemoryOperationError 
upon exiting the process on Windows 7. On my Debian VM I get a 
segmentation fault.


known bug in curl finalization on program exit. should be fixed 
in the next release. for now you have to live with it, or build 
your own phobos.


Ah. It's interesting that it works perfectly fine when used 
directly in main, and only becomes an issue when it's a struct 
member. Do you happen to have a link to the bug report for this 
specific issue that I could look at? I looked at the known bugs 
list and couldn't find anything related to this.


Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

2017-07-10 Thread ketmar via Digitalmars-d-learn

NoBigDeal256 wrote:

I'm currently learning D and started working on one of my first projects 
which is an API wrapper. I'm currently having an issue with my program 
getting a InvalidMemoryOperationError upon exiting the process on Windows 
7. On my Debian VM I get a segmentation fault.


known bug in curl finalization on program exit. should be fixed in the next 
release. for now you have to live with it, or build your own phobos.


Re: Having a strange issue with std.net.curl.HTTP as a struct dependency

2017-07-10 Thread NoBigDeal256 via Digitalmars-d-learn
Still haven't figured out what's wrong. Any help would be 
appreciated.


Why no offsetof for static struct?

2017-07-10 Thread FoxyBrown via Digitalmars-d-learn

Cannot get the offset of static members of a struct

struct X
{
__gshared public:
int x;
}


X.x.offsetof < invalid.

We can clearly get a pointer to the static struct X since  is 
effectively the address of X(regardless nomenclature and 
terminology issues in D trying to hide this).


e.g.,

auto p = cast(X*)

will, for all practical purposes be a pointer to X.


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

Of course, assuming that the first member is at the same location 
as the start of the struct and the elements are laid out in the 
same positions(not sure if this is guaranteed, but probably is).


Would be much nicer if we could just take the address of a static 
struct




This is pretty useful for simplification:

auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

auto GetOpts(T)(string[] args)
{   
import std.getopt, std.meta, std.traits;
auto t = GetStaticAddress!(T)();

string combine()
{
string s = "";
foreach(m; AliasSeq!(__traits(allMembers, T)))
{
mixin("enum a = __traits(getAttributes, T."~m~")[0];");
mixin("s ~= \"`"~a~"`, &"~T.stringof~"."~m~", \";");
}
return s;
}

enum s = combine();
mixin("return getopt(args, "~s~");");
}

struct X
{
align(1):
__gshared public static:
@("A") bool A;
@("B") string B;  
@("C") string[] C;
};


which allows us to do

GetOps!X(args)

vs

getop(args, "A", , "B", , "C", );


Could be improved to only deal with special argument attributes 
on X's fields and allow for non-static strucs(for the general 
case of mapping). Sort of a map between attribute space on a type 
and some function.







Re: Why no offsetof for static struct?

2017-07-10 Thread Adam D. Ruppe via Digitalmars-d-learn

On Monday, 10 July 2017 at 20:01:39 UTC, FoxyBrown wrote:

Cannot get the offset of static members of a struct


That's because static members do not have an offset. They are not 
part of the struct in memory, just in name.



We can clearly get a pointer to the static struct X


There's barely any such thing as a static struct. That's just a 
struct that stands without outside context which is almost 
all structs, actually, so the term isn't special.


since  is effectively the address of X(regardless 
nomenclature and terminology issues in D trying to hide this).


No, it isn't. Static members are stored in an entirely different 
place than non-static members. They are really just global 
variables in memory with their in-source name being nested 
somewhere else.




Foreign threads in D code.

2017-07-10 Thread Igor Shirkalin via Digitalmars-d-learn

Hello!

I have written some D code that I need to link to :C++ huge 
project. Let it be just one function that uses GC. The question 
is: if C++ code creates several threads and runs this :D function 
simultaneously, will GC work correctly?


p.s. Of course the druntime is initialized before it.

Igor Shirkalin




Why no offsetof for static struct?

2017-07-10 Thread FoxyBrown via Digitalmars-d-learn

Cannot get the offset of static members of a struct

struct X
{
__gshared public:
int x;
}


X.x.offsetof < invalid.

We can clearly get a pointer to the static struct X since  is 
effectively the address of X(regardless nomenclature and 
terminology issues in D trying to hide this).


e.g.,

auto p = cast(X*)

will, for all practical purposes be a pointer to X.


auto GetStaticAddress(T)()
{
mixin("auto p = cast(T*)"~__traits(allMembers, T)[0]~";");
return p;
}

Of course, assuming that the first member is at the same location 
as the start of the struct and the elements are laid out in the 
same positions(not sure if this is guaranteed, but probably is).


Would be much nicer if we could just take the address of a static 
struct





Re: Cannot dup an associative array but why?

2017-07-10 Thread Ali Çehreli via Digitalmars-d-learn

On 07/10/2017 11:46 AM, Jean-Louis Leroy wrote:
> Is there something special about ClassInfo that confuses? Look at this
> example:
>
> struct Foo
> {
>
> }
>
> class Bar
> {
> }
>
> void main()
> {
>   Foo*[Bar] a;
>   auto aa = a.dup; // OK
>   Foo*[ClassInfo] b; // Error: static assert  "cannot call
> Foo*[TypeInfo_Class].dup because Foo* is not copyable"

I think you're hitting the same TypeInfo.init issue again. :/ This is 
the assert that fails inside object.dup:


static assert(is(typeof({ V v = aa[K.init]; })),
"cannot call " ~ T.stringof ~ ".dup because " ~ V.stringof ~ " 
is not copyable");


Jean-Louis, a little more patience please. :) Hopefully this will be 
resolved with 2.075, which you should be able to test yourself already. 
(?) 2.075 is in its fourth beta release.


Ali



Cannot dup an associative array but why?

2017-07-10 Thread Jean-Louis Leroy via Digitalmars-d-learn
Is there something special about ClassInfo that confuses? Look at 
this example:


struct Foo
{

}

class Bar
{
}

void main()
{
  Foo*[Bar] a;
  auto aa = a.dup; // OK
  Foo*[ClassInfo] b; // Error: static assert  "cannot call 
Foo*[TypeInfo_Class].dup because Foo* is not copyable"
  auto bb = b.dup; // instantiated from here: 
dup!(Foo*[TypeInfo_Class], TypeInfo_Class, Foo*)}

}

'Foo*' is not copyable? Except that it is if the key is something 
else than ClassInfo? ClassInfo and Bar are both reference types 
though...


Re: iterate over variadic

2017-07-10 Thread ag0aep6g via Digitalmars-d-learn

On 07/10/2017 08:31 PM, H. S. Teoh via Digitalmars-d-learn wrote:

if (i % 2) {
// even


odd


... // do something with arg
} else {
// odd


even


... // do something with arg
}


Re: iterate over variadic

2017-07-10 Thread H. S. Teoh via Digitalmars-d-learn
On Sun, Jul 09, 2017 at 10:21:59PM +, FoxyBrown via Digitalmars-d-learn 
wrote:
> How can we iterate over a variadic and have it's index. I'll do
> different things depend on if it's an even or odd index, but seems to
> be no way to get it.

Easy:

auto func(Args...)(Args args) {
foreach (i, arg; args) {
if (i % 2) {
// even
... // do something with arg
} else {
// odd
... // do something with arg
}
}
}


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall


Re: CTFE output is kind of weired

2017-07-10 Thread H. S. Teoh via Digitalmars-d-learn
On Sun, Jul 09, 2017 at 06:48:30AM +, Stefan Koch via Digitalmars-d-learn 
wrote:
> On Sunday, 9 July 2017 at 04:03:09 UTC, H. S. Teoh wrote:
[...]
> > Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine
> > that should alleviate this limitation.
> > 
> > 
> > T
> 
> In fact ctfeWriteln harder to do for newCTFE then it is in the old
> interpreter.
[...]

Oh? Why is that?  Isn't it just a matter of adding a new opcode for
outputting a string?  Or calling an intrinsic function that the
interpreter recognizes as ctfeWriteln?


T

-- 
ASCII stupid question, getty stupid ANSI.


Re: Is runtime info in shared memory?

2017-07-10 Thread Ali Çehreli via Digitalmars-d-learn

On 07/09/2017 02:38 AM, Jean-Louis Leroy wrote:

When I look at ldc2's object.d I have the impression it's thread local.
I may be wrong though, just beginning to learn about 'shared'.


Unless it's marked as shared or __gshared it's thread-local by default.

Ali



Re: Get a string of a function name from a function pointer?

2017-07-10 Thread Ali Çehreli via Digitalmars-d-learn

On 07/10/2017 05:26 AM, SauceKode wrote:
> I need to pass a group of (C) function pointers to another language from
> D... is there a way to derrive a name from a function pointer? Or do I
> have to manually list out the names?

libunwind should be able to provide that functionality. Otherwise, no, 
the function pointer itself does not contain any additional information.


Ali



Re: problem overloading functions with complex enum type

2017-07-10 Thread Ali Çehreli via Digitalmars-d-learn

On 07/08/2017 08:23 AM, Eric wrote:

> enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
> enum BS : string[2] { a = ["5","6"], b = ["7","8"] };
>

> void funcs(AS a) { writeln("AS"); }
> void funcs(BS b) { writeln("BS"); }

> funcs(AS.a); // compiler error: matches both funcs(AS) and funcs(BS)

This looks like a bug to me.

Ali



Re: problem overloading functions with complex enum type

2017-07-10 Thread Lamex via Digitalmars-d-learn

On Saturday, 8 July 2017 at 15:23:10 UTC, Eric wrote:

import std.stdio;


check check one two


Re: pure factory function vs immutable(Foo)**

2017-07-10 Thread ag0aep6g via Digitalmars-d-learn

On 07/10/2017 05:42 PM, drug wrote:

10.07.2017 17:57, ag0aep6g пишет:

[...]

The error message is: "cannot implicitly convert expression (f(& p)) of
type immutable(int)** to immutable(int**)".

[...]

I'm not sure I understand, but
```
immutable (T)** r = f();
```
compiles. So compiler complains that indirections are mutable, but 
immutable ones are expected according to type of `r`


In itself, the error message makes sense. We can't usually convert from 
`immutable(int)**` to `immutable(int**)`.


We also can't usually convert from `int**` to `immutable(int**)`. But we 
can when the `int**` comes from a "pure factory function". And as far as 
I can see, it could/should also work when the pure factory function 
returns `immutable(int)**`.


For some context, I originally tried something like this:


struct S
{
string str;
int other_stuff;
}

void main()
{
import std.algorithm: map;
import std.array: array;
S[] structs;
immutable strs = structs.map!(s => s.str).array;
}



Re: pure factory function vs immutable(Foo)**

2017-07-10 Thread drug via Digitalmars-d-learn

10.07.2017 17:57, ag0aep6g пишет:

I feel like I must be missing something here.

This works:


alias T = int;

T** f(const T** input) pure
{
T** output;
return output;
}

void main()
{
T i;
T* p = 
immutable T** r = f();
}


`f` is `pure`, its parameter is const, and its return type has mutable
indirections. That makes it a "pure factory function" [1].

Since `f` is a pure factory function, the compiler can assume that the
result is not referenced from anywhere else. So I can declare it
`immutable`.

So far, so good.

Now change `T` to `alias T = immutable int;`. The program gets rejected.
The error message is: "cannot implicitly convert expression (f(& p)) of
type immutable(int)** to immutable(int**)".

What changed? `f` can now return a reference to `i`. But that's not a
problem, because that part of the return type is already `immutable`.
What would be a problem is if `f` could return a reference to `p`. But
it can't, as far as I can tell.

Am I missing something or could/should the program be accepted with `T =
immutable int`? What could `f` do that would break `r`'s immutability?


[1] https://dlang.org/spec/function.html#pure-functions

I'm not sure I understand, but
```
immutable (T)** r = f();
```
compiles. So compiler complains that indirections are mutable, but 
immutable ones are expected according to type of `r`




pure factory function vs immutable(Foo)**

2017-07-10 Thread ag0aep6g via Digitalmars-d-learn

I feel like I must be missing something here.

This works:


alias T = int;

T** f(const T** input) pure
{
T** output;
return output;
}

void main()
{
T i;
T* p = 
immutable T** r = f();
}


`f` is `pure`, its parameter is const, and its return type has mutable 
indirections. That makes it a "pure factory function" [1].


Since `f` is a pure factory function, the compiler can assume that the 
result is not referenced from anywhere else. So I can declare it 
`immutable`.


So far, so good.

Now change `T` to `alias T = immutable int;`. The program gets rejected. 
The error message is: "cannot implicitly convert expression (f(& p)) of 
type immutable(int)** to immutable(int**)".


What changed? `f` can now return a reference to `i`. But that's not a 
problem, because that part of the return type is already `immutable`. 
What would be a problem is if `f` could return a reference to `p`. But 
it can't, as far as I can tell.


Am I missing something or could/should the program be accepted with `T = 
immutable int`? What could `f` do that would break `r`'s immutability?



[1] https://dlang.org/spec/function.html#pure-functions


Re: Fiber based UI-Toolkit

2017-07-10 Thread Christian Köstlin via Digitalmars-d-learn
On 10.07.17 15:37, Gerald wrote:
> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out
>> for dlang. The second question is, if it would make sense at all to
>> have such a thing?
> 
> As previously noted, like other UI toolkits GTK maintains a single
> thread for processing UI events with an event loop running in that
> thread. GTK does support passing a function to be called when the main
> loop is idle, it could be possible to leverage this to manage fibers
> with appropriate yielding.
> 
> Having said that, I'm in the camp where this doesn't make much sense.
> Using fibers on the main UI thread is likely going to result in a
> blocked UI whenever a fiber takes too long to do its work. History has
> shown that cooperative multi-tasking typically doesn't work well for UI
> applications.
> 
> I think you would be much better off starting an additional thread and
> managing fibers in that thread outside the context of the main UI
> thread. You can then use things like std.concurrency to receive messages
> from the external thread to update the UI as needed in it's own thread.
Thanks for this answer,

my thinking was also in this direction.
I guess for many use cases fibers in ui could be good enough (like my
simple example, getting something from a webserver, (quickly) process it
and display it). given a fiber-based http-client, this could work quite
nicely. For real programs, with heavy transformation of the data,
I think this would not work so well, because either you block the ui
with the processing code in the fiber, or your processing code is not
running full speed, because it has some yields sprinkled throughout the
code.

On the other hand side, i also guess, that for ui and even more for
audio rendering, every tiny bit of delay can hurt the experience.

So probably not a good idea for a real world application?

Best regards,
Christian

p.s. i still wonder about jacobs argument about microsofts async/await.



Re: Fiber based UI-Toolkit

2017-07-10 Thread Jacob Carlborg via Digitalmars-d-learn

On 2017-07-10 15:37, Gerald wrote:

Having said that, I'm in the camp where this doesn't make much sense. 
Using fibers on the main UI thread is likely going to result in a 
blocked UI whenever a fiber takes too long to do its work. History has 
shown that cooperative multi-tasking typically doesn't work well for UI 
applications.


It's that basically the whole idea of async/await? Seems like Microsoft 
is pushing quite heavily for that in GUI code.


--
/Jacob Carlborg


Re: Fiber based UI-Toolkit

2017-07-10 Thread Gerald via Digitalmars-d-learn

On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
I wonder if there is any fiber based / fiber compatible 
UI-Toolkit out for dlang. The second question is, if it would 
make sense at all to have such a thing?


As previously noted, like other UI toolkits GTK maintains a 
single thread for processing UI events with an event loop running 
in that thread. GTK does support passing a function to be called 
when the main loop is idle, it could be possible to leverage this 
to manage fibers with appropriate yielding.


Having said that, I'm in the camp where this doesn't make much 
sense. Using fibers on the main UI thread is likely going to 
result in a blocked UI whenever a fiber takes too long to do its 
work. History has shown that cooperative multi-tasking typically 
doesn't work well for UI applications.


I think you would be much better off starting an additional 
thread and managing fibers in that thread outside the context of 
the main UI thread. You can then use things like std.concurrency 
to receive messages from the external thread to update the UI as 
needed in it's own thread.


Get a string of a function name from a function pointer?

2017-07-10 Thread SauceKode via Digitalmars-d-learn
I need to pass a group of (C) function pointers to another 
language from D... is there a way to derrive a name from a 
function pointer? Or do I have to manually list out the names?


Re: Application settings

2017-07-10 Thread Jacob Carlborg via Digitalmars-d-learn

On 2017-07-07 21:40, FoxyBrown wrote:
What's the "best" way to do this? I want something I can simply load at 
startup in a convenient and easy way then save when necessary(possibly 
be efficient at it, but probably doesn't matter).


Simply json an array and save and load it, or is there a better way?


I would say it depends on what kind of application and which platforms 
it supports. For GUI applications there's usually a native way to store 
application settings, which will be different on different platforms. 
For example, on macOS the NSUserDefaults class (Swift and Objective-C) 
is used, which will eventually store the settings in the plist format [1].


For CLI tools it seems quite common to store the settings in a file or 
directory in the user's home directory call .rc where  is the 
name, or short name, of the application. The actual format of these 
files vary between applications, platforms and which language they're 
implemented in. For example, it seems pretty common for tools written in 
Go to use the TOML format [2]. In D, the corresponding format would be 
SDLang [3].


Ideally, I'd like to store the settings as part of the binary to keep 
everything together but that poses a few issues I think.


I would say again that this depends on the kind of application and the 
platform.


[1] 
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/UserDefaults/Introduction/Introduction.html


[2] https://github.com/toml-lang/toml
[3] http://sdlang.org

--
/Jacob Carlborg


Re: Fiber based UI-Toolkit

2017-07-10 Thread Jacob Carlborg via Digitalmars-d-learn

On 2017-07-09 23:12, bauss wrote:


I believe OSX (possibly macOS too.) only allows it from the main thread.


Yes, that's correct. But what's the difference between OSX and macOS ;)

--
/Jacob Carlborg


Re: Fiber based UI-Toolkit

2017-07-10 Thread Jacob Carlborg via Digitalmars-d-learn

On 2017-07-09 21:43, Christian Köstlin wrote:

I wonder if there is any fiber based / fiber compatible UI-Toolkit out
for dlang. The second question is, if it would make sense at all to have
such a thing?


If I recall correctly, vibe.d has some form of integration with the 
native GUI event loop on Windows.


--
/Jacob Carlborg


Re: Fiber based UI-Toolkit

2017-07-10 Thread Christian Köstlin via Digitalmars-d-learn
On 10.07.17 00:23, Christian Köstlin wrote:
To elaborate on the previous post, I uploaded a small example, that
tries naively to mix dlangui with fibers. Please have a look at:
https://github.com/gizmomogwai/fibered-ui.git
For sure it does not work. The fiber in the callback is started,
but after the first yield, dlangui never returns to the fiber.
Does anybody know what needs to be done for that?

thanks a lot,
Christian

> On 09.07.17 23:12, bauss wrote:
>> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
>>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out
>>> for dlang. The second question is, if it would make sense at all to
>>> have such a thing?
>>>
>>> christian
>>
>> It doesn't really make sense to have that, because most (if not all)
>> operating systems only allow rendering from a single thread and I
>> believe OSX (possibly macOS too.) only allows it from the main thread.
>> Which means the only thing you can really operate on other threads are
>> events, but you'll always have to do callbacks to your UI thread in
>> order to render.
> Thanks for answering! you are touching exactly my question:
> Lets say, that all the event handling is done by fiber-aware code (means
> all io gives the thread free, when it would block, and perhaps
> a yield function for calculation heavy operations). It would then
> I think reduce the "risk" of a ANR (Application not responding (from
> android) or the famous beachball) without sacrificing the clarity of the
> code.
> 
> e.g. you want to download something from a webpage and process the data,
> if you click a button. you cannot do this in the buttons-onclick
> callback (because this is usually a long running operation and the
> callback is called from the main thread). with fibers, the main thread
> could continue running (and update the screen) as soon as the io thread
> is blocking or the process thread calls yield (which he should on a
> regular basis). after the processing as soon as the fiber gets back the
> control, the result can easily be integrated back into the ui, because
> its already in the right thread.
> compare this with the traditionally apporach of spawning a new thread,
> passing over the arguments, processing it, passing back the result and
> integrating this into the ui, it could perhaps be "simpler".
> 
> on the other hand, the process code would get a little bit messy because
> of the manually inserted yields (as far as i know, the erlang vm for
> example inserts such instructions automatically every n instructions).
> 
> what do you think?
>