Re: shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn 
wrote:
> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> > On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
> >> Oh really?!?! I thought slicing used the GC? Is this a recent
> >> development or always been that way?
> >
> > Always been that way. A D slice is just a C pointer + length
> > packed together. A slice simply increments the pointer and/or
> > decrements the length - no allocation needed.
> > (btw the garbage collector is actually pretty nice, why are you
> > avoiding it anyway?)
>
> Seems to be quite a lot of FUD wrt use of standard library and
> GC, which means also perhaps we don't communicate this point very
> well as a community.  Making Phobos GC-optional perhaps is an
> ultimate answer.  But people seem to think that you're back to C
> without the GC.

Aside from the few classes in Phobos, its GC usage is almost entirely
restricted to when it allocates arrays or when it has to allocate a closure
for a delegate, which can happen in some cases when passing predicates to
range-based algorithms. Avoiding functions that need to allocate arrays
avoids that source of allocation, and using functors or function pointers
as predicates avoids having to allocate closures. So, you _can_ end up with
GC allocations accidentally in Phobos if you're not careful, but on the
whole, the assertion that Phobos uses the GC heavily is FUD - or at least a
misunderstanding. But as we make more of the functions use lazy ranges
rather than arrays (particularly with regards to strings), and we make more
of the code @nogc, it becomes even clearer that the GC isn't involved. Also,
improvements to how lambdas are handled should reduce how often closures
have to be allocated for them.

Probably the may issue that actually requires a language change is that
exceptions currently pretty much have to be GC-allocated whereas they really
should be reference-counted (though possibly still GC-allocated, just not
left for a garbage collection cycle), but exceptions are thrown rarely,
meaning that the fact that they're GC allocated is really only a problem if
you're trying to avoid the GC completely rather than just minimize its use,
so it's rarely a problem. And there are plans to support reference-counted
types in the language, in which case, the exception types would be change to
use that Object hierarchy rather than the normal one.

So, we have improvements to make, but for the most part, I think that the
idea that Phobos requires a GC is FUD. It's not completely false, but folks
seem to think using Phobos means heavy GC usage, and for the most part,
that's not true at all.

- Jonathan M Davis

Re: Multidimension AA's and remove

[NX via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 05:54:13 UTC, NX wrote:

import std.stdio : writeln, std.algorithm.mutation : remove;


Ooops, this is so wrong! Corrected version:

void main()
{
import std.stdio : writeln;
import std.algorithm.mutation : remove;

int[][string] heh = [ "heh":[ 0, 10, 15, 20 ] ];
heh["heh"][0] = 5;
writeln(heh); // ["heh":[5, 10, 15, 20]]
heh["heh"] = remove!(c => (c == 15))(heh["heh"]);
writeln(heh); // ["heh":[5, 10, 20]]
}

Re: Multidimension AA's and remove

[NX via Digitalmars-d-learn]

On Saturday, 12 September 2015 at 03:44:50 UTC, Prudence wrote:
At the very least: Is T[][S] an associative array with keys of 
type S and values of an array of type T or is it backwards? 
Also, how to disambiguate


Thanks.


Indeed.

void main()
{
import std.stdio : writeln, std.algorithm.mutation : remove;

int[][string] heh = [ "hah":[ 0, 10, 15, 20 ] ];
heh["hah"][0] = 5;
foreach(var; heh["hah"])
writeln(var);
writeln();
heh["hah"] = remove!(c => (c == 15))(heh["hah"]);
foreach(var; heh["hah"])
writeln(var);
}
Giving me:
5
10
15
20

5
10
20

Multidimension AA's and remove

[Prudence via Digitalmars-d-learn]

Error: template std.algorithm.mutation.remove cannot deduce 
function from argument types !()(bool delegate(void*, uint, uint, 
int)[], void), candidates are:
std.algorithm.mutation.remove(SwapStrategy s = 
SwapStrategy.stable, Range, Offset...)(Range range, Offset 
offset) if (s != SwapStrategy.stable && 
isBidirectionalRange!Range && hasLvalueElements!Range && 
hasLength!Range && Offset.length >= 1)
std.algorithm.mutation.remove(SwapStrategy s = 
SwapStrategy.stable, Range, Offset...)(Range range, Offset 
offset) if (s == SwapStrategy.stable && 
isBidirectionalRange!Range && hasLvalueElements!Range && 
Offset.length >= 1)
std.algorithm.mutation.remove(alias pred, SwapStrategy s = 
SwapStrategy.stable, Range)(Range range) if 
(isBidirectionalRange!Range && hasLvalueElements!Range)



coming from

static TValue[][TKey] s;

(s[key]).remove(c => value == c);

How to disambiguate or do what I'm trying to do:

I'm trying to create an associative array with multiple values 
per key. Hence the AA with an extra dynamic array on it.


I've tried

TValue[TKey][] s;

and other stuff without success(essentially same error about not 
being able to deduce remove)


I would expect (s[key]) to return the normal array.

I've tried this too.
remove!(c => this.Value == c)(store[this.Key], 
SwapStrategy.unstable);




At the very least: Is T[][S] an associative array with keys of 
type S and values of an array of type T or is it backwards? Also, 
how to disabmiguate


Thanks.

Re: Is this a bug?

[Rene Zwanenburg via Digitalmars-d-learn]

On Friday, 11 September 2015 at 11:26:49 UTC, anonymous wrote:

On Friday 11 September 2015 12:33, Rene Zwanenburg wrote:

The following fails to compile with an 'cannot deduce function 
from argument types' error. When using an array of something 
other than TypeInfo_Class everything works as expected.


void main()
{
import std.algorithm.mutation : remove;

TypeInfo_Class[] arr;
TypeInfo_Class c;
arr = arr.remove!(a => a is c);
}


Yes, it's a bug. It should work.

The problem is that TypeInfo_Class has a method called "init" 
which shadows the built-in type property of the same name. This 
confuses ElementType.


I filed a bug: https://issues.dlang.org/show_bug.cgi?id=15037


Thanks, for both confirming and submitting the issue.

Re: shared array?

[Laeeth Isharc via Digitalmars-d-learn]

On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:

On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
Oh really?!?! I thought slicing used the GC? Is this a recent 
development or always been that way?


Always been that way. A D slice is just a C pointer + length 
packed together. A slice simply increments the pointer and/or 
decrements the length - no allocation needed.
(btw the garbage collector is actually pretty nice, why are you 
avoiding it anyway?)


Seems to be quite a lot of FUD wrt use of standard library and 
GC, which means also perhaps we don't communicate this point very 
well as a community.  Making Phobos GC-optional perhaps is an 
ultimate answer.  But people seem to think that you're back to C 
without the GC.

Re: friends with phobos, workaround?

[Daniel N via Digitalmars-d-learn]

On Thursday, 10 September 2015 at 13:19:08 UTC, Adam D. Ruppe 
wrote:

On Thursday, 10 September 2015 at 08:22:29 UTC, Daniel N wrote:
  this(string caller = __MODULE__)(int val) if(caller == 
"std.conv") // Use scoped!Awesome


That's disgustingly genius. I'm a bit jealous I didn't 
think of it myself!


One slight problem though: you couldn't call super() from a 
derived class, since the constructor wouldn't even exist due to 
the constraint.




super():
Hmm, yes that's a slight nuisance but manageable.

Thanks, coming from you that means a lot. :) Hmm, maybe I'll wait 
a week or two before I share my next trick to give you ample time 
to think of it also, meanwhile I'll just scribble it down in the 
margin of my copy of "D Cookbook". ;) ... just hope I didn't jinx 
myself now ...

