Re: Bug in gtkd?

[Johnson Jones via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 20:18:19 UTC, Mike Wey wrote:

On 01-08-17 21:44, Johnson Jones wrote:

On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:

On 01-08-17 05:53, Johnson Jones wrote:




GtkD is currently based on GTK 3 the properties it complains 
about were removed in GTK 3.0.


Which version of glade are you using?


The latest: Glade 3.8.5


Could you check File -> Properties and see what is set as the 
runtime version? It should be at least 3.0 so it doesn't use 
things that were removed.


There is no File/Properties. If I go to help/about it says 3.8.5. 
If I go to edit/preferences it says target gtk+ version and the 
highest is 2.24.


This is where I downloaded it from:

http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.8/

It seems I do, in fact have an older version ;/

https://glade.gnome.org/sources.html

I upgraded to 3.14(for some reason I was thinking 8 > 14 ;/). It 
does have the properties and did warn me about my glade file 
being old(strange though, the ver 14 looks crappier as the fonts 
are thinner).


Not a big deal though. Seems ver 3.14 is the newest binaries for 
windows for some reason ;/ No one has compiled a windows version 
for 3.20 in over a year.


Not sure of the differences between 3.14 and 3.20 but 3.14 does 
target gtk+3 while 3.8 targeted gtk+2.


How to build glade 3.20 for windows, or better, request the 
originators to build it(since they obviously have done it for the 
previous versions)?

Re: newCTFE Status August 2017

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote:
Sadly I temporarily broke the support for string-members in 
structs.


Fixed now.

The issue was ABI related.
we used to store pointers to sliceDescriptors, but I changed that 
to store the sliceDescriptors directly. Because otherwise slicing 
of initializes of type string does not work.


I am happy I thought about this briefly two months ago, and to 
have had the foresight to put in stubs for that, otherwise this 
would have gotten much messier.


Another issue I want to deal with are void initalized struct 
members.
In a few instances we can statically determine that they are 
always initialized.

i.e. when there are no branches.
In most instances this is not the case though  this requires 
us to store a bitfield next to the this pointer of the struct 
which indicated if a paricular member has been initialized or not.
Luckily we only need to do that for `= void` members. So I think 
we can get away with 32bit.


I should mention that newCTFE does currently not support structs 
with more then 96 member-variables anyway.

So far I have not come close to hitting that limit.

Talking about limits, this are the current limits I am aware of.
you can only use 16000 local variables per function.
you can only allocate around 265 Megabyte of heap-space per 
evaluation.

Only functions with up to 64 parameters are supported.
you can only have up to 65535 instructions per function (roughly 
16000 lines of code)
The call-stack can only be 2000 calls deep. (This is an artifical 
limtation that the old interpreter imposed because it would die 
and use insane amounts of memery wehen it went over that limit. 
(With newCTFE you can safely bump that limit up to 5000 levels of 
recursion  but in order to pass all unittests we need to keep 
the old limit))
You can only have about 12000 different struct types per 
evaluation.

And only about 16000 assertions.
Similarly there may only be 7000 array-literals per function.

I don't see anyone reaching those limits soon.

Cheers,
Stefan

[Issue 17710] Undefined behaviour and non-working casting of overloaded methods invoking overloaded delegates

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: The progress of D since 2013

[Maksim Fomin via Digitalmars-d]

OK. Thanks everybody for information!

Re: Have a question

[Stefan Koch via Digitalmars-d]

On Wednesday, 2 August 2017 at 02:33:24 UTC, Evanhdc wrote:

Hi everyone,
I'm a newbie there and I'm interested in this forum a lot. How 
can I get much knowledge as you guys? :D. Hope to get more 
knowledge from you all!

Thanks.


1. Read "The D Programming Language" by Andrei Alexanderscue.
2. Read it again :)

Have a question

[Evanhdc via Digitalmars-d]

Hi everyone,
I'm a newbie there and I'm interested in this forum a lot. How 
can I get much knowledge as you guys? :D. Hope to get more 
knowledge from you all!

Thanks.

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

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

On Wednesday, 2 August 2017 at 00:39:24 UTC, Mike wrote:
Looking at your code though, I probably should have used Adam's 
dom.d too; std.xml was weird to say the least.


There's a couple functions in dom.d too that might have 
simplified this:


foreach(EnumsTop; Flds.getElementsByTagName("enumeratedValues")){
foreach(Enums; EnumsTop.getElementsByTagName("enumeratedValue")){
foreach(child; Enums.childNodes){
			if(child.tagName=="description"){EnumV.description  = 
child.innerText();}
			if(child.tagName=="name"   ){EnumV.name = 
child.innerText();}		
			if(child.tagName=="value"  ){EnumV.value= 
child.innerText();}

}


This pattern is used throughout, and it is pretty nice. Not 
saying it is wrong!


But that could prolly be written:

foreach(Enums; Flds.querySelectorAll("enumeratedValues > 
enumeratedValue")) {
EnumV.description  = 
Enum.optionSelector("description").innerText();

EnumV.name  = Enum.optionSelector("name").innerText();
EnumV.value  = Enum.optionSelector("value").innerText();
}




The various *selector functions do CSS selector syntax. 
querySelector/querySelectorAll returns the first/all matching 
element, or null if none. requireSelector returns the first 
matching, or throws exception if there is none. optionSelector 
returns a wrapper object that is never null so you can call its 
methods, but they return null if it was.


Meaning you don't have to explicitly check presence, the 
.innerText just returns the null string if the element wasn't 
there.



The idea of these is to make navigating xml like this a bit more 
convenient.

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Mike via Digitalmars-d-announce]

On Tuesday, 1 August 2017 at 20:11:13 UTC, Taylor Hillegeist 
wrote:



Reminds me of something I put together a while ago.
https://github.com/taylorh140/SVD_TO_D
But this looks much nicer, nice work!


ha ha! Even the pattern used in our code is similar.  I swear I 
never saw it before.


Looking at your code though, I probably should have used Adam's 
dom.d too; std.xml was weird to say the least.


Mike

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Mike via Digitalmars-d-announce]

On Tuesday, 1 August 2017 at 19:04:44 UTC, Johannes Pfau wrote:


SVD seems to be an ARM standard / initiative?


Yeah, ARM appears to maintain the XML schema, but the SVD files 
are usually created and distributed by the silicon vendors, in 
varying levels of quality, unfortunately.


Mike

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Mike via Digitalmars-d-announce]

On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven Schveighoffer 
wrote:


Mike, I have to say still your talk in 2014 was one of my 
favorites. One of the things that was so impressive to me was 
the way you scraped the PDF to generate all the registers 
automatically. Having worked with STM chips (not ARM, but 
really basic 8-bit versions), I can definitely appreciate all 
the work this saves.


I'm not sure my work is worthy of such kind words, but thank you.

The PDF screen utility is here: 
https://github.com/JinShil/stm32_datasheet_to_d.  I'm not sure if 
it still compiles and works, but I might need to update it 
someday.


It generates much better code and more complete documentation 
than svd_to_d.  Most silicon vendors don't appear to invest much 
into their SVD files, so the SVD files are often incomplete and 
lacking the documentation that makes "good code + a good IDE = a 
substitute for the datasheet".


If I were creating a professional product, I'd probably prefer 
scraping the PDF over using the SVD files, or maybe some way to 
merge the two.


Mike

Re: Adding deprecated to an enum member

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 01:12:28 UTC, Jeremy DeHaan wrote:
I got an error today because I added deprecated to an enum 
member.


Is there a way to achieve this, or am I out of luck? If it 
isn't doable, should it be?


Here's what I want:

[...]


It's a bug [1].

[1] https://issues.dlang.org/show_bug.cgi?id=9395

Re: this r-value optimizations

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 22:47:24 UTC, Nordlöw wrote:
Given the `struct S` with lots of data fields, I've written the 
following functional way of initializing only a subset of the 
members in an instance of `S`:


struct S
{
[...]
}

Now the question becomes: will the S-copying inside `withF` be 
optimized out in the case when `this` is an r-value such as in 
the call


auto y = S(32).withF(42.0);

?


You're going to have to be specific about optimized out by whom. 
By the frontend? Doesn't seem that way to me by looking at the 
`-O0` assembly generated by ldc [1].




If not, one solution of doing this manually is to write `withF` 
as a free function


[...]

Is this the preferred way of solving this until we (ever) get 
named parameters in D?


Preferred by whom? The people who want named parameters in D seem 
to be a minority in the community from my personal observation, 
so you would most likely get personal preferred way as an answer 
(instead of "the" unanimous preferred way).
In any case, this looks like a case of evil early optimization to 
me, because it's statistically unlikely that this is going to be 
the bottleneck of your program (though profiling would be in 
order to confirm / disprove that assumption for your specific use 
case).


[1] https://godbolt.org/g/Htdtht

Re: [OT] Alternative to Thunderbird (was: Re: NG technical issues: Is it just me?)

[H. S. Teoh via Digitalmars-d]

On Tue, Aug 01, 2017 at 03:50:02PM -0700, Ali Çehreli via Digitalmars-d wrote:
[...]
> Perhaps I should get used to reading news and email with Emacs
> already. :/
[...]

I've been using Mutt for years, and quite happy with it.  There's a
version/patch floating around somewhere that has built-in NNTP support,
but IME it's a little klunky with high-traffic newsgroups.  I just use
the mailing list interface to the D forums, and things work perfectly.

The best part of using Mutt is that it has full threading support, so if
a particular topic doesn't interest you, you can delete the entire
(sub)thread with a single keystroke.  Indispensible for handling busy
forums like this one.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

Re: why won't byPair work with a const AA?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Aug 01, 2017 at 07:31:41PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 8/1/17 7:15 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> > On Tue, Aug 01, 2017 at 07:09:45PM -0400, Steven Schveighoffer via 
> > Digitalmars-d-learn wrote:
> > > If this were a true implementation without the opaqueness, it
> > > would not work properly.
> > [...]
> > 
> > Actually, a proper implementation would still work, provided you
> > declare your pointer types carefully.  Sketch of idea:
> > 
> > auto byKeyValue(AA)(AA aa) {
> > struct Result {
> > const(Slot)* current; // N.B.: proper type
> > bool empty() { ... }
> > auto front() { return Pair(*current); }
> > void popFront() {
> > current = current.next;
> > ...
> > }
> > }
> > return Result(aa);
> > }
> > 
> > Basically, the type of `current` must be const(Slot)* rather than
> > const(Slot*), which would be the default inferred type. But since
> > it's legal to assign a const pointer to a pointer to const (you
> > can't modify the original pointer, nor what it points to, but it's
> > valid to copy the pointer to a mutable pointer variable, as long as
> > what is pointed to is still const), this actually will work without
> > breaking / bypassing the type system.
> 
> No, you can't const the Slot, because if the value type is a pointer,
> you can't then cast away the const-ness of it legally.
> 
> There are ways to get it right, it involves templating for mutability.
[...]

Counter-proof:

struct Slot {
Slot* next;
const(string) key;
const(int) value;
}
struct AA {
Slot*[] slots;
}
unittest {
const(AA) aa;

static assert(is(typeof(aa.slots[0]) == const(Slot*)));
const(Slot)* p = aa.slots[0];   // N.B.: legal
p = p.next; // N.B.: legal
}

Note especially the type checked for in the static assert: you cannot
modify any of the Slot pointers in the AA, but you *can* assign them to
mutable (but tail-const) pointers. Therefore you totally can iterate a
const AA without any casts or any breaking of the type system. And
there's no need to template for mutability either.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them 
all, And thus to Windows bind them. -- Mike Champion

Re: why won't byPair work with a const AA?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/1/17 7:15 PM, H. S. Teoh via Digitalmars-d-learn wrote:

On Tue, Aug 01, 2017 at 07:09:45PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:

If this were a true implementation without the opaqueness, it would
not work properly.

[...]

Actually, a proper implementation would still work, provided you declare
your pointer types carefully.  Sketch of idea:

auto byKeyValue(AA)(AA aa) {
struct Result {
const(Slot)* current; // N.B.: proper type
bool empty() { ... }
auto front() { return Pair(*current); }
void popFront() {
current = current.next;
...
}
}
return Result(aa);
}

Basically, the type of `current` must be const(Slot)* rather than
const(Slot*), which would be the default inferred type. But since it's
legal to assign a const pointer to a pointer to const (you can't modify
the original pointer, nor what it points to, but it's valid to copy the
pointer to a mutable pointer variable, as long as what is pointed to is
still const), this actually will work without breaking / bypassing the
type system.


No, you can't const the Slot, because if the value type is a pointer, 
you can't then cast away the const-ness of it legally.


There are ways to get it right, it involves templating for mutability.

The current code is pretty horrific though, any way you slice it.

-Steve

Re: Adding deprecated to an enum member

[Jeremy DeHaan via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 02:06:27 UTC, dark777 wrote:
I did as follows using deprecated may help you to elucidate in 
relation to this

https://pastebin.com/NEHtWiGx


Deprecating an entire module isn't really a solution though. I 
only want parts of an existing enum to be deprecated when they 
are used.

Re: why won't byPair work with a const AA?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Aug 01, 2017 at 07:09:45PM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 8/1/17 6:50 PM, H. S. Teoh via Digitalmars-d-learn wrote:
[...]
> > Actually, there's nothing about the implementation of both
> > byKeyValue (the underlying implementation in druntime) and byPair in
> > std.array that would preclude them from being used with const AA's.
> > The only flaw is that the declaration of byPair doesn't match const
> > AA's:
> > 
> > https://issues.dlang.org/show_bug.cgi?id=17711
> > 
> > Here's the fix:
> > 
> > https://github.com/dlang/phobos/pull/5668
> 
> It works, because the byKeyValue implementation is so... ugly.
> 
> For instance this:
> 
> return Result(_aaRange(cast(void*)aa));
> 
> Just throws away all const/mutability. However, the Pair struct inside
> restores the correct modifiers. I hope...
> 
> If this were a true implementation without the opaqueness, it would
> not work properly.
[...]

Actually, a proper implementation would still work, provided you declare
your pointer types carefully.  Sketch of idea:

auto byKeyValue(AA)(AA aa) {
struct Result {
const(Slot)* current; // N.B.: proper type
bool empty() { ... }
auto front() { return Pair(*current); }
void popFront() {
current = current.next;
...
}
}
return Result(aa);
}

Basically, the type of `current` must be const(Slot)* rather than
const(Slot*), which would be the default inferred type. But since it's
legal to assign a const pointer to a pointer to const (you can't modify
the original pointer, nor what it points to, but it's valid to copy the
pointer to a mutable pointer variable, as long as what is pointed to is
still const), this actually will work without breaking / bypassing the
type system.


T

-- 
People tell me that I'm skeptical, but I don't believe them.

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 1 August 2017 at 22:52:26 UTC, H. S. Teoh wrote:
On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer 
via Digitalmars-d wrote:

On 8/1/17 6:17 PM, Moritz Maxeiner wrote:

[...]

> import std.algorithm;
> // I probably wouldn't even define this but use the body as 
> is

> auto strnlen_safe(in char[] str)
> {
>  return countUntil(cast(ubyte[]) str, '\0');
> }

Oh that cast it irks me so.

[...]

Welcome to the wonderful world of autodecoding. :-D

OTOH, we could just use byCodeUnit and we wouldn't need the 
cast, I think.


I was lazy, okay (I nearly forgot putting the auto decoding 
prevention in there, because I always forget that D has auto 
decoding; it irks me as well) :p

Re: why won't byPair work with a const AA?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/1/17 6:50 PM, H. S. Teoh via Digitalmars-d-learn wrote:

On Tue, Aug 01, 2017 at 10:04:18AM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:

On 7/30/17 12:19 AM, Matthew Gamble wrote:

[...]

import std.array;
import std.algorithm;

class A
{
  this() { aa = ["a":1, "b" : 2, "c" : 3]; }
  auto pairs() @property const { return
aa.byPair.array.sort().release; }
private:
  int[string] aa;
}

If I remove const from the pairs function it compiles fine. I'm just
not sure this is a behavior I want. Any help/recommendation would be
appreciated.


byPair must store a pointer to the data in the AA. If you mark the AA
const, then it must store a const pointer to AA data.

[...]

Actually, there's nothing about the implementation of both byKeyValue
(the underlying implementation in druntime) and byPair in std.array that
would preclude them from being used with const AA's.  The only flaw is
that the declaration of byPair doesn't match const AA's:

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

Here's the fix:

https://github.com/dlang/phobos/pull/5668


It works, because the byKeyValue implementation is so... ugly.

For instance this:

return Result(_aaRange(cast(void*)aa));

Just throws away all const/mutability. However, the Pair struct inside 
restores the correct modifiers. I hope...


If this were a true implementation without the opaqueness, it would not 
work properly.


-Steve

[Issue 17711] std.array.byPair should be usable with const AA

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from hst...@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/5668

--

Re: all OS functions should be "nothrow @trusted @nogc"

[H. S. Teoh via Digitalmars-d]

On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer via 
Digitalmars-d wrote:
> On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
[...]
> > import std.algorithm;
> > // I probably wouldn't even define this but use the body as is
> > auto strnlen_safe(in char[] str)
> > {
> >  return countUntil(cast(ubyte[]) str, '\0');
> > }
> 
> Oh that cast it irks me so.
[...]

Welcome to the wonderful world of autodecoding. :-D

OTOH, we could just use byCodeUnit and we wouldn't need the cast, I
think. 


T

-- 
Don't get stuck in a closet---wear yourself out.

Re: why won't byPair work with a const AA?

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Aug 01, 2017 at 10:04:18AM -0400, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 7/30/17 12:19 AM, Matthew Gamble wrote:
[...]
> > import std.array;
> > import std.algorithm;
> > 
> > class A
> > {
> >  this() { aa = ["a":1, "b" : 2, "c" : 3]; }
> >  auto pairs() @property const { return
> > aa.byPair.array.sort().release; }
> > private:
> >  int[string] aa;
> > }
> > 
> > If I remove const from the pairs function it compiles fine. I'm just
> > not sure this is a behavior I want. Any help/recommendation would be
> > appreciated.
> 
> byPair must store a pointer to the data in the AA. If you mark the AA
> const, then it must store a const pointer to AA data.
[...]

Actually, there's nothing about the implementation of both byKeyValue
(the underlying implementation in druntime) and byPair in std.array that
would preclude them from being used with const AA's.  The only flaw is
that the declaration of byPair doesn't match const AA's:

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

Here's the fix:

https://github.com/dlang/phobos/pull/5668


T

-- 
Sometimes the best solution to morale problems is just to fire all of the 
unhappy people. -- despair.com

[OT] Alternative to Thunderbird (was: Re: NG technical issues: Is it just me?)

[Ali Çehreli via Digitalmars-d]

On 08/01/2017 09:58 AM, Mike Wey wrote:


The errors seem to be getting more frequent lately. But i nog also get
these errors on the GtkD newsgroup (vibenews) so it might be a
Thunderbird issue.

Is anybody getting the errors with a different client?



Is there a better (lightweight, more stable, etc.) Thunderbird? A couple 
of weeks ago it could not open my Yahoo Inbox any more, so I had to add 
my account again.


Perhaps I should get used to reading news and email with Emacs already. :/

Ali

[Issue 17711] New: std.array.byPair should be usable with const AA

[via Digitalmars-d-bugs]

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

  Issue ID: 17711
   Summary: std.array.byPair should be usable with const AA
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
--
import std.array;
const(int[string]) aa = [ "abc": 123 ];
auto r = aa.byPair;
--

This code ought to compile, but doesn't, because const(int[string]) does not
match the function declaration `auto byPair(K,V)(Value[Key] aa)`.

However, the implementation actually supports iterating over const AA's just
fine. We just need to declare the function differently so that it will match a
const AA type:

--
auto byPair(AA : V[K], V, K)(AA aa)
--

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 8/1/17 6:17 PM, Moritz Maxeiner wrote:

On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer wrote:

On 8/1/17 5:54 PM, Moritz Maxeiner wrote:

On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:

On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d 
wrote:

> Direct OS function calls should probably all be treated as
> >
unsafe, except for rare cases where the behaviour is very > well 
defined in standards and in actual implementations to > be safe. 
The way to get safe functions for OS functionality

> is to write wrapper functions in D which prohibit unsafe >
calls.

+1.


I think I got it now!

size_t strlen_safe(in char[] str) @trusted
{
foreach (c; str)
if (!c)
return strlen(str.ptr);
return str.length;
}

  :o)


I know this is in jest, but since `strlen`'s interface is inherently 
unsafe, yes, the only way to make calling it @safe happens to also 
solve what `strlen` is supposed to solve.
To me the consequence of this would be to not use `strlen` (or any 
other C function where checking the arguments for @safety solves a 
superset of what the C function solves) from D.
I don't think this applies to most OS functions, though, just to (OS 
independent) libc functions.


I think it goes without saying that some functions just shouldn't be 
marked @safe or @trusted. strlen is one of those.




Of course, though I think this (sub) context was more about writing 
@safe D wrappers for @system C functions than about which C functions to 
mark as @trusted/@safe. `strnlen` shouldn't be marked @safe/@trusted, 
either, but writing a @safe D wrapper for it doesn't involve doing in D 
what `strnlen` is supposed to do:


---
size_t strnlen_safe(in char[] str)
{
 return strnlen([0], str.length);
}
---


Most definitely. It would be nice to have a fully @safe interface that 
is as low-level as you can possibly get. Then any library implemented on 
top of it could be marked @safe as well.


Not that there's much of a reason to do so, anyway, when the D idiomatic 
way is just a Phobos away:


---
import std.algorithm;
// I probably wouldn't even define this but use the body as is
auto strnlen_safe(in char[] str)
{
 return countUntil(cast(ubyte[]) str, '\0');
}


Oh that cast it irks me so.

-Steve

Re: gtk arch issues