Re: shared array?

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

On Friday, 11 September 2015 at 21:48:14 UTC, Prudence wrote:
Oh really?!?! I thought slicing used the GC? Is this a recent 
development or always been that way?


Always been that way. A D slice is just a C pointer + length 
packed together. A slice simply increments the pointer and/or 
decrements the length - no allocation needed.


GC can make slices more convenient, since you don't need to think 
about who owns that memory you're slicing to free it, but that's 
true of pointers and references and everything too.


you've done above) then release and remalloc when I need to 
append(not efficient but ok in my senario), then it won't use 
the GC?


yeah.

you might want to GC.addRange it though so the contents are 
scanned anyway...


(btw the garbage collector is actually pretty nice, why are you 
avoiding it anyway?)


I guess [] doesn't have a capacity field so I'll have to keep 
track of that. Other wise, it should be pretty simple.


Nope but you can just use realloc which does track some capacity 
for you. (Actually, the built-in ~= operator does that too, just 
with the GC instead of the C function. It sometimes won't 
reallocate because it knows it already has enough capacity. Read 
more here: http://dlang.org/d-array-article.html )

Re: best way to memoize a range?

[Laeeth Isharc via Digitalmars-d-learn]

On Friday, 11 September 2015 at 13:31:06 UTC, John Colvin wrote:
On Friday, 11 September 2015 at 13:09:33 UTC, Laeeth Isharc 
wrote:
obviously it's trivial to do with a little aa cache.  and I 
know I can memoize a function, and turn the memoized version 
into an infinite range.  but suppose I have a lazy function 
that returns a finite range, and its expensive to calculate.


can I use Phobos to produce a memoized range?  So it will 
calculate on access to an element if it needs to, but will 
return the cached value if it has been calculated before.


perhaps 
http://dlang.org/phobos/std_algorithm_iteration.html#.cache 
would do what you need. An AA based cache (with a normal range 
interface if you want) is probably the sensible way to get true 
random-access here, unless you have reasonably dense and 
monotonic accesses in which case an appender-based linear cache 
could work, either using Nullable!T or a separate list of bools 
(or bits) marking whether a result is cached yet.



Thanks, John and Jacob.


Laeeth.

Re: shared array?

[Prudence via Digitalmars-d-learn]

On Friday, 11 September 2015 at 20:30:37 UTC, Adam D. Ruppe wrote:

On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
Can you back up this claim? Not saying your lying, I'd just 
like to know it's true for a fact?


The list of things that trigger the GC is pretty short. See the 
bottom of this page:


http://dlang.org/garbage.html

Basically, the three things that can do a gc allocation in a 
built in array are: increasing the length, the ~= and ~ 
operators, and the [a,b,c] literal syntax.


Slicing, indexing, etc, the other basic operations do not.

If you do: ubyte[] a = (cast(ubyte*) malloc(4)[0..4];, it will 
compile... and create a slice from the malloced memory. That's 
one way to create an array without GCing it.



In that case, am I not essentially just re-creating Array?


Array does a lot of other stuff too... you only really need 
append and maybe shrink for a static variable, since tracking 
ownership doesn't matter (it is never disappearing since it is 
global)


Oh really?!?! I thought slicing used the GC? Is this a recent 
development or always been that way?


ok, so if I just use a shared [], and create it using malloc(as 
you've done above) then release and remalloc when I need to 
append(not efficient but ok in my senario), then it won't use the 
GC?


If so, then I can handle that! I guess [] doesn't have a capacity 
field so I'll have to keep track of that. Other wise, it should 
be pretty simple.


Of course, I still feel like I'm trying to implement array 
because everything turns in to "lots of stuff" at some point ;/

Re: How To: Passing curried functions around

[Ali Çehreli via Digitalmars-d-learn]

On 09/11/2015 02:04 PM, Ali Çehreli wrote:

The same keyword has a different use with
templates:


And the official documentation:

  http://dlang.org/template.html#TemplateAliasParameter

Ali

Re: How To: Passing curried functions around

[Ali Çehreli via Digitalmars-d-learn]

On 09/11/2015 01:07 PM, Bahman Movaqar wrote:
> On Friday, 11 September 2015 at 18:39:15 UTC, Ali Çehreli wrote:
>> >> import std.stdio;
>> >>
>> >> bool isEven(int n) {
>> >> return !(n % 2);
>> >> }
>> >>
>> >> int readValidInt(alias validator)(string prompt) {
>>
>> readValidInt() is a function template that takes two information:
>>
>> 1) The validator as its alias template parameter. alias template
>> parameter allows it to work with anything that can be called.
>
> I read "alias and with" chapter of the book to understand this but
> couldn't find any such use for `alias` there.  Does using `alias`
> instead of a type makes the parameter a `callable`?

Sorry for the confusion. :) The same keyword has a different use with 
templates:



http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.alias,%20template%20parameter

Ali

Re: shared array?

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

On Friday, 11 September 2015 at 20:06:53 UTC, Prudence wrote:
Can you back up this claim? Not saying your lying, I'd just 
like to know it's true for a fact?


The list of things that trigger the GC is pretty short. See the 
bottom of this page:


http://dlang.org/garbage.html

Basically, the three things that can do a gc allocation in a 
built in array are: increasing the length, the ~= and ~ 
operators, and the [a,b,c] literal syntax.


Slicing, indexing, etc, the other basic operations do not.

If you do: ubyte[] a = (cast(ubyte*) malloc(4)[0..4];, it will 
compile... and create a slice from the malloced memory. That's 
one way to create an array without GCing it.



In that case, am I not essentially just re-creating Array?


Array does a lot of other stuff too... you only really need 
append and maybe shrink for a static variable, since tracking 
ownership doesn't matter (it is never disappearing since it is 
global)

Re: Hello World Example with Glade?

[Mike Wey via Digitalmars-d-learn]

On 09/11/2015 04:00 PM, Mike McKee wrote:

On Friday, 11 September 2015 at 09:07:37 UTC, Jordi Sayol wrote:

On  there is the "pkg-config" section:


I finally got it to compile with your help, guys! :)

Here's what I had to type:

# dmd test1.d -L-ldl -I/usr/include/dmd/gtkd3 `pkg-config --cflags
--libs gtkd3`



You should be able to drop the -L-ldl and -I/usr/ flags, as they are 
included in the pkg-config output.


--
Mike Wey

Re: How To: Passing curried functions around

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 18:39:15 UTC, Ali Çehreli wrote:

>> import std.stdio;
>>
>> bool isEven(int n) {
>> return !(n % 2);
>> }
>>
>> int readValidInt(alias validator)(string prompt) {

readValidInt() is a function template that takes two 
information:


1) The validator as its alias template parameter. alias 
template parameter allows it to work with anything that can be 
called.


I read "alias and with" chapter of the book to understand this 
but couldn't find any such use for `alias` there.  Does using 
`alias` instead of a type makes the parameter a `callable`?

Re: shared array?

[Prudence via Digitalmars-d-learn]

On Friday, 11 September 2015 at 19:27:49 UTC, Adam D. Ruppe wrote:

On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
I don't care about "maybe" working. Since the array is hidden 
inside a class I can control who and how it is used and deal 
with the race conditions.


You could use __gshared instead of shared. It means put it in 
non-tls storage, just like shared, but the compiler will not 
attempt to help you use it correctly; you're on your own for 
synchronization, etc.


What I want is to be able to use Array so I don't have to rely 
on the GC.


But, again, built-in slices do NOT rely on the GC. Only 
specific methods on them do and you can use your own 
implementation for them.


Really?

Can you back up this claim? Not saying your lying, I'd just like 
to know it's true for a fact?


Ho wan you use "specific methods"? Do you mean I do not use new 
to allocate and use malloc(more or less)?


In that case, am I not essentially just re-creating Array? 
Obviously I can write my own array type and I can even write my 
own compiler, but that's no that the point, is it?

Re: Multiple implicit type converters

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

On Friday, 11 September 2015 at 19:51:09 UTC, Dave Akers wrote:

Would it be possible to create it as an 'as' template?


Yeah, the way I'd do it is something like:

T as(T)() {
   import std.traits;
   static if(isIntegral!T)
   return to!T(convert_to_some_int);
   else static if(isSomeString!T)
   return to!T(convert_to_some_string);
   else /// and so on and so forth
}


These isX templates from std.traits will help you break down a 
gazillion potential types into just a handful of type families 
which are easier to handle.


But you could also just static if(is(T == something)) or whatever 
to list the types you do want to support.

Re: Multiple implicit type converters

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 19:51:09 UTC, Dave Akers wrote:

That's enough for me, I suppose.
I am thinking of having a family of functions in my 
structs/classes as `as` family, such as `asDouble`, `asFooBar`.


Would it be possible to create it as an 'as' template?


Hmm...there's already the `to` template, right?

Re: Multiple implicit type converters

[Dave Akers via Digitalmars-d-learn]

On Friday, 11 September 2015 at 19:34:46 UTC, Bahman Movaqar 
wrote:

On Friday, 11 September 2015 at 16:33:52 UTC, Meta wrote:
The only ways to get implicit conversion between two types in 
D are through `alias this`, inheritance, or implementing an 
interface.


That's enough for me, I suppose.
I am thinking of having a family of functions in my 
structs/classes as `as` family, such as `asDouble`, `asFooBar`.


Would it be possible to create it as an 'as' template?

Re: Calling D from C, C++, Python…

[Jacob Carlborg via Digitalmars-d-learn]

On 2015-09-10 20:01, Russel Winder via Digitalmars-d-learn wrote:

Is there an easy way of knowing when you do not have to initialize the
D runtime system to call D code from, in this case, Python via a C
adapter?


You always need to initialize the D runtime, unless you have a D main 
function. You can initialize the runtime as many times you like, 
assuming you also deinitialize it the same number of times.


--
/Jacob Carlborg

Re: Multiple implicit type converters

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 16:33:52 UTC, Meta wrote:
The only ways to get implicit conversion between two types in D 
are through `alias this`, inheritance, or implementing an 
interface.


That's enough for me, I suppose.
I am thinking of having a family of functions in my 
structs/classes as `as` family, such as `asDouble`, `asFooBar`.

Re: Multiple implicit type converters

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 16:31:46 UTC, Adam D. Ruppe wrote:
explicit is the only way to go. That's easy to do, just write 
like a .get method or something that does the conversion and 
returns it.


Fair enough.  Type conversion is one of those spots that I'd like 
it to as explicit as possible.

Re: shared array?

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

On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
I don't care about "maybe" working. Since the array is hidden 
inside a class I can control who and how it is used and deal 
with the race conditions.


You could use __gshared instead of shared. It means put it in 
non-tls storage, just like shared, but the compiler will not 
attempt to help you use it correctly; you're on your own for 
synchronization, etc.


What I want is to be able to use Array so I don't have to rely 
on the GC.


But, again, built-in slices do NOT rely on the GC. Only specific 
methods on them do and you can use your own implementation for 
them.

Re: Huge output size for simple programs

[Johannes Pfau via Digitalmars-d-learn]

Am Fri, 11 Sep 2015 05:36:27 -0700
schrieb Jonathan M Davis via Digitalmars-d-learn
:

> Now, as to why the gdc binary is so large, I don't know. My guess is
> that it has something to do with the debug symbols. You could try
> building with -g or -gc to see how that affects the dmd-generated
> binary.

The libphobos shipped with the GDC binaries or with a self-compiled GDC
does contain debug information (default GCC policy IIRC?). That combined
with static linking leads to huge executables. A simple 'strip' command
reduces the executable size.

Re: How To: Passing curried functions around

[Ali Çehreli via Digitalmars-d-learn]

On 09/11/2015 02:41 AM, Bahman Movaqar wrote:
> On Friday, 11 September 2015 at 06:14:18 UTC, Ali Çehreli wrote:
>> partial takes the function arguments as 'value template parameters'.
>> Unfortunately, a function pointer like &isEven cannot be 'value
>> template parameters'; only fundamental types and strings can... So,
>> 'partial' is not an option for this problem.
>
> Ah...now I understand the mysterious compiler errors.

I was wrong there: 'partial' does take its arguments as alias template 
parameters but it still doesn't work probably because of a compiler or 
language issue:


import std.functional;

alias Validator = bool function(int);

bool condition(int)
{
return true;
}

void foo(Validator validator)
{
validator(42);
}

void main()
{
alias f = partial!(foo, condition);// <-- ERROR
}

/usr/include/dmd/phobos/std/functional.d(662): Error: function 
deneme.condition (int _param_0) is not callable using argument types ()
/usr/include/dmd/phobos/std/functional.d(662): Error: cannot return 
non-void from void function


I wouldn't expect an actual call for that line of code but the compiler 
thinks that there is a call to condition() without a parameter. (This 
may be related to a syntax issue caused by no-parameter functions being 
called without parentheses.)


>> Idiomatic D uses templates and passes behavior in the form of 'alias
>> template parameters.' Alias template parameters are the convenient way
>> of allowing anything that is callable, not just functions. For
>> example, foo() would be much more useful if it allowed a delegate or a
>> class object that has an overloaded opCall() operator.
>
> True.  I guess I was just pushing D functions too far.

Not necessarily. You can do the same thing with function pointers as 
well but I don't think 'partial' has much to offer over a lambda. I am 
guessing that partial predates lambdas. (?)


>>   http://ddili.org/ders/d.en/parallelism.html
>>
>> (Search for "The task function above has been specified as a template
>> parameter" on that page.)
>
> Actually, I *am* using your book (which is, by the way, very well
> written) plus the language specs to learn D.  However, that section yet
> too advance for me to touch :-)
>
>> import std.stdio;
>>
>> bool isEven(int n) {
>> return !(n % 2);
>> }
>>
>> int readValidInt(alias validator)(string prompt) {

readValidInt() is a function template that takes two information:

1) The validator as its alias template parameter. alias template 
parameter allows it to work with anything that can be called.


2) The prompt as its function parameter.

>> while (true) {
>> int i;
>> write(prompt);
>> readf(" %s", &i);
>> if (validator(i)) {
>> return i;
>> } else {
>> writeln("Sorry, that's not acceptable");
>> }
>> }
>> }

The should be obvious.

>> void foo(alias reader)() {
>> reader();
>> }

Another function template that takes a callable entity and calls it.

>> void main() {
>> auto reader = () => readValidInt!isEven("Enter an integer: ");

The syntax above creates a lambda with this definition: Call 
readValidInt!isEven with the string argument "Enter an integer: ".


>> foo!reader();

foo takes that lambda. When foo eventually calls the lambda, 
readValidInt!isEven("Enter an integer: ") will be called.


>> }
>>
>> You can add template constraints to make the code easier to use.
>
> Clean one!  Even though I don't know what's going behind the scenes, I
> can easily read and understand it.
>
> Thanks for the help.

Ali

Re: shared array?

[Prudence via Digitalmars-d-learn]

On Friday, 11 September 2015 at 16:04:22 UTC, Kagamin wrote:

On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
But in this case it is static, so why does it matter? Do you 
have any ideas how to wrap it or fix this?


It matters exactly because it is static. A code written for 
single-threaded environment may not work correctly in shared 
context. It simply wasn't written for it. The way to fix it is 
to write code for shared context.


I don't care about "maybe" working. Since the array is hidden 
inside a class I can control who and how it is used and deal with 
the race conditions.


What I want is to be able to use Array so I don't have to rely on 
the GC. but since it complains about the ~this destruction, how 
can I fix that? If I wrap Array, and use a non-shared array 
inside it, I'll  still have the same problem because it will be 
thread local to the object? or is shared applied to all sub types 
of a class?


e.g.,

class MySharedArrayWrapper
{
static Array!(int) a;

}

and instead I use

static shared MySharedArrayWrapper;

But a isn't marked shared, so will it be TLS, which put's me back 
at square one. Or it it marked shared, which then still complains?


Again, I'm asking how, not why.

Re: Multiple implicit type converters

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

On Friday, 11 September 2015 at 16:25:53 UTC, Bahman Movaqar 
wrote:
As only one `alias this` is possible for any type, how should 
one implement multiple implicit type converters?


multiple alias this is supposed to work and might some day fyi

But for today, the explicit is the only way to go. That's easy to 
do, just write like a .get method or something that does the 
conversion and returns it.

Re: Multiple implicit type converters

[Meta via Digitalmars-d-learn]

On Friday, 11 September 2015 at 16:25:53 UTC, Bahman Movaqar 
wrote:
As only one `alias this` is possible for any type, how should 
one implement multiple implicit type converters?


Actually I'm looking for something similar to Groovy's `asType` 
method[1].  An example in Groovy:


Point p = new Point(1, 1)
assert (p as BigDecimal[]) == [1, 1]
assert (p as BigDecimal) == Math.sqrt(2)
assert (p as Region) == new Region(p, p)

This allows for multiple type converters which are *explicit* 
--in contrast to `alias this` implicit nature.


[1] 
http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Collection.html#asType%28java.lang.Class%29


The only ways to get implicit conversion between two types in D 
are through `alias this`, inheritance, or implementing an 
interface. There is a pull request open for multiple alias-this, 
but it has yet to be pulled.


https://github.com/D-Programming-Language/dmd/pull/3998

Multiple implicit type converters

[Bahman Movaqar via Digitalmars-d-learn]

As only one `alias this` is possible for any type, how should one 
implement multiple implicit type converters?


Actually I'm looking for something similar to Groovy's `asType` 
method[1].  An example in Groovy:


Point p = new Point(1, 1)
assert (p as BigDecimal[]) == [1, 1]
assert (p as BigDecimal) == Math.sqrt(2)
assert (p as Region) == new Region(p, p)

This allows for multiple type converters which are *explicit* 
--in contrast to `alias this` implicit nature.


[1] 
http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Collection.html#asType%28java.lang.Class%29

Re: shared array?

[Kagamin via Digitalmars-d-learn]

On Friday, 11 September 2015 at 14:54:00 UTC, Prudence wrote:
But in this case it is static, so why does it matter? Do you 
have any ideas how to wrap it or fix this?


It matters exactly because it is static. A code written for 
single-threaded environment may not work correctly in shared 
context. It simply wasn't written for it. The way to fix it is to 
write code for shared context.

Re: shared array?

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

On Friday, 11 September 2015 at 14:47:15 UTC, Prudence wrote:
If it's never collected and the GC scans it every time, it 
means it adds a constant overhead to the GC for absolutely no 
reason, right?


GC overhead isn't quite constant, it happens only when you call 
for a collection cycle.


But the array would still be scanned to clean up dead objects 
referred to by the delegates. The array itself is never collected 
(since it is always referenced by the global), but if you null 
out some entries, the objects they pointed to may be collected.


It also then makes every dependency on it GC dependent(@nogc 
can't be used)? It just seems like it's the wrong way to go 
about it.


You can access an array without the GC. And if you manually 
allocate it, then there's no GCness to it at all.


Built in arrays and slices are not necessarily managed by the 
garbage collector. It depends on how you create and use them.

Re: shared array?

[Prudence via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:41:10 UTC, Kagamin wrote:

I get only one error:
Error: non-shared method std.container.array.Array!(void 
delegate()).Array.~this is not callable using a shared object.


It will try to destruct the array on program termination, but 
it requires the destructor to be aware of the shared context.


But in this case it is static, so why does it matter? Do you have 
any ideas how to wrap it or fix this?

Re: shared array?

[Prudence via Digitalmars-d-learn]

On Friday, 11 September 2015 at 13:12:14 UTC, Adam D. Ruppe wrote:

On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
I thought about that but then I have to rely on the GC for 
some simple things. Doesn't seem like the right way to go.


Since it is static, it will never be collected anyway, so you 
could just use it and it'll work for convenience and probably 
lose nothing, or very trivially write an append function that 
uses any scheme you want instead of doing ~= on it without even 
worrying about freeing it.


And that makes it worse!! If it's never collected and the GC 
scans it every time, it means it adds a constant overhead to the 
GC for absolutely no reason, right? It also then makes every 
dependency on it GC dependent(@nogc can't be used)? It just seems 
like it's the wrong way to go about it.

Re: Huge output size for simple programs

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

On Friday, 11 September 2015 at 14:30:00 UTC, NX wrote:

One question: Why?


use the map viewer to get more info:

http://thecybershadow.net/d/mapview/

use dmd -map to create the file it wants

Re: Huge output size for simple programs

[NX via Digitalmars-d-learn]

On Friday, 11 September 2015 at 13:45:03 UTC, Adam D. Ruppe wrote:
Just D's isn't preinstalled so it carries what it needs with 
the executable for broadest compatibility. You could 
dynamically link if you like (`-defaultlib=libphobos2.so` on 
dmd linux)


So I did some testing:

# dmd -defaultlib=libphobos2.so "app.d"
Source:
void main()
{
main();
}
Result:
app.o -> 5.3 KB
app (exe) -> 9.4 KB


# dmd -defaultlib=libphobos2.so "app.d"
Source:
import std.stdio, std.conv, core.stdc.stdlib, std.typecons, 
std.parallelism;

void main()
{
main();
}
Result:
app.o -> 6 KB
app (exe) -> 13.7 KB


Just because I imported some stuff from a dynamically linked 
library makes output weirdly big. Try it yourself, change the 
number of imported modules and output size will significantly 
change.


One question: Why?

Re: Version for windows/console compilation?

[Mike Parker via Digitalmars-d-learn]

On Friday, 11 September 2015 at 04:30:44 UTC, Prudence wrote:


I'm simply creating my own version flags in VD properties. Not 
the best way because I'll have to remember to set the flags 
every time I use the library or I'll get errors about stuff 
missing. I was hoping D had a flag to disambiguate console and 
windows apps(or some type to CT way to check).


The subsystem is set at link time, so there is no reliable way at 
compile time to determine the configuration. A simple and cheap 
runtime check can be made like this:


import core.sys.windows.windows : GetConsoleCP;
bool hasConsole = !!GetConsoleCP();

Re: Lazy sort

[via Digitalmars-d-learn]

On Friday, 11 September 2015 at 12:23:52 UTC, ixid wrote:
Yes, I was reading about heapsort. I was only thinking about 
the usability POV (I mean isn't reduced pretty much an eager 
operation that accepts a lazy input? Why can't sort do that?) 
but it could also offer some performance improvement if you 
only use a part of the sorted array.


I think there is something called "partial sort" in Phobos, but 
"lazy" sorting is the same as a priority queue.


You need to look at all elements before finding the largest one, 
that's why you cannot turn sort into a plain generator (or lazy 
range as some may call it).

Re: Hello World Example with Glade?

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

On Friday, 11 September 2015 at 14:00:30 UTC, Mike McKee wrote:

I finally got it to compile with your help, guys! :)

Here's what I had to type:

# dmd test1.d -L-ldl -I/usr/include/dmd/gtkd3 `pkg-config 
--cflags --libs gtkd3`


Don't forget to answer yourself on SO too!

http://stackoverflow.com/questions/32516092/how-to-show-hello-world-with-glade-gtkd-and-d-programming-language

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Friday, 11 September 2015 at 09:07:37 UTC, Jordi Sayol wrote:
On  there is the "pkg-config" 
section:


I finally got it to compile with your help, guys! :)

Here's what I had to type:

# dmd test1.d -L-ldl -I/usr/include/dmd/gtkd3 `pkg-config 
--cflags --libs gtkd3`

Re: Huge output size for simple programs

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

On Friday, 11 September 2015 at 11:15:33 UTC, NX wrote:

hello_world (linux executable) -> 13 MB !!!


Try running `strip yourexecutable` on all compilers, but on gdc 
it should make the biggest difference. It brings debugging info 
and exported symbols.


Is this because whole GC implementation code is injected into 
executable or maybe libphobos.a being statically linked or is 
this because TypeInfo* ModuleInfo* stuff?


Static linking is a couple hundred kilobytes, some of the library 
being intertwined is a couple hundred more.


C's stdlib is also large, but since it comes with the operating 
system preinstalled, you don't think about it much. Ditto times 
twenty for Java, .net, C++, dynamic languages, etc.


Just D's isn't preinstalled so it carries what it needs with the 
executable for broadest compatibility. You could dynamically link 
if you like (`-defaultlib=libphobos2.so` on dmd linux) though 
then to share the application, you've gotta share that 
multi-megabyte .so as well as the executable and deal with 
dependency management, so it really makes it worse.


And if you aren't distributing it, meh, what's 400 kb on your own 
hard drive?

Re: Version for windows/console compilation?

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

On Friday, 11 September 2015 at 04:30:44 UTC, Prudence wrote:
I'm using Visual D and I assume it takes care of all this. It 
works so that's not a huge problem.


If it is taking care of the linker switch, then you gain nothing 
but more complicated and fragile code by writing a WinMain!


I was hoping D had a flag to disambiguate console and windows 
apps(or some type to CT way to check).


There's not really a difference between them. A console app can 
create windows and a gui app can allocate a console.


The best thing to check for might just be if there's already a 
console available when you want to use one.

Re: best way to memoize a range?

[John Colvin via Digitalmars-d-learn]

On Friday, 11 September 2015 at 13:09:33 UTC, Laeeth Isharc wrote:
obviously it's trivial to do with a little aa cache.  and I 
know I can memoize a function, and turn the memoized version 
into an infinite range.  but suppose I have a lazy function 
that returns a finite range, and its expensive to calculate.


can I use Phobos to produce a memoized range?  So it will 
calculate on access to an element if it needs to, but will 
return the cached value if it has been calculated before.


perhaps 
http://dlang.org/phobos/std_algorithm_iteration.html#.cache would 
do what you need. An AA based cache (with a normal range 
interface if you want) is probably the sensible way to get true 
random-access here, unless you have reasonably dense and 
monotonic accesses in which case an appender-based linear cache 
could work, either using Nullable!T or a separate list of bools 
(or bits) marking whether a result is cached yet.

Re: best way to memoize a range?

[Jakob Ovrum via Digitalmars-d-learn]

On Friday, 11 September 2015 at 13:09:33 UTC, Laeeth Isharc wrote:
obviously it's trivial to do with a little aa cache.  and I 
know I can memoize a function, and turn the memoized version 
into an infinite range.  but suppose I have a lazy function 
that returns a finite range, and its expensive to calculate.


can I use Phobos to produce a memoized range?  So it will 
calculate on access to an element if it needs to, but will 
return the cached value if it has been calculated before.


Is your range random access?

If not, `cache` should do the trick.

[1] http://dlang.org/phobos/std_algorithm_iteration.html#cache

Re: shared array?

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

On Friday, 11 September 2015 at 04:28:52 UTC, Prudence wrote:
I thought about that but then I have to rely on the GC for some 
simple things. Doesn't seem like the right way to go.


Since it is static, it will never be collected anyway, so you 
could just use it and it'll work for convenience and probably 
lose nothing, or very trivially write an append function that 
uses any scheme you want instead of doing ~= on it without even 
worrying about freeing it.

Re: using std.algorithm to find intersection of DateTime[][] arg

[Laeeth Isharc via Digitalmars-d-learn]

On Thursday, 10 September 2015 at 11:58:10 UTC, deed wrote:
On Wednesday, 9 September 2015 at 20:28:35 UTC, Laeeth Isharc 
wrote:

I have a DateTime[][] arg ...
I would like to find the intersection of the dates.


A suggestion:

auto minLength  = arg.map!(a => a.length).reduce!min;
auto minIdx = arg.map!(a => 
a.length).countUntil(minLength);
auto intersection   = arg[minIdx].filter!(e => 
chain(arg[0..minIdx], arg[minIdx..$]).all!(a => 
a.assumeSorted.contains(e)));


reduce with setIntersection seems the most straightforward, but 
needs array AFAIK, i.e.:


auto intersection =
//reduce!((r, x) => setIntersection(r, x))(arg);  // 
doesn't work
  reduce!((r, x) => setIntersection(r, x).array)(arg);// does, 
but with array


Thank you for this - exactly what I was looking for - and for the 
other answer.



Laeeth.

best way to memoize a range?

[Laeeth Isharc via Digitalmars-d-learn]

obviously it's trivial to do with a little aa cache.  and I know 
I can memoize a function, and turn the memoized version into an 
infinite range.  but suppose I have a lazy function that returns 
a finite range, and its expensive to calculate.


can I use Phobos to produce a memoized range?  So it will 
calculate on access to an element if it needs to, but will return 
the cached value if it has been calculated before.

Re: Huge output size for simple programs

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, September 11, 2015 11:15:31 NX via Digitalmars-d-learn wrote:
> I compile a simple hello world program in C and the results:
>
> hello_world.o -> 1.5 KB
> hello_world (linux executable) -> 8.5 KB
>
>
> Then I compile a simple hello world program in D (using DMD) and
> the results:
>
> hello_world.o -> 9.3 KB
> hello_world (linux executable) -> 575.9 KB
>
>
> Then I compile a simple hello world program in D (using GDC) and
> the results:
>
> hello_world.o -> 24.6 KB
> hello_world (linux executable) -> 13 MB !!!
>
> What's the reason for that? What makes D applications so much
> bloated?
> Is this because whole GC implementation code is injected into
> executable or maybe libphobos.a being statically linked or is
> this because TypeInfo* ModuleInfo* stuff?

It's primarily because the d runtime and standard library are statically
linked, whereas the C runtime and standard library are dynamically linked.
Some of the stuff related to TypeInfo and other D-specific features does
make it worse than it would be otherwise, but fundamentally, if you're
statically linking in the D runtime and standard library, you're always
going to get larger programs than when you dynamically link. However, a lot
of that won't increase in size as a program's source code increases in size,
because the runtime and standard library don't increase in size just because
you have more code. I expect that there will be improvements to the size of
D binaries in the future though, since there is some desire among the
compiler devs to figure out how to reduce it, and you can use libphobos.so
if you'd like. It's just that its ABI changes from release to release, so
your D programs risk breaking every time you upgrade and thus likely will
have to be rebuilt, whereas you wouldn't have the same problem with
libphobos.a, since in that case, it all ends up in the executable.

Now, as to why the gdc binary is so large, I don't know. My guess is that it
has something to do with the debug symbols. You could try building with -g
or -gc to see how that affects the dmd-generated binary.

Regardless, this is the sort of thing that looks really bad with hello
world, because your code is really small, and the D runtime and standard
library dwarf it, whereas if you have a much larger program, the difference
between D and C/C++ is likely to be a lot less noticeable.

- Jonathan M Davis

Re: Huge output size for simple programs

[John Colvin via Digitalmars-d-learn]

On Friday, 11 September 2015 at 11:15:33 UTC, NX wrote:

I compile a simple hello world program in C and the results:

hello_world.o -> 1.5 KB
hello_world (linux executable) -> 8.5 KB


Then I compile a simple hello world program in D (using DMD) 
and the results:


hello_world.o -> 9.3 KB
hello_world (linux executable) -> 575.9 KB


Then I compile a simple hello world program in D (using GDC) 
and the results:


hello_world.o -> 24.6 KB
hello_world (linux executable) -> 13 MB !!!

What's the reason for that? What makes D applications so much 
bloated?
Is this because whole GC implementation code is injected into 
executable or maybe libphobos.a being statically linked or is 
this because TypeInfo* ModuleInfo* stuff?


static linking is the really big thing here.

Re: Lazy sort

[ixid via Digitalmars-d-learn]

On Friday, 11 September 2015 at 11:08:29 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 11 September 2015 at 10:41:16 UTC, ixid wrote:
Does sort have to be eager or would it be possible to have a 
lazy version? It's messy to always have to use array and leap 
in and out of lazy operations within a UFCS chain. Surely as 
many functions as possible should be optionally lazy.


https://en.wikipedia.org/wiki/Priority_queue


Yes, I was reading about heapsort. I was only thinking about the 
usability POV (I mean isn't reduced pretty much an eager 
operation that accepts a lazy input? Why can't sort do that?) but 
it could also offer some performance improvement if you only use 
a part of the sorted array.

Re: Huge output size for simple programs

[Daniel N via Digitalmars-d-learn]

On Friday, 11 September 2015 at 11:15:33 UTC, NX wrote:

I compile a simple hello world program in C and the results:

hello_world.o -> 1.5 KB
hello_world (linux executable) -> 8.5 KB




If you care about binary sizes, use ldc2:
ldc 225544 bytes (stripped + writeln)
ldc 175736 bytes (stripped + puts)

with tricks you can get lower, but that's out of the box...

Re: Is this a bug?

[anonymous via Digitalmars-d-learn]

On Friday 11 September 2015 12:33, Rene Zwanenburg wrote:

> The following fails to compile with an 'cannot deduce function 
> from argument types' error. When using an array of something 
> other than TypeInfo_Class everything works as expected.
> 
> void main()
> {
>   import std.algorithm.mutation : remove;
>   
>   TypeInfo_Class[] arr;
>   TypeInfo_Class c;
>   arr = arr.remove!(a => a is c);
> }

Yes, it's a bug. It should work.

The problem is that TypeInfo_Class has a method called "init" which shadows 
the built-in type property of the same name. This confuses ElementType.

I filed a bug: https://issues.dlang.org/show_bug.cgi?id=15037

Huge output size for simple programs

[NX via Digitalmars-d-learn]

I compile a simple hello world program in C and the results:

hello_world.o -> 1.5 KB
hello_world (linux executable) -> 8.5 KB


Then I compile a simple hello world program in D (using DMD) and 
the results:


hello_world.o -> 9.3 KB
hello_world (linux executable) -> 575.9 KB


Then I compile a simple hello world program in D (using GDC) and 
the results:


hello_world.o -> 24.6 KB
hello_world (linux executable) -> 13 MB !!!

What's the reason for that? What makes D applications so much 
bloated?
Is this because whole GC implementation code is injected into 
executable or maybe libphobos.a being statically linked or is 
this because TypeInfo* ModuleInfo* stuff?

Re: Lazy sort

[via Digitalmars-d-learn]

On Friday, 11 September 2015 at 10:41:16 UTC, ixid wrote:
Does sort have to be eager or would it be possible to have a 
lazy version? It's messy to always have to use array and leap 
in and out of lazy operations within a UFCS chain. Surely as 
many functions as possible should be optionally lazy.


https://en.wikipedia.org/wiki/Priority_queue

Re: Lazy sort

[Chris via Digitalmars-d-learn]

On Friday, 11 September 2015 at 10:41:16 UTC, ixid wrote:
Does sort have to be eager or would it be possible to have a 
lazy version? It's messy to always have to use array and leap 
in and out of lazy operations within a UFCS chain. Surely as 
many functions as possible should be optionally lazy.


Are you the lazy sort? ;)

Sorry, I couldn't resist the pun.

Re: Lazy sort

[deed via Digitalmars-d-learn]

On Friday, 11 September 2015 at 10:41:16 UTC, ixid wrote:
Does sort have to be eager or would it be possible to have a 
lazy version? It's messy to always have to use array and leap 
in and out of lazy operations within a UFCS chain. Surely as 
many functions as possible should be optionally lazy.


Wouldn't that mean removing min or max lazily?

Lazy sort

[ixid via Digitalmars-d-learn]

Does sort have to be eager or would it be possible to have a lazy 
version? It's messy to always have to use array and leap in and 
out of lazy operations within a UFCS chain. Surely as many 
functions as possible should be optionally lazy.

Re: Hello World Example with Glade?

[Gary Willoughby via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:13:22 UTC, Mike McKee wrote:

I'm having trouble installing GtkD on Ubuntu Linux 14.04.


Here's an old guide I wrote years ago. It might be a little out 
of date but may help you put things together:


http://nomad.so/2013/07/cross-platform-gui-programming-using-d-and-gtk/

Is this a bug?

[Rene Zwanenburg via Digitalmars-d-learn]

The following fails to compile with an 'cannot deduce function 
from argument types' error. When using an array of something 
other than TypeInfo_Class everything works as expected.


void main()
{
import std.algorithm.mutation : remove;

TypeInfo_Class[] arr;
TypeInfo_Class c;
arr = arr.remove!(a => a is c);
}

Re: How To: Passing curried functions around

[Bahman Movaqar via Digitalmars-d-learn]

On Friday, 11 September 2015 at 06:14:18 UTC, Ali Çehreli wrote:

On 09/06/2015 12:05 PM, Bahman Movaqar wrote:
>  alias bool function(int n) validator_t;

There is the relatively newer alias syntax which is more 
intuitive:


alias Validator = bool function(int n);


Great.  This is easily read by my eyes.

partial takes the function arguments as 'value template 
parameters'. Unfortunately, a function pointer like &isEven 
cannot be 'value template parameters'; only fundamental types 
and strings can... So, 'partial' is not an option for this 
problem.


Ah...now I understand the mysterious compiler errors.

Idiomatic D uses templates and passes behavior in the form of 
'alias template parameters.' Alias template parameters are the 
convenient way of allowing anything that is callable, not just 
functions. For example, foo() would be much more useful if it 
allowed a delegate or a class object that has an overloaded 
opCall() operator.


True.  I guess I was just pushing D functions too far.


> and even
> if this is the correct way of currying `readInt`, what should
be the
> signature of `foo`?

I think 'int delegate()' would do because all foo needs is a 
function that returns an int.


That's correct.  I realised this subtle point later on, but had 
already switched to a `struct`y approach.




The idiomatic way is to leave it as a template parameter. 
However, this has the problem of making each instantiation of 
the foo template a different type, making them incompatible to 
be elements of the same array:


[ &(foo!myReader), &(foo!yourReader) ]  // <-- compilation error

One solution is to do what std.parallelism.task does: to 
provide both a foo template and another foo function that takes 
an 'int delegate()':


  http://ddili.org/ders/d.en/parallelism.html

(Search for "The task function above has been specified as a 
template parameter" on that page.)


Actually, I *am* using your book (which is, by the way, very well 
written) plus the language specs to learn D.  However, that 
section yet too advance for me to touch :-)



import std.stdio;

bool isEven(int n) {
return !(n % 2);
}

int readValidInt(alias validator)(string prompt) {
while (true) {
int i;
write(prompt);
readf(" %s", &i);
if (validator(i)) {
return i;
} else {
writeln("Sorry, that's not acceptable");
}
}
}

void foo(alias reader)() {
reader();
}

void main() {
auto reader = () => readValidInt!isEven("Enter an integer: 
");


foo!reader();
}

You can add template constraints to make the code easier to use.


Clean one!  Even though I don't know what's going behind the 
scenes, I can easily read and understand it.


Thanks for the help.

Re: Hello World Example with Glade?

[Jordi Sayol via Digitalmars-d-learn]

El 11/09/15 a les 11:05, Jordi Sayol via Digitalmars-d-learn ha escrit:
> El 11/09/15 a les 09:13, Mike McKee via Digitalmars-d-learn ha escrit:
>> On Friday, 11 September 2015 at 06:53:07 UTC, Mike James wrote:
>>> There's a Glade example in the demos/builder directory...
>>
>> I'm having trouble installing GtkD on Ubuntu Linux 14.04. I did the apt 
>> steps from here:
>>
>> http://d-apt.sourceforge.net/
>>
>> $ sudo su
>> # wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O 
>> /etc/apt/sources.list.d/d-apt.list
>> # apt-get update && apt-get -y --allow-unauthenticated install --reinstall 
>> d-apt-keyring && apt-get update
>> # apt-get install libgtkd3-dev libgtkd3-doc
>>
>> I then run the following and it fails:
>>
>> # dmd test1.d
>> test1.d(1): Error: module gtk is in file 'gtk.d' which cannot be read
>> import path[0] = /usr/include/dmd/phobos
>> import path[1] = /usr/include/dmd/druntime/import
>>
> 
> 
> On  there is the "pkg-config" section:
> 
> ---
> pkg-config:
> Every dev package contains "pkg-config" (shared and static) configuration 
> files for the specific library.
> i.e. link GtkD2 applications against "libgtkd2.so" and "libphobos2.so" 
> shared libraries:
> $ dmd `pkg-config --cflags --libs gtkd2` my_gtkd2_app.d
> or link GtkD2 applications against "libgtkd2.a" and "libphobos2.a" static 
> libraries:
> $ dmd `pkg-config --cflags --libs gtkd2-static` my_gtkd2_app.d
> ---

Just replace "gtkd2" by "gtkd3"

$ dmd `pkg-config --cflags --libs gtkd3` my_glade_app.d
$ dmd `pkg-config --cflags --libs gtkd3-static` my_glade_app.d

This works out of the box with the "builderTest.d" example on GtkD demos folder.

Regards

Re: What is "FilterResult" type?

[Bahman Movaqar via Digitalmars-d-learn]

On Wednesday, 9 September 2015 at 13:16:49 UTC, cym13 wrote:
True.  But is pumping the output of `filter` as the seed into 
`reduce` really considered weird usage!?


I don't think it is really weird per se, I just can't think of 
a case where there isn't a better way to do it. I find it 
completely unreadable frankly, and I generally avoid reduce 
when I can because it is not UFCS-able. This is only personal 
opinion though.


Now I see your point.  I too find fold/reduce the least 
transparent verb of the list comprehension.  And certainly your 
point about UFCS adds to it.

Re: Hello World Example with Glade?

[Jordi Sayol via Digitalmars-d-learn]

El 11/09/15 a les 09:13, Mike McKee via Digitalmars-d-learn ha escrit:
> On Friday, 11 September 2015 at 06:53:07 UTC, Mike James wrote:
>> There's a Glade example in the demos/builder directory...
> 
> I'm having trouble installing GtkD on Ubuntu Linux 14.04. I did the apt steps 
> from here:
> 
> http://d-apt.sourceforge.net/
> 
> $ sudo su
> # wget http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list -O 
> /etc/apt/sources.list.d/d-apt.list
> # apt-get update && apt-get -y --allow-unauthenticated install --reinstall 
> d-apt-keyring && apt-get update
> # apt-get install libgtkd3-dev libgtkd3-doc
> 
> I then run the following and it fails:
> 
> # dmd test1.d
> test1.d(1): Error: module gtk is in file 'gtk.d' which cannot be read
> import path[0] = /usr/include/dmd/phobos
> import path[1] = /usr/include/dmd/druntime/import
> 


On  there is the "pkg-config" section:

---
pkg-config:
Every dev package contains "pkg-config" (shared and static) configuration 
files for the specific library.
i.e. link GtkD2 applications against "libgtkd2.so" and "libphobos2.so" 
shared libraries:
$ dmd `pkg-config --cflags --libs gtkd2` my_gtkd2_app.d
or link GtkD2 applications against "libgtkd2.a" and "libphobos2.a" static 
libraries:
$ dmd `pkg-config --cflags --libs gtkd2-static` my_gtkd2_app.d
---

Best regards

Re: shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, September 11, 2015 00:50:13 Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Friday, 11 September 2015 at 00:48:28 UTC, Prudence wrote:
> > static Array!(bool delegate(int, WPARAM, LPARAM)) callbacks;
>
> Try just using a regular array instead of the library Array.
>
>
> static bool delegate(int, WPARAM, LPARAM)[] callbacks;
>
> my guess is the Array library thing isn't marked as shared
> internally.

Given how shared works, for a class or struct to work with shared, it pretty
much has to be designed specifically to be used with shared. Depending on
its members, it's possible to declare a variable of class or struct type as
shared and then cast away shared to operate on it (after protecting access
to it with a mutex of course), but actually using an object as shared is
impossible unless the type was specifically designed to be used that way,
and even marking one as shared with the idea that you'll cast away shared to
operate on it (after protecting it with a mutex) probably won't work in many
cases simply because the type's internals weren't designed to work with
shared and could end up with compilation errors even if it was never
actually going to be used without casting away shared.

In general, shared should only be used with built-in types or types which
were specifically designed to be shared, and that means that types that
you'd use in non-shared code aren't going to work in shared code. This can
be annoying, but it really forces you to separate out your shared code from
your normal code, which is arguably a good thing. Still, shared is one of
those things that we need to re-examine and see how it should be changed to
be more usable. It's a great idea, but the devil is in the details.

- Jonathan M Davis

Re: Hello World Example with Glade?

[Mike James via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:47:15 UTC, Mike McKee wrote:

[...]


The undefined references mean you haven't provided a linker path 
to the GtkD libs.

Have you built the GtkD libraries?
Check out https://github.com/gtkd-developers/GtkD

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:39:46 UTC, Mike James wrote:

try # dmd test1.d -I/usr/include/dmd/gtkd3


# dmd test1.d -L-ldl -I/usr/include/dmd/gtkd3
test1.o:(.rodata+0x12c): undefined reference to 
`_D3gtk7Builder12__ModuleInfoZ'
test1.o:(.rodata+0x130): undefined reference to 
`_D3gtk4Main12__ModuleInfoZ'
test1.o:(.rodata+0x134): undefined reference to 
`_D3gtk6Window12__ModuleInfoZ'
test1.o:(.rodata+0x138): undefined reference to 
`_D7gobject4Type12__ModuleInfoZ'

test1.o: In function `_Dmain':
test1.d:(.text._Dmain+0xc): undefined reference to 
`_D3gtk4Main4Main4initFKAAyaZv'
test1.d:(.text._Dmain+0x11): undefined reference to 
`_D3gtk7Builder7Builder7__ClassZ'
test1.d:(.text._Dmain+0x1c): undefined reference to 
`_D3gtk7Builder7Builder6__ctorMFZC3gtk7Builder7Builder'
test1.d:(.text._Dmain+0x38): undefined reference to 
`_D3gtk6Window6Window7__ClassZ'
test1.d:(.text._Dmain+0x63): undefined reference to 
`_D3gtk4Main4Main3runFZv'

collect2: error: ld returned 1 exit status

I also tried without the "-L-ldl" and got the same result. I then 
tried this:


# rdmd -I/usr/include/dmd/gtkd3 -L-ldl test1.d

** (test1:3169): WARNING **: Couldn't connect to accessibility 
bus: Failed to connect to socket /tmp/dbus-PJfKDfNeIv: Connection 
refused

Segmentation fault (core dumped)

Re: shared array?

[Kagamin via Digitalmars-d-learn]

You can try to write a wrapper for the array that it aware of 
concurrency.

Re: shared array?

[Kagamin via Digitalmars-d-learn]

I get only one error:
Error: non-shared method std.container.array.Array!(void 
delegate()).Array.~this is not callable using a shared object.


It will try to destruct the array on program termination, but it 
requires the destructor to be aware of the shared context.

Re: Hello World Example with Glade?

[Mike James via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:29:23 UTC, Mike McKee wrote:

On Friday, 11 September 2015 at 07:20:57 UTC, Mike James wrote:
It looks last keep you're missing an import path 
(-Ipath_to_source). Check out 
http://dlang.org/dmd-linux.html#switches


I tried this just now:

# dmd test1.d -I/usr/include/dmd/gtkd3/gtkc
/usr/include/dmd/gtkd3/gtkc/gtk.d(28): Error: module gtktypes 
is in file 'gtkc/gtktypes.d' which cannot be read

import path[0] = /usr/include/dmd/gtkd3/gtkc
import path[1] = /usr/include/dmd/phobos
import path[2] = /usr/include/dmd/druntime/import

It's saying that it can't read gtkc/gtktypes.d, but there is a 
file in path /usr/include/dmd/gtkd3/gtkc/gtktypes.d



try # dmd test1.d -I/usr/include/dmd/gtkd3

I'm using GtkD on Windows so there is a .../src directory with 
all the source files in.


regards, --

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:20:57 UTC, Mike James wrote:
It looks last keep you're missing an import path 
(-Ipath_to_source). Check out 
http://dlang.org/dmd-linux.html#switches


I tried this just now:

# dmd test1.d -I/usr/include/dmd/gtkd3/gtkc
/usr/include/dmd/gtkd3/gtkc/gtk.d(28): Error: module gtktypes is 
in file 'gtkc/gtktypes.d' which cannot be read

import path[0] = /usr/include/dmd/gtkd3/gtkc
import path[1] = /usr/include/dmd/phobos
import path[2] = /usr/include/dmd/druntime/import

It's saying that it can't read gtkc/gtktypes.d, but there is a 
file in path /usr/include/dmd/gtkd3/gtkc/gtktypes.d

Re: private selective import not so private ?

[Gary Willoughby via Digitalmars-d-learn]

On Friday, 11 September 2015 at 00:55:41 UTC, Adam D. Ruppe wrote:

On Friday, 11 September 2015 at 00:52:00 UTC, BBasile wrote:
While trying to get why some call to memmove without the right 
import didn't lead to a compilation failure i've found that 
imported symbols are not private ! Is that a bug ? The specs 
don't say that a selective import is public !


Yes, it is one of the oldest, most infamous bugs D has, the 
dreaded #314:


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


Walter, Andrei, when is this ever going to be addressed? It 
catches out so many people, me included and is raised on this 
newsgroup over and over again.

Re: Hello World Example with Glade?

[Mike James via Digitalmars-d-learn]

On Friday, 11 September 2015 at 07:13:22 UTC, Mike McKee wrote:

On Friday, 11 September 2015 at 06:53:07 UTC, Mike James wrote:

There's a Glade example in the demos/builder directory...


I'm having trouble installing GtkD on Ubuntu Linux 14.04. I did 
the apt steps from here:


http://d-apt.sourceforge.net/

$ sudo su
# wget 
http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list 
-O /etc/apt/sources.list.d/d-apt.list
# apt-get update && apt-get -y --allow-unauthenticated install 
--reinstall d-apt-keyring && apt-get update

# apt-get install libgtkd3-dev libgtkd3-doc

I then run the following and it fails:

# dmd test1.d
test1.d(1): Error: module gtk is in file 'gtk.d' which cannot 
be read

import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import



It looks last keep you're missing an import path 
(-Ipath_to_source). Check out 
http://dlang.org/dmd-linux.html#switches


Regards, --

Re: Hello World Example with Glade?

[Mike McKee via Digitalmars-d-learn]

On Friday, 11 September 2015 at 06:53:07 UTC, Mike James wrote:

There's a Glade example in the demos/builder directory...


I'm having trouble installing GtkD on Ubuntu Linux 14.04. I did 
the apt steps from here:


http://d-apt.sourceforge.net/

$ sudo su
# wget 
http://master.dl.sourceforge.net/project/d-apt/files/d-apt.list 
-O /etc/apt/sources.list.d/d-apt.list
# apt-get update && apt-get -y --allow-unauthenticated install 
--reinstall d-apt-keyring && apt-get update

# apt-get install libgtkd3-dev libgtkd3-doc

I then run the following and it fails:

# dmd test1.d
test1.d(1): Error: module gtk is in file 'gtk.d' which cannot be 
read

import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import