[FoxyBrown via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 21:03:44 UTC, Mike Wey wrote:

On 01-08-17 22:16, Johnson Jones wrote:

nvm, the file exists.  Why it is not being found is unknown.

I did some stuff and it says it is not a valid win32, this is 
using that gtk3 runtime I linked to... says it's x64 version 
but probably x86.


Would be nice if the error message printed the full path of 
what was being loaded so it's quicker to diagnose.


Seems there is a


> ... code ...


which is used, could I just hijack this to set the correct 
path based on what version it is compiled under? Would be the 
easiest thing, at least as a temporary workaround.




You renamed the gtk DLL's, i assume you simply renamed them, 
but to get things working with different names you would need 
to build GTK from source, and apply the appropriate patches to 
GTK and its make files.




I rebuilt gtkD but obviously not gtk, which I guess was using 
searching the dll's the same way that gtkD did.


If you would use a dependency walker on libgtk-3-0.dll you can 
see that it depends on basically all the other dll's in the 
directory, and by renaming them they can no longer be found. 
For libraries that are in both GTK 3 and GTK 2 it might find 
the libraries distributed with gtksharp but that would also 
fail because of the version difference.




I didn't actually rename, I copied then renamed the copies so 
that the originals were still there. The point was to get gtkD to 
use different versions, which it did, but I guess gtk had the 
same problem with it's versioning where it would simply try to 
use whatever it found in the path.



Printing the full path of the library in the error would only 
only be possible if we call LoadLibrary with the full path. 
It's been a while since i implemented the architecture check 
but if i remember correctly there were some issues with that. 
Otherwise it might be loaded from one of the other directories 
LoadLibrary searches, and then the printed path would be wrong, 
making things even worse.


And yes you could hard code the path that is passed to 
SetDllDirectory as a work around, but the dll's will need to 
have there proper names.


As I stated the last post, everything is working. I reverted back 
to the original gtkD so it uses the original names. I only have 
one GTK dir in the path at a time now rather than both x86 and 
x64. That solved the problem. The only problem that exists now is 
that I have to manually swap the installations of gtkx86 and 
gtkx64. When I switch from from x86 to x64 and vice versa... not 
difficult but I'm sure I'll forget months down the road and waste 
time trying to remember what I needed to do.


So, I have dirs like

C:\Gtkx86
C:\Gtkx64
C:\Gtk

where C:\Gtk is a junction that points to either C:\Gtkx86 or 
C:\Gtkx64 depend on which arch I'm compiling for. The path only 
as C:\Gtk in it so there is no possibility for the dlls to get 
mixed up, which is what happens when both architecture versions 
are in the path.


I'd like to avoid having to change the junction each time I 
decide to test my app in a different architecture. Instead, 
having a simple


version(X86)
   SetGTKDir("C:\\Gtkx86");
version(Win64)
   SetGTKDir("C:\\Gtkx64");

is what I'm after.

this r-value optimizations

[Nordlöw via Digitalmars-d-learn]

Given the `struct S` with lots of data fields, I've written the 
following functional way of initializing only a subset of the 
members in an instance of `S`:


struct S
{
int i;
float f;
...

this(int i) { this.i = i; }

S withF(float f)
{
// will this be optimized out if `this` is an r-value?
S copy = this;
copy.f = f;
return copy;
}
}

Now the question becomes: will the S-copying inside `withF` be 
optimized out in the case when `this` is an r-value such as in 
the call


auto y = S(32).withF(42.0);

?

If not, one solution of doing this manually is to write `withF` 
as a free function


S withF()(auto ref S this_, float f)
{
static if (__traits(isRef, this_))
{
// this_ is an l-value (and was passed by ref)
// so a copy has to be made before modifying it
}
else
{
// this_ is an r-value (and was passed by move)
// so it can be modified in-place
}
}

Is this the preferred way of solving this until we (ever) get 
named parameters in D?

Re: [OT] Generative C++

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 1 August 2017 at 22:11:47 UTC, Stefan Koch wrote:

On Tuesday, 1 August 2017 at 22:06:28 UTC, Walter Bright wrote:

On 7/31/2017 5:41 AM, Joakim wrote:
If he's right that C++ use is so balkanized, this will 
simplify some code but further balkanize the language.  That 
might be worth it for them, but rather than simplifying the 
language, it makes it more powerful and more complex, heading 
higher up into the hills rather than the lower ground he 
claims to be heading for.


I can't say I understand the proposal, but if it is similar to 
AST macros, my argument against that is well known and similar 
to yours.


It's basically a restricted form of AST-Macros.
Not as aweful as it could have been but still quite complex and 
I have no idea how one would implement that efficiently.


Luckily they don't need to: Since when was C++ compilation ever 
efficient?

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer 
wrote:

On 8/1/17 5:54 PM, Moritz Maxeiner wrote:

On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:

On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via 
Digitalmars-d wrote:

> Direct OS function calls should probably all be treated as
> >
unsafe, except for rare cases where the behaviour is very > 
well defined in standards and in actual implementations to > 
be safe. The way to get safe functions for OS functionality

> is to write wrapper functions in D which prohibit unsafe >
calls.

+1.


I think I got it now!

size_t strlen_safe(in char[] str) @trusted
{
foreach (c; str)
if (!c)
return strlen(str.ptr);
return str.length;
}

  :o)


I know this is in jest, but since `strlen`'s interface is 
inherently unsafe, yes, the only way to make calling it @safe 
happens to also solve what `strlen` is supposed to solve.
To me the consequence of this would be to not use `strlen` (or 
any other C function where checking the arguments for @safety 
solves a superset of what the C function solves) from D.
I don't think this applies to most OS functions, though, just 
to (OS independent) libc functions.


I think it goes without saying that some functions just 
shouldn't be marked @safe or @trusted. strlen is one of those.




Of course, though I think this (sub) context was more about 
writing @safe D wrappers for @system C functions than about which 
C functions to mark as @trusted/@safe. `strnlen` shouldn't be 
marked @safe/@trusted, either, but writing a @safe D wrapper for 
it doesn't involve doing in D what `strnlen` is supposed to do:


---
size_t strnlen_safe(in char[] str)
{
return strnlen([0], str.length);
}
---

Not that there's much of a reason to do so, anyway, when the D 
idiomatic way is just a Phobos away:


---
import std.algorithm;
// I probably wouldn't even define this but use the body as is
auto strnlen_safe(in char[] str)
{
return countUntil(cast(ubyte[]) str, '\0');
}
---

Re: [OT] Generative C++

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 August 2017 at 22:06:28 UTC, Walter Bright wrote:

On 7/31/2017 5:41 AM, Joakim wrote:
If he's right that C++ use is so balkanized, this will 
simplify some code but further balkanize the language.  That 
might be worth it for them, but rather than simplifying the 
language, it makes it more powerful and more complex, heading 
higher up into the hills rather than the lower ground he 
claims to be heading for.


I can't say I understand the proposal, but if it is similar to 
AST macros, my argument against that is well known and similar 
to yours.


It's basically a restricted form of AST-Macros.
Not as aweful as it could have been but still quite complex and I 
have no idea how one would implement that efficiently.

Re: [OT] Generative C++

[Walter Bright via Digitalmars-d]

On 7/31/2017 5:41 AM, Joakim wrote:
If he's right that C++ use is so balkanized, this will simplify some code but 
further balkanize the language.  That might be worth it for them, but rather 
than simplifying the language, it makes it more powerful and more complex, 
heading higher up into the hills rather than the lower ground he claims to be 
heading for.


I can't say I understand the proposal, but if it is similar to AST macros, my 
argument against that is well known and similar to yours.

[Issue 15759] chunks should work with only an input range

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15759] chunks should work with only an input range

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/6826427ba55b9ae9a0f64f4489c359a851e08087
Fix issue 15759: Extend std.range.chunks to work with non-forward input ranges.

Add input range example.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 8/1/17 5:54 PM, Moritz Maxeiner wrote:

On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:


On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> Direct OS function calls should probably all be treated as > 
unsafe, except for rare cases where the behaviour is very > well 
defined in standards and in actual implementations to > be safe. The 
way to get safe functions for OS functionality > is to write wrapper 
functions in D which prohibit unsafe > calls.


+1.


I think I got it now!

size_t strlen_safe(in char[] str) @trusted
{
foreach (c; str)
if (!c)
return strlen(str.ptr);
return str.length;
}

  :o)


I know this is in jest, but since `strlen`'s interface is inherently 
unsafe, yes, the only way to make calling it @safe happens to also solve 
what `strlen` is supposed to solve.
To me the consequence of this would be to not use `strlen` (or any other 
C function where checking the arguments for @safety solves a superset of 
what the C function solves) from D.
I don't think this applies to most OS functions, though, just to (OS 
independent) libc functions.


I think it goes without saying that some functions just shouldn't be 
marked @safe or @trusted. strlen is one of those.


-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:

On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via 
Digitalmars-d wrote:
> Direct OS function calls should probably all be treated as 
> unsafe, except for rare cases where the behaviour is very 
> well defined in standards and in actual implementations to 
> be safe. The way to get safe functions for OS functionality 
> is to write wrapper functions in D which prohibit unsafe 
> calls.


+1.


I think I got it now!

size_t strlen_safe(in char[] str) @trusted
{
foreach (c; str)
if (!c)
return strlen(str.ptr);
return str.length;
}

  :o)


I know this is in jest, but since `strlen`'s interface is 
inherently unsafe, yes, the only way to make calling it @safe 
happens to also solve what `strlen` is supposed to solve.
To me the consequence of this would be to not use `strlen` (or 
any other C function where checking the arguments for @safety 
solves a superset of what the C function solves) from D.
I don't think this applies to most OS functions, though, just to 
(OS independent) libc functions.

newCTFE Status August 2017

[Stefan Koch via Digitalmars-d]

Hi Guys,

At the end of July newCTFE became capable of executing the 
bf-ctfe[1] code and pass the tests.

At 5 times the speed. While using 40% the memory.
(It should be noted that the code generated by bf-ctfe is 
optimized to put as little pressure on ctfe as possible and tries 
to avoid the pathological paths which is why the speed 
improvement is not as high as some other code I showed before)


[1] https://github.com/UplinkCoder/bf-ctfe

I've been hard at work to support complex structs.
which means things like trees or lists which have pointers slices 
and stuff in them :)

as well as multi-dimensional arrays and/or slices.

Sadly I temporarily broke the support for string-members in 
structs.

This Month I intend to fix it again :)
As well as working on supporting bounds-checked pointers.
(meaning pointers created from array literals will still carry 
the array-bounds with them)
The easiest way to do this is unifying the way pointers and 
slices are handled.


As all of these changes affect the ABI they are quite tricky to 
actually execute even if they are not that hard in principle.


If all things go smoothly I will implement union support as well.
(nice safe-unions with a hidden type-field that makes sure you 
can only deref where you previously assigned to)


So stay tuned for updates.

Cheers,
Stefan

Re: gtk arch issues

[Mike Wey via Digitalmars-d-learn]

On 01-08-17 22:16, Johnson Jones wrote:

nvm, the file exists.  Why it is not being found is unknown.

I did some stuff and it says it is not a valid win32, this is using that 
gtk3 runtime I linked to... says it's x64 version but probably x86.


Would be nice if the error message printed the full path of what was 
being loaded so it's quicker to diagnose.


Seems there is a


> ... code ...


which is used, could I just hijack this to set the correct path based on 
what version it is compiled under? Would be the easiest thing, at least 
as a temporary workaround.




You renamed the gtk DLL's, i assume you simply renamed them, but to get 
things working with different names you would need to build GTK from 
source, and apply the appropriate patches to GTK and its make files.


If you would use a dependency walker on libgtk-3-0.dll you can see that 
it depends on basically all the other dll's in the directory, and by 
renaming them they can no longer be found. For libraries that are in 
both GTK 3 and GTK 2 it might find the libraries distributed with 
gtksharp but that would also fail because of the version difference.


Printing the full path of the library in the error would only only be 
possible if we call LoadLibrary with the full path. It's been a while 
since i implemented the architecture check but if i remember correctly 
there were some issues with that. Otherwise it might be loaded from one 
of the other directories LoadLibrary searches, and then the printed path 
would be wrong, making things even worse.


And yes you could hard code the path that is passed to SetDllDirectory 
as a work around, but the dll's will need to have there proper names.


--
Mike Wey

Re: all OS functions should be "nothrow @trusted @nogc"

[H. S. Teoh via Digitalmars-d]

On Tue, Aug 01, 2017 at 10:39:35PM +0200, Marco Leise via Digitalmars-d wrote:
> Am Tue, 1 Aug 2017 10:50:59 -0700
> schrieb "H. S. Teoh via Digitalmars-d"
> :
> 
> > On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> > > Direct OS function calls should probably all be treated as unsafe,
> > > except for rare cases where the behaviour is very well defined in
> > > standards and in actual implementations to be safe. The way to get
> > > safe functions for OS functionality is to write wrapper functions
> > > in D which prohibit unsafe calls.  
> > 
> > +1.
> 
> I think I got it now!
> 
>   size_t strlen_safe(in char[] str) @trusted
>   {
>   foreach (c; str)
>   if (!c)
>   return strlen(str.ptr);
>   return str.length;
>   }
> 
>   :o)
[...]

LOL, that's laughably inefficient.  Instead of calling strlen, you might
as well have just looped with an index and returned the index. :-P

foreach (i, c; str)
if (!c) return i;

Oh wait, so we didn't need the wrapper after all. :-P


T

-- 
It's amazing how careful choice of punctuation can leave you hanging:

Re: gtk arch issues(fixed)

[Johnson Jones via Digitalmars-d-learn]

So, The error I currently get is

object.Exception@generated\gtkd\gtkd\Loader.d(125): Library load 
failed (libgdk-3-0x64.dll):  is not a valid Win32 application.


and libgdk-3-0x64.dll was libgdk-3-0.dll from the 64-bit gtk 
package. (I simply added the extension)... the package downloaded 
from the gdk website.


The size of the file is

1.15 MB (1,211,571 bytes)


What's strange is that the file says the original name was 
libgdk-win32-3.0-0.dll..


This is from the supposedly 64-bit package on the gdk website: 
gtk3-runtime_3.22.4_64-bit


I extracted the files directly from that to compare and that is 
what it says... so, if the dll is truly 32-bit then it would 
explain it and the 64-bit runtime is not correct.


Trying the files from http://www.tarnyko.net/dl/gtk.htm still has 
the same name(maybe the name is not correct... but still doesn't 
work).



I've uninstalled all the gtk stuff and reinstalled using that 
website(seems to be a later version?).


Eventually after setting the paths and all that I run the program 
and get a different error: (note the the spelling error)


object.Error@(0): The function you are calling is not pressent in 
your version of GTK+.


0x7FF7DBE8A033 in extern (C) void 
gtkd.Loader.Linker.unsupportedSymbol()
0x7FF7DBAC28BB in gtk.Builder.Builder 
gtk.Builder.Builder.__ctor(immutable(char)[])

0x7FF7DBAC145A in D main at main.d(17)
0x7FF7DBEF0172 in 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x7FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).tryExec(scope void delegate())
0x7FF7DBEF010C in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).runAll()
0x7FF7DBEF007F in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).tryExec(scope void delegate())

0x7FF7DBEEFF9F in d_run_main
0x7FF7DBAC1502 in __entrypoint.main
0x7FF7DBF6B654 in invoke_main at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(65)
0x7FF7DBF6B567 in __scrt_common_main_seh at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(259)
0x7FF7DBF6B42E in __scrt_common_main at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(302)
0x7FF7DBF6B669 in mainCRTStartup at 
f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp(17)

0x7FFB8EBD2774 in BaseThreadInitThunk
0x7FFB90050D51 in RtlUserThreadStart


now trying the the gtkd's gtk64.

woot! which works!

So, the problem is simple(but unfortunately a lot of wasted 
time). gtkD needs to be updated to work well with x64 and x86. I 
think all one has to do is be able to specify which path of gtk 
to use rather than have it search the windows path.


While I could manually rename the dirs or create a script that 
does so, that seems harsh.  It would be nice if we could simply 
set a path in D that gtkD attempts to use as a base path to load 
the dlls.


That way, we can completely avoid windows path if necessary and 
simply use d's version to set the correct path to the correct 
dlls.


(or modified gtkD to work properly with both versions installed 
instead of crapping out on the first instance of the dll it comes 
across if it is not correct... I'd actually prefer both ways 
implemented though so gtkD works better on the end user's end but 
I have more control when developing).

Re: all OS functions should be "nothrow @trusted @nogc"

[Marco Leise via Digitalmars-d]

Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:

> On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> > Direct OS function calls should probably all be treated as unsafe,
> > except for rare cases where the behaviour is very well defined in
> > standards and in actual implementations to be safe. The way to get
> > safe functions for OS functionality is to write wrapper functions in D
> > which prohibit unsafe calls.  
> 
> +1.

I think I got it now!

size_t strlen_safe(in char[] str) @trusted
{
foreach (c; str)
if (!c)
return strlen(str.ptr);
return str.length;
}

  :o)

-- 
Marco

Re: covered - processes output of code coverage analysis performed by the D programming language compiler

[Anton Fediushin via Digitalmars-d-announce]

On Tuesday, 1 August 2017 at 08:19:47 UTC, Szabo Bogdan wrote:

Nice work!

I would like to contribute to such a tool :) I was working at 
something similar with trial( http://trial.szabobogdan.com/ ), 
and I would like to include your library if it's possible.


Thanks! Yes, module "covered.loader" can be used, but it isn't 
complete yet. I'll start working on v1.0.0 tomorrow, changing 
current design (get as much information as possible and store it) 
to a new one (get only required information). This will increase 
speed and decrease memory usage.




this is a sample code coverage report:
http://trial.szabobogdan.com/artifacts/coverage/html/index.html


Nice! I'm using unit-threaded, but trial looks even better. I'll 
try it tomorrow.

Re: How do you use D?

[aberba via Digitalmars-d]

On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
While the Orgs using D page is very nice ... I hoping to hear 
more personal stories ...


So

How do you use D?
I'm a full stack developer using D on my personal backend project 
development and APis.



In work, (key projects or smaller side projects)
in your side project, (github, links please)
I'm working on my own platform using vibe.d and other D dub 
packages.


just to learn something new? (I would easily argue that 
learning D will make you a better C++ programmer, maybe not the 
most efficient way, but I a sure it i very effective)
Even after php and JavaScript, D has made me a matured and 
productive developer. Its expressiveness is unmatched.




Did you introduce D to your work place? How? What challenges 
did you face?

Most people are hooked by popular stuff. Too destructed to focus.



What is you D setup at work, which compiler, which IDE?


Sublime Text Editor + dub + DMD



And any other fun facts you may want to share :)
D is productive, fast, easy, clean and capable more than any 
languagein existence. It a fact. GC is very useful for my use 
case. Dub registry is great way to use libs, community is awesome 
and full of technical/experienced people.


D is a language that takes you to every party.

Re: Bug in gtkd?

[Mike Wey via Digitalmars-d-learn]

On 01-08-17 21:44, Johnson Jones wrote:

On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:

On 01-08-17 05:53, Johnson Jones wrote:




GtkD is currently based on GTK 3 the properties it complains about 
were removed in GTK 3.0.


Which version of glade are you using?


The latest: Glade 3.8.5


Could you check File -> Properties and see what is set as the runtime 
version? It should be at least 3.0 so it doesn't use things that were 
removed.


--
Mike Wey

Re: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

nvm, the file exists.  Why it is not being found is unknown.

I did some stuff and it says it is not a valid win32, this is 
using that gtk3 runtime I linked to... says it's x64 version but 
probably x86.


Would be nice if the error message printed the full path of what 
was being loaded so it's quicker to diagnose.


Seems there is a

public static void loadLibrary(string library)
{
void* handle = pLoadLibrary(library);

//TODO: A more general way to try more than one version.
if ( handle is null && library == importLibs[LIBRARY.GSV] )
handle = pLoadLibrary(importLibs[LIBRARY.GSV1]);

if ( handle is null )
			throw new Exception("Library load failed ("~ library ~"): "~ 
getErrorMessage());


loadedLibraries[library] = handle;
}


	private void* pLoadLibrary(string libraryName, int flag = 
RTLD_NOW)

{
		void* handle = 
dlopen(cast(char*)toStringz(basePath.buildPath(libraryName)), 
flag | RTLD_GLOBAL);


if(!handle){
lastError = dlerror().fromStringz.idup;
}

// clear the error buffer
dlerror();

return handle;
}

private void setDllPath()
{
static bool isSet;

if ( isSet )
return;

string gtkPath = getGtkPath();

if ( gtkPath.length > 0 )
SetDllDirectoryA((gtkPath~'\0').ptr);

isSet = true;
}


which is used, could I just hijack this to set the correct path 
based on what version it is compiled under? Would be the easiest 
thing, at least as a temporary workaround.

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Taylor Hillegeist via Digitalmars-d-announce]

On Monday, 31 July 2017 at 08:51:16 UTC, Mike wrote:

https://github.com/JinShil/svd_to_d

SVD_to_D is a command-line utility that generates D code from 
ARM Cortex-M SVD files.


[...]


Reminds me of something I put together a while ago.
https://github.com/taylorh140/SVD_TO_D
But this looks much nicer, nice work!

Re: gtk arch issues

[Johnson Jones via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 15:14:50 UTC, Mike Wey wrote:

On 01-08-17 01:37, Johnson Jones wrote:


So, the question is, is this a gtkd problem or a gtk problem? 
In either case, what's the way to get them both to work. Do 
you guys actually test out both versions installed on the same 
system?




Gtk also loads some of it's own libraries at start up with 
GModule / LoadLibrary. So with the library names changed GTK 
might be loading the Gtk 2 libraries installed with gtksharp 
instead of the correct ones.


Ok, I renamed Program Files (x86)\GtkSharp so that it effectively 
deleted it,


Same issue though:

C:\Program Files (x86)\Gtk-Runtime\bin\libgdk_pixbuf-2.0-0.dll 
unloaded.

C:\Program Files (x86)\Gtk-Runtime\bin\libepoxy-0.dll unloaded.
C:\Windows\System32\dwmapi.dll unloaded.
C:\Windows\System32\setupapi.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded.
C:\Windows\System32\ole32.dll unloaded.
C:\Windows\System32\winmmbase.dll unloaded.
C:\Windows\System32\winmm.dll unloaded.
C:\Windows\System32\ws2_32.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded.
The thread 0x1590 has exited with code 1 (0x1).
The thread 0x1598 has exited with code 1 (0x1).
The thread 0x1594 has exited with code 1 (0x1).
The program '[5472] test.exe' has exited with code 1 (0x1).


Renaming Program Files (x86)\Gtk-Runtime

Gives

C:\Windows\System32\dwmapi.dll unloaded.
C:\Windows\System32\setupapi.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-gobject-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libcairo-2.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgio-2.0-0.dll unloaded.
C:\Windows\System32\ole32.dll unloaded.
C:\Windows\System32\winmmbase.dll unloaded.
C:\Windows\System32\winmm.dll unloaded.
C:\Windows\System32\ws2_32.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libglib-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgobject-2.0-0.dll unloaded.
C:\Program Files\Gtk-Runtime\bin\libgdk-3-0x64.dll unloaded.
The thread 0x1480 has exited with code 1 (0x1).
The thread 0x1560 has exited with code 1 (0x1).
The thread 0x4f0 has exited with code 1 (0x1).
The program '[3936] test.exe' has exited with code 1 (0x1).

And x86 test.exe gives the error:

"The image File C:\Program 
Files\Gtk-Runtime\bin\libatk-1.0-0.dll" is valid but is for a 
machine type other than the current machine. Select Ok to 
Continue or Cancel to fail the DLL load".


which was the original error I got.

At this point x64 gives the error:

object.Exception@generated\gtkd\gtkd\Loader.d(125): Library load 
failed (libgdk-3-0x64.dll): The specified module could not be 
found.


which has the code:

//TODO: A more general way to try more than one version.
if ( handle is null && library == importLibs[LIBRARY.GSV] )
   handle = pLoadLibrary(importLibs[LIBRARY.GSV1]);

Which, if I'm not mistaken, suggests that maybe it is time to add 
this "more general way" ;)


Now, why it is trying to load libgdk-3-0x64.dll, which is clearly 
one of the modified files, but a dll of gdk, is unclear.


I have no file with gdk in it in any of the proper directories.

tried installing

https://sourceforge.net/projects/gtk3win/files/latest/download

but no luck. Says it's for x86 and x64 but I have my doubts.

So what is going on here?

[Issue 9287] DMD should read from stdin when an input file is "-"

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7d1813309a8c89c8349672ba37a8c15f9d5a42a2
Fix issue 9287 - implement reading source from stdin.

https://github.com/dlang/dmd/commit/28daf534a405e9a07d42afb8f978d8746be7b89a
Merge pull request #6880 from quickfur/stdin

Issue 9287 - Implement -stdin.
merged-on-behalf-of: unknown

--

Re: Bug in gtkd?

[Johnson Jones via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 15:20:08 UTC, Mike Wey wrote:

On 01-08-17 05:53, Johnson Jones wrote:




GtkD is currently based on GTK 3 the properties it complains 
about were removed in GTK 3.0.


Which version of glade are you using?


The latest: Glade 3.8.5

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Johannes Pfau via Digitalmars-d-announce]

Am Mon, 31 Jul 2017 08:51:16 +
schrieb Mike :

> https://github.com/JinShil/svd_to_d
> 
> SVD_to_D is a command-line utility that generates D code from ARM 
> Cortex-M SVD files.
> 
> SVD files are XML files that describe, in great detail, the 
> memory layout and characteristics of registers in an ARM Cortex-M 
> microcontroller. See 
> https://github.com/posborne/cmsis-svd/tree/master/data for a 
> curated list of SVD files for many ARM Cortex-M microcontrollers 
> from various silicon vendeors.
> 
>  From the information in an SVD file, code for accessing the 
> microcontroller's memory-mapped-io registers can be automatically 
> generated, and SVD_to_D does exactly that.

Nice work! SVD seems to be an ARM standard / initiative? I wish there
was something similar for MSP/AVR/PIC controllers.


-- Johannes

Re: all OS functions should be "nothrow @trusted @nogc"

[H. S. Teoh via Digitalmars-d]

On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> Direct OS function calls should probably all be treated as unsafe,
> except for rare cases where the behaviour is very well defined in
> standards and in actual implementations to be safe. The way to get
> safe functions for OS functionality is to write wrapper functions in D
> which prohibit unsafe calls.

+1.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

Re: args.d | a command line argument and config file parser

[H. S. Teoh via Digitalmars-d-announce]

On Tue, Aug 01, 2017 at 03:44:34PM +, Robert burner Schadek via 
Digitalmars-d-announce wrote:
> args.d is a command line argument and config file parser.
> 
> The basic idea of args.d is that that command line options and config
> file options are basically the same or should be.
> The configuration options are build from UDA annotated structs that
> can be nested.
[...]

Cool!  I had the same idea recently and implemented something similar
for one of my projects.  Great minds think alike. :-D

I think UDA-driven configuration parsing is ultimately the right
direction to go.  And by that I mean more than just command-line
parsing, but the parsing of configuration parameters in general,
including command-line options, configuration files, etc..  Usually a
lot of boilerplate is involved in constructing a parser, enumerating
options, then mapping that to configuration variables, adding helpful
descriptions, etc.. All of which are a maintenance burden on the
programmer, because any of these components can become out-of-sync with
each other: the parsing of parameters, the mapping of these parameters
to internal variables, and the help text.

With UDAs, it's possible to unify all three in one declaration, thereby
ensuring things will never go out-of-sync, and also greatly reduces the
amount of boilerplate the programmer has to type.

I didn't look too closely at args.d yet, but in my implementation, I
have UDAs for specifying alternate names for common configuration
parameters (e.g., "outfile=..." instead of "outputFilename=..."). This
allows more user-friendly option names, and also decouples it from
internal variable naming schemes.

There's also UDAs for optionally flattening a nested struct, so that
internally I can have separate structs for configuring each module, but
the main program combines all of them into a single flattened struct, so
that to the user all the options are top-level (can specify
"outfile=..." instead of "backend.outputFilename=..."). The user
shouldn't need to know how the program is organized internally, after
all, yet I can still properly encapsulate configuration parameters
relevant to only that module, thereby avoiding spaghetti dependencies of
modules on a single global configuration struct.


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

Re: Can you parse the d source file during compile time with std.regex?

[12345swordy via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 16:20:07 UTC, Stefan Koch wrote:

On Tuesday, 1 August 2017 at 16:16:46 UTC, 12345swordy wrote:
I don't see this anywhere in the documentation. I am asking 
this as I want to know that it's possible to create a 
attribute to prevent certain functions being called in the 
body of a function. To enforce a certain code standard upon 
myself.


UDA's are your friend here.
There is no need to use parser, and in any case std.regex 
cannot match the regex at ct.
I know that UDA exist, what I want to know if it is possible to 
create one that prevent certain things like calling certain 
functions in a function body Ie

@custom main()
{
 //function body
 example()//throw error by @custom
}
There is no getRawFunctionBody for traits either, so I was 
thinking about using std.regex to get the string of the function 
body and and then parse that string during compile time.


Alex

Re: all OS functions should be "nothrow @trusted @nogc"

[w0rp via Digitalmars-d]

Direct OS function calls should probably all be treated as 
unsafe, except for rare cases where the behaviour is very well 
defined in standards and in actual implementations to be safe. 
The way to get safe functions for OS functionality is to write 
wrapper functions in D which prohibit unsafe calls.

Re: NG technical issues: Is it just me?

[Mike Wey via Digitalmars-d]

On 21-04-17 19:03, Mike Wey wrote:

On 04/21/2017 10:27 AM, Vladimir Panteleev wrote:

On Thursday, 20 April 2017 at 23:37:25 UTC, Ali Çehreli wrote:
*Looks* like a server/network issue but behaves like a screwy local 
issue.


Started happening more in recent weeks.

I don't select automatic checking for messages. I just click on a 
newsgroup and it fails at differing rates. (Pretty good in the last 
couple of days.) When it fails, for me the cure is to click on 
another D newsgroup to make a successful connection and then come 
back to the failed one; then it always succeeds.


It would be helpful if someone could record a packet capture log (e.g. 
with Wireshark) of the problem. The information therein could be the 
first step towards diagnosing the problem.




Ok, here is an Wireshark export of the error and a few successful 
packets beforehand. Hopefully this gives some insight in whats going on.


https://drive.google.com/open?id=0B6DxRRR3v-n9QzhtZmNEbUQzWmM



The errors seem to be getting more frequent lately. But i nog also get 
these errors on the GtkD newsgroup (vibenews) so it might be a 
Thunderbird issue.


Is anybody getting the errors with a different client?

--
Mike Wey

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[MysticZach via Digitalmars-d]

On Monday, 31 July 2017 at 09:55:22 UTC, Nick Treleaven wrote:
This is subjective. If you put `do` on the end of the line, it 
is trivial:


in(x > 4)
out(works)
out(r; r.test)
out(flag) do
{
  // body
}


The common case is for `out` contracts to test for the return 
variable. Something like 90% will therefore look like:


int fun(int x)
out(r; r > 0)
{

}

So it's the uncommon case we're trying to solve for. Requiring 
`do` in precisely one case, which is the rare case in which the 
`out` test has only one identifier, and therefore can't be 
disambiguated from existing `out` contracts, is a solution to 
that problem. It's seems like a complicated one. To me, it's 
simpler to simply require the `;` because it's the uncommon case 
to begin with, and everyone will know what it means because 
they'll be used to seeing `out(r; r > 0)`.


That said, `do` can solve the loophole with the alternative 
ambiguous syntax. For example:


int fun(ref int x, ref int y, ref int z)
out(x) // fine, followed by another contract
out(y != 0) // fine, multiple tokens, unambiguous
out(z) do   // fine, followed by `do`
{
}

If you forget to add the `do` there is an inevitable parsing 
error, so it's not that bad even in the worst case. The error can 
be fixed by changing `out(z)` to `out(z != 0)`, or to `out(z) do` 
as you suggest. `do` is only going to be valuable in that one 
case, though. I'd say it depends where the language designers 
want to pay the cost of solving the problem. Either pay it up 
front with the ugliness of the foreach syntax, or pay it in 
complexity with the different cases of the ambiguous syntax. 
Because it's a programming language and not a sports car, I'd 
probably  choose the consistency of the foreach syntax over the 
attractiveness of the ambiguous syntax. But there's no clear 
winner, IMO.

Re: Can you parse the d source file during compile time with std.regex?

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 16:16:46 UTC, 12345swordy wrote:
I don't see this anywhere in the documentation. I am asking 
this as I want to know that it's possible to create a attribute 
to prevent certain functions being called in the body of a 
function. To enforce a certain code standard upon myself.


UDA's are your friend here.
There is no need to use parser, and in any case std.regex cannot 
match the regex at ct.

Can you parse the d source file during compile time with std.regex?

[12345swordy via Digitalmars-d-learn]

I don't see this anywhere in the documentation. I am asking this 
as I want to know that it's possible to create a attribute to 
prevent certain functions being called in the body of a function. 
To enforce a certain code standard upon myself.

Re: How to build GUI-based applications in D ?

[Dukc via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 15:18:12 UTC, ashit wrote:
i couldn't set control's width and height (Button widget) shows 
error. maybe it works a different way.


1. Try layoutHeight/width. Remember to set it for the main widget 
too, not just the children of it.


2. DlangUI is not intended to define sizes in pixels as a 
standard practice. Instead, use layouts and layout sizes. This is 
intended to courage you to make your program resolution-agnostic.


But I'm a beginner at this topic too. Take these with a grain of 
salt

[Issue 17686] [REG2.075.0] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/1fb7bd7fd889941c818cba6b1eb277e90e61dc9c
Fix issue 17686: [REG2.075.0] Covariant return types doesn't work with override
in some cases

https://github.com/dlang/dmd/commit/413466c796851fae4fb147bb7b3c9bd5da13355b
Merge pull request #7033 from Kozzi11/Issue17686

--

[Issue 17676] [REG 2.075] bad inlining of functions with multiple return statements

[via Digitalmars-d-bugs]

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/d48421509341bfb43ac48cd3b971948f4b55f57b
fix issue 17676: do not inline function with multiple return values as
statements

https://github.com/dlang/dmd/commit/95dba7d707437aa68a21f1e048dac6e18bde043a
Merge pull request #7029 from rainers/issue_17676

--

Re: args.d | a command line argument and config file parser

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

On Tuesday, 1 August 2017 at 15:44:34 UTC, Robert burner

import args;



I suggest adding a module declaration with some kind of top level 
namespace as soon as possible. This is liable to conflict with 
some other module with the same name from a user's project.

args.d | a command line argument and config file parser

[Robert burner Schadek via Digitalmars-d-announce]

args.d is a command line argument and config file parser.

The basic idea of args.d is that that command line options and 
config file options are basically the same or should be.
The configuration options are build from UDA annotated structs 
that can be nested.
The package can be used with dub "argsd": "~>0.2.0" 
http://code.dlang.org/packages/argsd


Less talking more example:

```D
import args;

/** args.d arguments are structures as shown below.
Each argument that should be searched for needs to have $(D 
@Arg())

attached to it.
$(D @Arg()) takes three kinds of parameter.
1. A $(D string) which is used as the help message for that 
argument.
2. A $(D char) which is used as the character for the short 
argument

selector.
3. A $(D Optional) value to make the argument as optional or not 
(default

Optional.yes).
The order of the three parameter is not relevant.
Arguments can be nested, see the nested $(D NestedArgument) $(D 
struct) in

$(D MyAppArguments).
Arguments can be of all primitive types, arrays of primitive 
types and $(D

enum)s.

All arguments take the shape "name value". Equal sign syntax is 
not

supported.
Array values can be given as separate values of as comma 
separated values.


The name of the argument will be derived from the name of the 
member in

the struct. The names are case sensitive.
Arguments in nested structs have the name of the struct prefixed 
(compare

"--nested.someFloatValue).

Short names must be unique. If they are not unique an Exception 
will be
thrown. Short names are used by prefixing the character with a 
single "-".

The short name "-h" is reserved for requestion the help page.

Long names are unique by definition. Long names are prefixed with 
"--".

The long name "--help" is reserved for requestion the help page.

If $(D parseArgsWithConfigFile) is used two more long names are 
reserved,
"--config", and "--genConfig". Both take a $(D string) as 
argument.
"--config filename" will try to parse the file with name $(I 
filename) and

assign the values in that file to the argument struct passed.

"--genConfig filename" can be used to create a config file with
the default values of the argument struct. The name of the config 
file is

again $(I filename).
*/


/** A enum used inside of NestedArguments */
enum NestedEnumArgument {
one,
two,
many
}

/** A struct nested in MyAppArguments */
static struct NestedArguments {
@Arg("Important Help Message") float someFloatValue;

// D allows to assign default values to the arguments
@Arg('z') NestedEnumArgument enumArg = NestedEnumArgument.two;
@Arg() bool someBool;
}

/** The options to the created program. */
static struct MyAppArguments {
@Arg(Optional.no) string inputFilename;
@Arg('b') int[] testValues;

/** All options inside of $(D nested) need to be prefixed with
  "nested.".
*/
@Arg() NestedArguments nested;
}

import std.algorithm.comparison : equal;
import std.format : format;
import std.math : approxEqual;

/** It is good practice to have the arguments write-protected by 
default.

The following three declarations show a possible implementation.
In order to look up a argument the developer would use the $(D 
config())
function, returning him a write-protected version of the 
arguments.
In order to populate the arguments the writable version returned 
from

$(D configWriteable) is passed to $(D parseArgsWithConfigFile).
This, and the option definitions is usually placed in a separate 
file and
the visibility of $(D MyAppArguments arguments) is set to $(D 
private).

*/
MyAppArguments arguments;

ref MyAppArguments configWriteable() {
return arguments;
}

ref const(MyAppArguments) config() {
return arguments;
}

/** This $(D string[]) serves as an example of what would be 
passed to the

$(D main) function from the command line.
*/
string[] args = ["./executablename",
"--nested.someBool",
"--nested.someFloatValue", "12.34",
"--testValues", "10",
"-b", "11,12",
"--nested.enumArg", "many",
"--inputFilename", "nice.d"];

/** Populates the argument struct returned from configWriteable 
with the

values passed in $(D args).

$(D true) is returned if the help page is requested with either 
"-h" or

"--help".
$(D parseArgsWithConfigFile), and $(D parseArgs) will remove all 
used

strings from $(D args).
After the unused strings and the application name are left in $(D 
args).


Replacing $(D parseArgsWithConfigFile) with $(D parseArgs) will 
disable

the config file parsing option.
*/
bool helpWanted = parseArgsWithConfigFile(configWriteable(), 
args);


if(helpWanted) {
/** If the help page is wanted by the user the $(D printArgsHelp)
function can be used to print help page.
*/
printArgsHelp(config(), "A text explaining the program");
}

/** Here it is tested if the parsing of $(D args) was successful. 
*/

Re: How to build GUI-based applications in D ?

[ashit via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 14:57:50 UTC, JamesD wrote:

On Tuesday, 1 August 2017 at 09:31:32 UTC, ashit wrote:

what is the simplest library to create gui applications in D?
i want to create gui applications but couldnt configure the 
tools so far.

[snip]

I recommend you check out the D widget toolkit (DWT).
DWT is a library for creating cross-platform GUI applications.
It's a port of the SWT Java library from Eclipse.

The key advantages of DWT are;

1. Extensive API and examples from SWT that can be searched 
with your Browser

2. Statically linked (don't need an external DLL)
3. Easy to learn and use

Here is the dub package for DWT:
https://code.dlang.org/packages/dwtlib

See more features in the DWT forum:
https://forum.dlang.org/group/dwt

Here are the various GUIs for the D language:
https://wiki.dlang.org/GUI_Libraries



thank you James

i should try that.
i was always enjoy the pure and efficiency of C. that made me 
stubborn to learn java.
but now, as i look behind i know i was wrong. (that caused i miss 
android).

i need to rethink my strategy.

but instead of that C brought me to the MCU's world.

Re: It makes me sick!

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

On Tuesday, 1 August 2017 at 15:16:44 UTC, Vladimir Panteleev 
wrote:

Sorry, isn't that how things work now?


For modules, yes. For packages, no. That inconsistency is what I 
want to change.


So since we have a package here and the compiler doesn't allow 
you to define a package in the existing datetime.d, we have to 
move the file. And unzipping doesn't pick up that the file was 
moved and leaves old stuff behind.


b.d(1): Error: package name 'aa' conflicts with usage as a module 
name in file


That error shouldn't exist.

The problem here is that the compiler picks up the OLD 
datetime.d


If we could just use datetime.d as the package file, there would 
be no old datetime.d anymore.

Re: How to build GUI-based applications in D ?

[ashit via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 10:09:56 UTC, Russel Winder wrote:
I use GtkD (with GStreamerD) for my GUI applications written in 
D.


https://gtkd.org/



thank you Russel.

i have tried to config that several months ago, but no luck.
i should try that once again.

Re: Bug in gtkd?

[Mike Wey via Digitalmars-d-learn]

On 01-08-17 05:53, Johnson Jones wrote:




GtkD is currently based on GTK 3 the properties it complains about were 
removed in GTK 3.0.


Which version of glade are you using?

--
Mike Wey

Re: How to build GUI-based applications in D ?

[ashit via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 09:44:48 UTC, ketmar wrote:

ashit wrote:


[...]


Adam Ruppe has minigui in his arsd[0] repo. and minigui_xml to 
make interface creation easier. it is not really 
well-documented yet, tho, so you will prolly have to figure 
some things on your own.


[0] https://github.com/adamdruppe/arsd


On Tuesday, 1 August 2017 at 09:44:48 UTC, ketmar wrote:

thank you

Re: It makes me sick!

[Vladimir Panteleev via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 14:29:28 UTC, Adam D. Ruppe wrote:
So we can keep the search path: `datetime.di`, then 
`datetime.d`, then `datetime/package.d`, and any one of them, 
as long as it has `module std.datetime;` at the top, can count 
equally as the package.d.


Sorry, isn't that how things work now? The problem here is that 
the compiler picks up the OLD datetime.d, and then things fail at 
the linking stage because symbols in the old datetime.d are not 
present in the new phobos.lib.

Re: How to build GUI-based applications in D ?

[ashit via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 09:39:36 UTC, Daniel Kozak wrote:

https://www.youtube.com/watch?v=5eUL8Z9AFW0

https://github.com/buggins/dlangui


thank you Daniel.

i have tried Dlangui previously and had no luck. but this time i 
could successfully compile my first app. now, i can say level 
zero created.


i couldn't set control's width and height (Button widget) shows 
error. maybe it works a different way.

i used the following code instead, but no effect.

// create some widget to show in window
auto button1 = new Button("btn1", "OK"d).margins(50);
button1.minWidth = 200;
button1.minHeight = 50;
button1.maxWidth = 201;
button1.maxHeight = 51;

also i couldn't compile dlangide. it shows error like every time 
before:


D:\ashit\software\D Compiler\DlangUI\dlangide-master>dub run
Performing "debug" build using dmd for x86.
emsi_containers 0.5.3: target for configuration "library" is up 
to date.

libdparse 0.7.1-beta.7: building configuration "library"...
C:\Users\axar\AppData\Roaming\dub\packages\libdparse-0.7.1beta.7\libdparse\src\ 
dparse\lexer.d(1789,12): Error: module std.math import 'nextPow2' not found
dmd failed with exit code 1.

Re: gtk arch issues

[Mike Wey via Digitalmars-d-learn]

On 01-08-17 01:37, Johnson Jones wrote:


So, the question is, is this a gtkd problem or a gtk problem? In either 
case, what's the way to get them both to work. Do you guys actually test 
out both versions installed on the same system?




Gtk also loads some of it's own libraries at start up with GModule / 
LoadLibrary. So with the library names changed GTK might be loading the 
Gtk 2 libraries installed with gtksharp instead of the correct ones.


--
Mike Wey

Re: It makes me sick!

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/1/17 10:29 AM, Adam D. Ruppe wrote:

On Tuesday, 1 August 2017 at 14:20:00 UTC, Steven Schveighoffer wrote:
But the fix here is to fix the bizarre package.d design. Don't break 
the zip for cases like mine where adding files is a key feature of it.


How should it be fixed?


Well, my preference would be to treat it just like any other module: the 
compiler has a search path, but if it opens a file, the module name is 
definitive.


So we can keep the search path: `datetime.di`, then `datetime.d`, then 
`datetime/package.d`, and any one of them, as long as it has `module 
std.datetime;` at the top, can count equally as the package.d.


I don't remember the reason why we can't just have foo/... and foo.d and 
needed to use foo/package.d to do this.


It does fail to compile though if I use foo.d instead of package.d:

foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module 
name in file foo.d


BTW I kinda want to put `datetime/package.d` first on the search path, 
but I fear that'd hurt the speed of the normal case (every import would 
mean 2 file not found queries until it actually finds the common 
`file.d`)... but it might be worth investigating if we do want to prefer 
it.


Either way, you now have a file that is completely ignored, which is 
going to confuse someone.


I actually think the only "fix" at the moment is to error when both are 
present, since the compiler can't be sure which one is correct. So we 
are stuck with at least trying to find a package file. I don't see the 
speed of opening two files being a huge issue for compilation.


Anyway, if package.d is just like any other module, if we want to break 
up a module, then you can keep the existing file, with the existing 
module declaration, and just start moving stuff out. You wouldn't have 
to literally create a package.d file, you can just keep using your 
existing module.d file.


I'm sure there's a reason why it's this way, but I don't know what it 
is. Anyone remember?


-Steve

Re: How to build GUI-based applications in D ?

[JamesD via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 09:31:32 UTC, ashit wrote:

what is the simplest library to create gui applications in D?
i want to create gui applications but couldnt configure the 
tools so far.

[snip]

I recommend you check out the D widget toolkit (DWT).
DWT is a library for creating cross-platform GUI applications.
It's a port of the SWT Java library from Eclipse.

The key advantages of DWT are;

1. Extensive API and examples from SWT that can be searched with 
your Browser

2. Statically linked (don't need an external DLL)
3. Easy to learn and use

Here is the dub package for DWT:
https://code.dlang.org/packages/dwtlib

See more features in the DWT forum:
https://forum.dlang.org/group/dwt

Here are the various GUIs for the D language:
https://wiki.dlang.org/GUI_Libraries

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/31/17 4:51 AM, Mike wrote:

https://github.com/JinShil/svd_to_d

SVD_to_D is a command-line utility that generates D code from ARM 
Cortex-M SVD files.




Mike, I have to say still your talk in 2014 was one of my favorites. One 
of the things that was so impressive to me was the way you scraped the 
PDF to generate all the registers automatically. Having worked with STM 
chips (not ARM, but really basic 8-bit versions), I can definitely 
appreciate all the work this saves.


This seems like a natural extension, so awesome!

-Steve

A DUB Case Study: Compiling DMD as a Library

[Mike Parker via Digitalmars-d-announce]

Jacob Carlborg announced here recently that he had configured DMD 
to compile as a library. From there, he decided to write a blog 
post intended as an introduction to DUB, with the 
DMD-as-a-library bit as a case study. I convinced him to post it 
on The D Blog and then deviously hijacked his title to put the 
focus on the DMD-as-a-library bit, because that's just cool.


Blog:
https://dlang.org/blog/2017/08/01/a-dub-case-study-compiling-dmd-as-a-library/

reddit:
https://www.reddit.com/r/programming/comments/6qwl5n/using_dub_the_d_build_tool_package_manager_to/

Re: Accessing memory after destroy

[Steven Schveighoffer via Digitalmars-d]

On 7/30/17 9:17 AM, Petar Kirov [ZombineDev] wrote:

On Sunday, 30 July 2017 at 07:45:27 UTC, Johan Engelen wrote:

On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote:


[1] https://dlang.org/spec/class.html#deallocators


If destroy has been called on a class object, then it is a bug to 
access it at any point after that (IIRC, the expectation is that it 
will blow up in your face, because the vtable is gone - TDPL talks 
about this, I believe, but I don't know where my copy is at the 
moment, so I can't check). That being said, the memory is still 
valid. And as Moritz pointed out, if the memory is accessible, the GC 
won't free it. So, it's a bug to access the object, but it should be 
memory safe to do so.


If this is the case, then we really need to improve and pin-down the 
spec on this point.


So `destroy` only calls the destructor and puts the object in 
`T.initializer` (non-constructed) state, and is otherwise not related 
to memory deallocation.

May the destructor be called again when the GC collects the memory?
Why is the object put in `T.initializer` state?


rt_finalize2 zeroes the vptr out after assigning typeid(T).initializer, 
so calling the destructor more than once is not possible, unless someone 
manually saves the vptr and assigns it back to the object after the call 
to destroy / rt_finalize.


Yes, this is on purpose. It's the way the runtime knows it has already 
been run. In fact, destroy used to NOT do this, and that caused problems.


A class instance is not usable after calling destroy. It is not intended 
to be usable, because classes require a constructor call to be valid, 
and there's no way to guarantee you can do this with destroy.


Structs are different.

To make sure: My question is from a spec point of view. Not about what 
currently happens and what is "OK" with the current implementation.


I guess the spec needs to be updated to state explicitly that a class 
destructor is called only once, if that's not already the case.


I thought this was in the spec, but I can't find it. This is definitely 
the case.


-Steve

Re: It makes me sick!

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

On Tuesday, 1 August 2017 at 14:20:00 UTC, Steven Schveighoffer 
wrote:
But the fix here is to fix the bizarre package.d design. Don't 
break the zip for cases like mine where adding files is a key 
feature of it.


How should it be fixed?


Well, my preference would be to treat it just like any other 
module: the compiler has a search path, but if it opens a file, 
the module name is definitive.


So we can keep the search path: `datetime.di`, then `datetime.d`, 
then `datetime/package.d`, and any one of them, as long as it has 
`module std.datetime;` at the top, can count equally as the 
package.d.


BTW I kinda want to put `datetime/package.d` first on the search 
path, but I fear that'd hurt the speed of the normal case (every 
import would mean 2 file not found queries until it actually 
finds the common `file.d`)... but it might be worth investigating 
if we do want to prefer it.



Anyway, if package.d is just like any other module, if we want to 
break up a module, then you can keep the existing file, with the 
existing module declaration, and just start moving stuff out. You 
wouldn't have to literally create a package.d file, you can just 
keep using your existing module.d file.

Re: Convert ResultSet to List of Associted Array

[Jshah via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 14:14:57 UTC, Steven Schveighoffer 
wrote:

On 8/1/17 10:14 AM, Steven Schveighoffer wrote:

On 7/30/17 1:02 PM, Jshah wrote:

On Sunday, 30 July 2017 at 16:39:05 UTC, Jshah wrote:

Hi

I am new to D writing a web service with vibe.

My webservice connect to mysql and return the result
as JSON.

How do I convert resultset to Array of Associated Array
[["col1" : value, "col2" : value], ]


I am using mysql-native


Variant[string][] realresult;
realresult.reserve(resultset.length);
while(!resultset.empty)
{
realresult ~= resultset.asAA;


  resultset.popFront(); // forgot this.

}



-Steve


Thanks It is working

Re: import std.stdio; void main() { size_t count; bool[8191] flags; writeln("10 iterations"); // using iter as a throwaway variable foreach (iter; 1 .. 11) { count = 0; flags[] = 1

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 August 2017 at 14:08:26 UTC, enter per ner wrote:

whats the mistake


you are passing a ptr to writefln.

Re: import std.stdio; void main() { size_t count; bool[8191] flags; writeln("10 iterations"); // using iter as a throwaway variable foreach (iter; 1 .. 11) { count = 0; flags[] = 1

[Anonymouse via Digitalmars-d]

On Tuesday, 1 August 2017 at 14:08:26 UTC, enter per ner wrote:

whats the mistake


For everyone's sanity: https://run.dlang.io/is/bjlaNy

Re: import std.stdio; void main() { size_t count; bool[8191] flags; writeln("10 iterations"); // using iter as a throwaway variable foreach (iter; 1 .. 11) { count = 0; flags[] = 1

[Stefan Koch via Digitalmars-d]

On Tuesday, 1 August 2017 at 14:08:26 UTC, enter per ner wrote:

whats the mistake


wrong forum.

this is for d. learn.
Also you posted the text in the title.

Re: It makes me sick!

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/29/17 3:51 PM, Adam D. Ruppe wrote:

But the fix here is to fix the bizarre package.d design. Don't break the 
zip for cases like mine where adding files is a key feature of it.


How should it be fixed?

-Steve

Re: Convert ResultSet to List of Associted Array

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/1/17 10:14 AM, Steven Schveighoffer wrote:

On 7/30/17 1:02 PM, Jshah wrote:

On Sunday, 30 July 2017 at 16:39:05 UTC, Jshah wrote:

Hi

I am new to D writing a web service with vibe.

My webservice connect to mysql and return the result
as JSON.

How do I convert resultset to Array of Associated Array
[["col1" : value, "col2" : value], ]


I am using mysql-native


Variant[string][] realresult;
realresult.reserve(resultset.length);
while(!resultset.empty)
{
realresult ~= resultset.asAA;


  resultset.popFront(); // forgot this.

}



-Steve

Re: Convert ResultSet to List of Associted Array

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/30/17 1:02 PM, Jshah wrote:

On Sunday, 30 July 2017 at 16:39:05 UTC, Jshah wrote:

Hi

I am new to D writing a web service with vibe.

My webservice connect to mysql and return the result
as JSON.

How do I convert resultset to Array of Associated Array
[["col1" : value, "col2" : value], ]


I am using mysql-native


Variant[string][] realresult;
realresult.reserve(resultset.length);
while(!resultset.empty)
{
   realresult ~= resultset.asAA;
}

-Steve

import std.stdio; void main() { size_t count; bool[8191] flags; writeln("10 iterations"); // using iter as a throwaway variable foreach (iter; 1 .. 11) { count = 0;

[enter per ner via Digitalmars-d]

whats the mistake

Re: why won't byPair work with a const AA?

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/30/17 12:19 AM, Matthew Gamble wrote:
I have a class member function from which I'm trying to return a sorted 
array of key, value tuples stored in an associative array as a private 
member. The member function should be able to be marked const to prevent 
the AA from being modified. I have reduced the problem to the simple 
case below which won't compile with DMD v2.072.2.


import std.array;
import std.algorithm;

class A
{
 this() { aa = ["a":1, "b" : 2, "c" : 3]; }
 auto pairs() @property const { return 
aa.byPair.array.sort().release; }

private:
 int[string] aa;
}

If I remove const from the pairs function it compiles fine. I'm just not 
sure this is a behavior I want. Any help/recommendation would be 
appreciated.


byPair must store a pointer to the data in the AA. If you mark the AA 
const, then it must store a const pointer to AA data.


However, because we don't have tail modifiers, you can't construct just 
one range that would make this work. We would need many different 
ranges, one for each flavor of mutability.


So you are stuck doing what Ali recommended -- cast away the const.

In this case, no harm comes if you don't cast back to const (since the 
value of the AA is `int`), but in general this solution isn't valid if 
the value type contains references.


-Steve

Re: The progress of D since 2013

[Jacob Carlborg via Digitalmars-d]

On 2017-07-31 09:22, Maxim Fomin wrote:

Hi!

Good to see D is progressing! I was active forum and bugzilla
participant in 2011-2013. Since then I have not touched D.

What is the progress of D (2014-2017) in following dimensions:
1) Support of linking in win64? AFAIK Walter introduced win64 support in
circa 2012 which was the big progress. However, support for win64
linking was limited because dmd defaulted on old dmc linker, and Walter
didn't plan to do anything with this.


When compiling for Win64 DMD only works with the Microsoft tool chain. 
For Win32 the default is till DMC/Optlink but a flag can be specified to 
use the Microsoft tool chain there as well. LDC also supports Windows.



2) What is the support of other platforms? AFAIK there was progress on
Android. From my memory recollections, the full support of Android was
expected at that time.


Yes, there's been some great progress in supporting ARM and Andriod, 
which I think is almost ready to be merged upstream into LDC. There's 
also been quite some progress of supporting iOS, but that looks like it 
has stalled now.



3) What is the state of GC? AFAIK there were some improvements for GC
sent as GSOC projects but they were not added in 2013. I see in the
changelog that there are some improvements in speed and configuration
support was added.


Dmitry Olshansky has recently announced that he will work on a new GC 
for D [1]. DIP1000 [2] has been accepted and Walter has started to 
implement it. DIP1000 is something similar to Rust's memory management 
system (but not as complicated and complex) that will allow to 
implement, among other things, safe reference counting. For those that 
don't want to use the GC.



4) What is the state of GDC/LDC? GDC team was actively working on
including gdc in gcc project.


It was recently announced that GDC has been accepted for inclusion into 
GCC [3]. The work as started but is not done yet.



Do gdc and ldc still pull D frontend, so
there is essentially 1 frontend (where gdc and ldc frontends lag several
versions behind) + 3 backends?


Yes. DMD and LDC are using the frontend ported to D. GCC is still on the 
frontend written in C++.



I see in the changelog some dmd backend
improvements. How the dmd backend is compared with C++/GDC/LDC? AFAIK in
2013 there was a tradeoff: either you use dmd with brand-new frontend or
gdc/ldc where performance is comparable to gcc, but frontend lags
behind. Is it still true?


The GCC and LLVM backends are still generating better code than DMD in 
some (most?) cases. But LDC are now usually only one version behind DMD. 
GDC is still on an older version of the frontend.



5) What is the progress with CTFE? I see a lot of discussions in forum
archive devoted to the development of CTFE. What is the summary of CTFE
development in recent years?


Stefan Koch is working on a new CTFE implementation [4]. He's building a 
new proper interpreter which is significantly faster than the existing 
implementation, if I understand correctly.



6) I don't see any significant changes in D core from dlang
documentation (except those mentioned in changelog for 2014-2017). Is is
true or is the official spec as usual delayed :)?


Yes, it's still delayed.


Is dlang spec fully and frequently updated or is it sparse as in the past?


It's not always up to date.


Is TDPL book still relevant?


I think it's mostly up to date. But new features and libraries have been 
added after. Multiple "alias this" are still not implemented.



7) Is UDA still compile-time?


Yes.


Are there plans to make it also runtime?


No. A template exists in druntime that will be instantiated with all 
user defined types. This can be used to extracted UDAs and make 
available at runtime. But this requires you to modify druntime.



8) What is the progress with shared and immutable? AFAIK the compiler
support for shared was not complete and Phobos library itself was not
'immutable-' and 'shared-correct'.


Not much progress, as far as I understand.


10) Anything else 2013 D user must know? :) I don't ask about Phobos
because according to the changelog the progress is enormous,
incremential and targets several directions - I doubt it can be easily
summarised...


A lot of things have happened. Perhaps take a look at the DIPs [5]. 
Although a lot more has happened as well.


[1] http://forum.dlang.org/post/ewdoqmvslcnypzyrb...@forum.dlang.org
[2] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
[3] https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
[4] http://forum.dlang.org/post/inhkfqctiyuapubkl...@forum.dlang.org
[5] https://github.com/dlang/DIPs

--
/Jacob Carlborg

[Issue 16230] core.atomic.atomicLoad removes shared from aggregate types too eagerly

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/7e87d0646a3c2177e41253c7b9c3fca09c6fb08f
prepare for fix of druntime issue 16230

https://github.com/dlang/phobos/commit/b97aa79fb60bdba7a8ab08cf7341b077a5b5efba
Merge pull request #5665 from aG0aep6G/16230

prepare for fix of druntime issue 16230
merged-on-behalf-of: Petar Kirov 

--

[Issue 982] Codeview: symbols of enum type are declared integer

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||symdeb

--

Re: How do you use D?

[Jacob Carlborg via Digitalmars-d]

On 2017-07-28 16:58, Ali wrote:

While the Orgs using D page is very nice ... I hoping to hear more
personal stories ...

So

How do you use D?
In work, (key projects or smaller side projects)
in your side project, (github, links please)
just to learn something new? (I would easily argue that learning D will
make you a better C++ programmer, maybe not the most efficient way, but
I a sure it i very effective)


I mostly use D at my spare time to write tools and libraries for D, 
[1][2][3][4] to mention a few.


I've managed to sneak in some D code at work for a tool [5] that helps 
building slides using Markdown and a build job in GitLab. This is now 
used for our weekly meeting to build a combined slideshow. Although 
nothing in production yet.



Did you introduce D to your work place? How? What challenges did you face?


Yes. The first question that comes up is: "who is using D?" and "are 
there any developers that know D?". The lack of libraries in some areas 
is not helping.



What is you D setup at work, which compiler, which IDE?


TextMate with the default D bundle [6], can be downloaded directly from 
within TextMate. DMD, RDMD, DUB and DCD.


[1] https://github.com/jacob-carlborg/dstep
[2] https://github.com/d-widget-toolkit/dwt
[3] https://github.com/jacob-carlborg/dvm
[4] https://github.com/jacob-carlborg/orange
[5] https://github.com/jacob-carlborg/remarkify
[6] https://github.com/textmate/d.bundle

--
/Jacob Carlborg

[Issue 17710] New: Undefined behaviour and non-working casting of overloaded methods invoking overloaded delegates

[via Digitalmars-d-bugs]

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

  Issue ID: 17710
   Summary: Undefined behaviour and non-working casting of
overloaded methods invoking overloaded delegates
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kamil.sub...@nexwell.eu

Created attachment 1652
  --> https://issues.dlang.org/attachment.cgi?id=1652=edit
Sample code presenting the bug.

Sample code to present the case (also in the attachment):

//

alias BoolFirst = void delegate(bool b, string s);
alias StringFirst = void delegate(string s, bool b);

class Caller {
void call(BoolFirst bs) { bs(true, "text"); }
void call(StringFirst sb) { sb("text", true); }
}

class Writer {
import std.stdio;
void write(bool b, string s) { writeln("bool+string:", b, "/", s); }
void write(string s, bool b) { writeln("string+bool:", s, "/", b); }
}

void main() {
new Caller().call( Writer().write);
}

//

The call in main() is ambiguous, but nevertheless the code compiles and the
program runs the "string+bool" variant. Swapping write() methods in the source
file causes calling "bool+string" variant. Casting call(cast(StringFirst)
) compiles, although is not necessary, because not casting works the
same way, but casting call(cast(BoolFirst) ) - which should help in
calling bool+string variant - does not compile, and the compiler says that
"Caller.call called with argument types (void delegate(bool b, string s))
matches both (...)", which is untrue. Moreover, swapping write() methods again
causes the exact opposite behaviour: cast(BoolFirst) compiles, but is useless,
and cast(StringFirst) does not compile at all.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Kagamin via Digitalmars-d]

On Monday, 31 July 2017 at 13:56:48 UTC, Shachar Shemesh wrote:
One of the things that really bother me with the D community is 
the "100% or nothing" approach.


In the worst case when a function becomes unsafe, only @safe 
attribute will be removed from it, which will be a breaking 
change, but hopefully it will happen rarely enough.

Re: Problem of undefined behaviour with overloaded methods and overloaded delegate's invokers

[John Colvin via Digitalmars-d]

On Tuesday, 1 August 2017 at 11:07:59 UTC, knex wrote:
I came across a strange thing and I am not sure if this is a 
bug or just an undefined behaviour of a compiler. Here is some 
sample code to present the case:


//

alias BoolFirst = void delegate(bool b, string s);
alias StringFirst = void delegate(string s, bool b);

class Caller {
void call(BoolFirst bs) { bs(true, "text"); }
void call(StringFirst sb) { sb("text", true); }
}

class Writer {
import std.stdio;
void write(bool b, string s) { writeln("bool+string:", b, 
"/", s); }
void write(string s, bool b) { writeln("string+bool:", s, 
"/", b); }

}

void main() {
new Caller().call( Writer().write);
}

//

As you can see, I have two classes, both having two overloaded 
methods. Writer has some dummy printing methods for bool and 
string, differing with the order of the arguments, while Caller 
takes one of these methods as a delegate and invokes it. In 
main() I create objects of these classes and call Caller's 
call() with Writer's write().


But - as far as I understand - this call is ambiguous, and 
compiler does not know what should be done here: calling 
call/write pair for bool+string or for string+bool parameters. 
Nevertheless the code compiles and the program runs the fist 
variant. The funny thing is that swapping write() methods in 
the source file causes calling the second one. But OK, suppose 
that this is and should be treated as an undefined behaviour. 
What is actually disturbing here, is that casting like 
c.call(cast(BoolFirst) ) compiles, although is not 
necessary, because not casting works the same way, but casting 
c.call(cast(StringFirst) ) - which should help here in 
calling string+bool variant - does not compile, and the 
compiler says that "Caller.call called with argument types 
(void delegate(string s, bool b)) matches both (...)", which is 
clearly true. Moreover, swapping write() methods again causes 
the exact opposite behaviour: cast(StringFirst) compiles, but 
is useless, and cast(BoolFirst) does not compile at all.


So, is this a bug, or am I just not getting something? In the 
first case, is there some kind of a workaround for the 
possibility of calling both variants (without changing the code 
of Caller and Writer classes)? In the last case, how should I 
do it properly?


I am using DMD32 D Compiler v2.075.0 on Linux.


looks like a bug to me. Please report at issues.dlang.org

Re: Problem of undefined behaviour with overloaded methods and overloaded delegate's invokers

[knex via Digitalmars-d]

Erratum:
which is clearly true ---> which is clearly untrue

Problem of undefined behaviour with overloaded methods and overloaded delegate's invokers

[knex via Digitalmars-d]

I came across a strange thing and I am not sure if this is a bug 
or just an undefined behaviour of a compiler. Here is some sample 
code to present the case:


//

alias BoolFirst = void delegate(bool b, string s);
alias StringFirst = void delegate(string s, bool b);

class Caller {
void call(BoolFirst bs) { bs(true, "text"); }
void call(StringFirst sb) { sb("text", true); }
}

class Writer {
import std.stdio;
void write(bool b, string s) { writeln("bool+string:", b, 
"/", s); }
void write(string s, bool b) { writeln("string+bool:", s, 
"/", b); }

}

void main() {
new Caller().call( Writer().write);
}

//

As you can see, I have two classes, both having two overloaded 
methods. Writer has some dummy printing methods for bool and 
string, differing with the order of the arguments, while Caller 
takes one of these methods as a delegate and invokes it. In 
main() I create objects of these classes and call Caller's call() 
with Writer's write().


But - as far as I understand - this call is ambiguous, and 
compiler does not know what should be done here: calling 
call/write pair for bool+string or for string+bool parameters. 
Nevertheless the code compiles and the program runs the fist 
variant. The funny thing is that swapping write() methods in the 
source file causes calling the second one. But OK, suppose that 
this is and should be treated as an undefined behaviour. What is 
actually disturbing here, is that casting like 
c.call(cast(BoolFirst) ) compiles, although is not 
necessary, because not casting works the same way, but casting 
c.call(cast(StringFirst) ) - which should help here in 
calling string+bool variant - does not compile, and the compiler 
says that "Caller.call called with argument types (void 
delegate(string s, bool b)) matches both (...)", which is clearly 
true. Moreover, swapping write() methods again causes the exact 
opposite behaviour: cast(StringFirst) compiles, but is useless, 
and cast(BoolFirst) does not compile at all.


So, is this a bug, or am I just not getting something? In the 
first case, is there some kind of a workaround for the 
possibility of calling both variants (without changing the code 
of Caller and Writer classes)? In the last case, how should I do 
it properly?


I am using DMD32 D Compiler v2.075.0 on Linux.

Re: [OT] uncovering x86 hardware bugs and unknown instructions by fuzzing.

[Guillaume Chatelet via Digitalmars-d]

On Monday, 31 July 2017 at 23:51:57 UTC, deadalnix wrote:

This man is a superhero.


Actually this guy is Cypher (https://g.co/kgs/NMRPQU), he's just 
back from the Matrix :D

Re: sharedLog between dll

[rikki cattermole via Digitalmars-d-learn]

On 01/08/2017 11:27 AM, Domain wrote:

On Tuesday, 1 August 2017 at 09:06:39 UTC, rikki cattermole wrote:

On 01/08/2017 9:28 AM, Domain wrote:
I want to redirect the sharedLog to my logger in one dll, and all 
dlls will use the new one. What should I do?


sharedLog = new MyLogger(); // this will not change the logger in 
other dll


You said the magic phrase, DLL.

Can't share e.g. classes between dll/host[0].

[0] https://issues.dlang.org/show_bug.cgi?id=4071


That issue is reported 7 years ago!
I think DLL support should be a basic feature.
And I think the core team spend too little time on those features which 
will block the usage of D in the real world.

I have to reconsider using C++ instead.


Please email Walter about this. It works everywhere else.

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

[Mike via Digitalmars-d-announce]

On Monday, 31 July 2017 at 08:51:16 UTC, Mike wrote:

The code generated by SVD_to_D depends on this memory-mapped-IO 
library: https://github.com/JinShil/memory_mapped_io  That 
library uses D's CTFE and meta-programming features to generate 
highly optimized code (for both size and speed) at compile-time 
with additional features such as type safety and 
compile-time-enforced mutability.


By the way, there are a couple of bugs that are preventing me 
from perfecting the memory-mapped-IO library.  It'd be great to 
have them addressed.


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

Thanks,
Mike

Re: sharedLog between dll

[Domain via Digitalmars-d-learn]

On Tuesday, 1 August 2017 at 09:06:39 UTC, rikki cattermole wrote:

On 01/08/2017 9:28 AM, Domain wrote:
I want to redirect the sharedLog to my logger in one dll, and 
all dlls will use the new one. What should I do?


sharedLog = new MyLogger(); // this will not change the logger 
in other dll


You said the magic phrase, DLL.

Can't share e.g. classes between dll/host[0].

[0] https://issues.dlang.org/show_bug.cgi?id=4071


That issue is reported 7 years ago!
I think DLL support should be a basic feature.
And I think the core team spend too little time on those features 
which will block the usage of D in the real world.

I have to reconsider using C++ instead.

Re: How to build GUI-based applications in D ?

[Russel Winder via Digitalmars-d-learn]

I use GtkD (with GStreamerD) for my GUI applications written in D.

https://gtkd.org/

On Tue, 2017-08-01 at 09:31 +, ashit via Digitalmars-d-learn wrote:
> what is the simplest library to create gui applications in D?
> i want to create gui applications but couldnt configure the tools 
> so far.
> i tried to install DFL several times, but it shows some errors 
> while installing (that bold red lables showing : depreacated, 
> depreacated, ... )
> 
> i dont need to build something advanced or so, only that common 
> and simple elements like: buttons, labels, textboxs, ...
> 
> i really like D's syntax (C, C++, C#), but i have nothing to do 
> with command line.
> the good thing about C# (& WPF) is: double click on installer, 
> start design your app.
> 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: is the ubuntu sourceforge repository safe?

[Michael via Digitalmars-d]

On Monday, 24 July 2017 at 11:02:55 UTC, Russel Winder wrote:
On Sun, 2017-07-23 at 18:23 +, Michael via Digitalmars-d 
wrote:


I stopped using it. It kept causing error messages in my 
package manager and I couldn't update it properly so I've just 
stuck to downloading the updates on release.


If we are talking about D-Apt here  
http://d-apt.sourceforge.net/  it seems to be working fine for 
me on Debian Sid.  2.075 just installed this morning.


I stopped using it a while ago as it was constantly causing me 
problems with being unable to check for new package updates. It 
was right when sourceforge was issuing security warnings and I 
couldn't be bothered to try and deal with it.