Re: Basic DerelictOrg and Deimos question

[Mike Parker via Digitalmars-d-learn]

On Friday, 24 October 2014 at 18:16:52 UTC, Justin Whear wrote:

On Fri, 24 Oct 2014 18:04:13 +, WhatMeWorry wrote:

Just for clarity's sake, should I consider the DerelictOrg and 
Deimos
(packages, projects, or libraries) as separate from one 
another?  Or

does DerelictOrg use Deimos behind the scenes?


They are quite different.  The Deimos packages are static 
bindings to the

C
libraries--requiring you to statically link.  This, 
incidentally is why

there
is no Deimos binding for OpenGL: it cannot be statically linked 
(unless

you go
with a software implementation like MESA) because libGL is 
provided by the

end user's video hardware drivers.


To clarify a bit for the OP, I should point out that this isn't 
actually correct. To get the terminology straight, there are two 
types of linking. Static linking means linking with a static 
library. Dynamic linking means linking with an import library on 
Windows or directly with a .so on Posix systems. Static bindings 
support both types, so Deimos does not preclude you from using 
shared libraries. It just always has a link-time dependency.


Dynamic bindings have no link-time dependencies at all. They 
cannot be linked with either static or shared libraries (because 
the external functions are actually function pointers). Instead, 
they use a process called 'dynamic loading' to pull the shared 
library into the process space at run time.


When I first came to D over 10 years ago, the only OpenGL binding 
out there was a static one. It's quite possible to link with the 
OpenGL shared library to get whatever the system provides and 
then pull in later versions at run time. For example, on Windows 
you could get 1.1 by linking (IIRC up to 1.4 since Vista or maybe 
Win 7), but had to load the rest at run time. Of course, OGL is a 
special case.

Re: How do I use dub?

[Mike Parker via Digitalmars-d-learn]

On Friday, 24 October 2014 at 23:50:26 UTC, Minas Mina wrote:
Oh and another thing: The program compiles right now but I 
can't execute it because for some reason:

Failed to create a child process.
Cannot run program 
"/home/minas/Projects/eclipse_workspace/DTest/dtest" (in 
directory "/home/minas/Projects/eclipse_workspace/DTest"): 
error=13, Permission denied


Running from terminal yields the same error.


That's a file permissions problem. Make sure that you have write 
access to that directory.

Re: How do I use dub?

[Mike Parker via Digitalmars-d-learn]

On Friday, 24 October 2014 at 23:46:51 UTC, Minas Mina wrote:



The way I specified the library seems very ugly to me. 
Essentially it's a full path... How can I tell dub to use it by 
locating it automatically from its local repository?


You don't. That's what dub does by default.

Re: DirEntry on Windows - wstring variant?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, October 25, 2014 01:11:26 dcrepid via Digitalmars-d-learn wrote:
> On Friday, 24 October 2014 at 22:53:15 UTC, Jonathan M Davis via
> Anyway, some things to think about.

DirEntry and all of the related functions and types would need quite a bit of
rewriting to do what you're suggesting, and most folks aren't going to be
using the Windows API enough for it to matter that std.file operates on string
rather than wstring. And much as the Windows API unfortunately uses wchar all
over the place, the functions that are being used internally in dirEntries and
company and using static arrays of wchar, so it's not like using wstring
instead of string would avoid any allocations. All it would do would be to
avoid decoding and re-encoding the Unicode from UTF-16 to UTF-8. Additionally,
the cost of the file operations would dwarf the cost of any allocations
anyway. So, I'm not in the least bit convinced that altering anything in
std.file to use wstring would be of much benefit, and all previous suggestions
to support wstring anywhere in std.file have been shot down (and iin at least
one case, it was by Walter Bright, and he works on Windosw primarily).

- Jonathan M Davis

Re: DirEntry on Windows - wstring variant?

[dcrepid via Digitalmars-d-learn]

On Friday, 24 October 2014 at 22:53:15 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:


Also, given how DirEntry works internally, I'd definitely be 
inclined to argue
that it would be too much of a mess to support wstring unless 
it's by simply
converting the name to a wstring when requested (which is kind 
of pointless,
since you can just do to!wstring on the name if that's what you 
want). Making
it support wstring directly would involve a lot of code 
duplication, and it
would increase the memory footprint, because the structs 
involved would then
have to hold the path and whatnot as both a string and wstring. 
So, I question
that it's at all worth it to try and make dirEntries support 
wstring.


I would suggest that the string be kept as wstring inside the 
DirEntry structure, rather than converting twice as you suggest. 
Then a decision can be made as to whether .name() returns a 
string or wstring. If backwards compatibility is a concern, then 
it could be converted to a string on that call. It would break 
the nothrow promise that way, though. Adding something like 
.wname() would work here for getting the native wstring, I 
suppose.


Another alternative is to have a union of string and wstring, and 
a bool indicating how strings are handled internally. Of course, 
the .name and .wname properties would need to check it and 
convert depending on how it is stored.  Its not pretty, but its 
just another possibility.


The whole point is that there is a lot of wasted time doing the 
UTF16-UTF8 conversions when using these library functions.



And we
definitely don't want to encourage the use of wstring. It's 
there for when you
need it (which is great), but programs really should be using 
string if they

don't actually need to use wstring or dstring.


I get that wstring on a whole is ugly, but its the native unicode 
string type in Windows.  If someone is doing serious work on 
Windows, wstring will eventually need to be used.  It'd be nice 
to keep the abstraction of string at every level of a program, 
but in Windows its impossible. The standard library, even if it 
was comprehensive enough, will never cover every corner case 
where strings are needed.  Whether using the Windows API, COM, or 
interfacing with other Windows libraries, wstring will still rear 
its ugly head.


But, idealism aside, there are good reasons for keeping the 
pathname in its native format on Windows:
- If a program is processing lots of files, there's going to be a 
lot of wasted cycles doing those wstring->string conversions.
- Doing anything more with the files, besides listing them, will 
probably result in a string->wstring conversion during a call to 
Windows for opening or querying information about the file = more 
cycles wasted
- Additionally, Windows has a peculiar way of handling long 
pathnames that requires a "\\?\" prefix, and only works with the 
unicode versions of its functions. This also makes the pathname 
uniquely OS-specific..


Anyway, some things to think about.

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 21:02:05 UTC, Kapps wrote:

On Friday, 24 October 2014 at 18:38:39 UTC, tcak wrote:

On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:

This is what I did on shell: (I put some spaces for 
readability)


tolga@tolga:~/dev/d/bug$ dmd -gc -debug test.d

tolga@tolga:~/dev/d/bug$ gdb ./test



Yes, GDB is stopping on SIGUSR1 / SIGUSR2 since that's the 
default settings. D's GC uses these signals for suspending / 
resuming threads during a collection. You need to type what I 
said above, prior to typing 'run'.


I was desperately looking for a solution how to do this on Mono-D 
instead

of entering on shell. Then I have found this link:

http://www.mono-project.com/docs/debug+profile/debug/

Under the title "Debugging with GDB", it says to create 
".gdbinit" file
in home folder and put those "handle SIGUSR1..." things into it. 
Then
I opened the preferences of MonoDevelop, and brought the GDB with 
D language

support as first in preferred debugger list.

Tada! It works now. I really thank you.

BUT, since Mono-D comes with "GDB with D language support" as 
well, this
process should have been automated in my opinion knowing that GC 
would

be using those signals.

Re: template type deduction of static 2d arrays

[ketmar via Digitalmars-d-learn]

On Sat, 25 Oct 2014 00:38:37 +
uri via Digitalmars-d-learn  wrote:

> On Saturday, 25 October 2014 at 00:00:54 UTC, ketmar via 
> Digitalmars-d-learn >
> 
> 
> > we have a nice PR from Kenji that allows the following 
> > declarations:
> >
> >   int[$][$] a = [ [1,2],[3,4] ];
> >
> > but alas, it's not in the mainline yet.
> This will be cool, especially auto[$][$] also works.
yes, it works with that PR. i don't remember why it wasn't accepted,
though. i'm using it in my DMD build since day one and observed no
problems at all.


signature.asc
Description: PGP signature

Re: Why do some language-defined attributes have @ and some not?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 24, 2014 23:38:38 Chris Williams via Digitalmars-d-learn 
wrote:
> On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby
>
> wrote:
> > On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma
> > via Digitalmars-d-
> >
> >> I submit that the syntax for attributes should be streamlined.
> >> Shall I
> >> go and open a Bugzilla item?
> >
> > No need: http://wiki.dlang.org/DIP64
>
> Besides the @ symbols, isn't there also some inconsistency on
> whether attributes go before or after the declaration?
>
> @property public static void foo() const @safe pure nothrow
>
> I've never bothered to ascertain how much of the positioning is
> optional, but definitely none of it makes sense.

Yeah. Some attributes are legal on both sides, others on only one, and I'm not
aware of much logic to it (though at the moment, I don't think that there are
any that are only legal on the right, so you could get away with just putting
them all on the left). I think that it's primarily attributes that exist in
other languages (and go on the left in those languages) that have to go on the
left (e.g. public, private, static). Most (all?) of the D-specific ones can go
on both sides. The ones that actually cause problems with that though are
const, immutable, inout, and shared, because without parens, when they're put
on the left, they still affect the function and not the return type, so quite
a few of us have argued that they should be illegal on the left.

- Jonathan M Davis

Re: template type deduction of static 2d arrays

[uri via Digitalmars-d-learn]

On Saturday, 25 October 2014 at 00:00:54 UTC, ketmar via 
Digitalmars-d-learn >



we have a nice PR from Kenji that allows the following 
declarations:


  int[$][$] a = [ [1,2],[3,4] ];

but alas, it's not in the mainline yet.




This will be cool, especially auto[$][$] also works.

thanks,
uri

Re: template type deduction of static 2d arrays

[uri via Digitalmars-d-learn]

On Friday, 24 October 2014 at 23:46:28 UTC, uri wrote:



On a related note, does the D spec guarantee the following will 
be rectangular in memory?


auto a = [ [1,2],[3,4] ];


Cheers,
uri


I just checked the docs and auto a = [ [1,2],[3,4] ] will be an 
an array of pointers. So this cannot work (unless the compiler 
truly is magical :)


auto a = [ [1,2],[3,4] ];
cast(int[2][2])(a);

but this should work:

enum a = [ [1,2],[3,4] ];
cast(int[2][2])(a);


(all untested)

Thanks,
uri

Re: template type deduction of static 2d arrays

[ketmar via Digitalmars-d-learn]

On Fri, 24 Oct 2014 23:46:27 +
uri via Digitalmars-d-learn  wrote:

> On a related note, does the D spec guarantee the following will 
> be rectangular in memory?
> 
> auto a = [ [1,2],[3,4] ];
ah, no, it's not. this is array of arrays, i.e. 'int[][]'. only static
arrays are guaranteed to be placed as one block of data. this will:

  int[2][2] a = [ [1,2],[3,4] ];

we have a nice PR from Kenji that allows the following declarations:

  int[$][$] a = [ [1,2],[3,4] ];

but alas, it's not in the mainline yet.


signature.asc
Description: PGP signature

Re: How do I use dub?

[Minas Mina via Digitalmars-d-learn]

Oh and another thing: The program compiles right now but I can't 
execute it because for some reason:

Failed to create a child process.
Cannot run program 
"/home/minas/Projects/eclipse_workspace/DTest/dtest" (in 
directory "/home/minas/Projects/eclipse_workspace/DTest"): 
error=13, Permission denied


Running from terminal yields the same error.

How do I use dub?

[Minas Mina via Digitalmars-d-learn]

I intent to use D to make a small 2D game.
I have downloaded eclipse, DDT plugin and dub. I also set the 
path to dub in eclipse.


So I made a new project, tested a writeln and it worked. The next 
step was to add some dependencies for derelict. I need SFML for 
now (and DerelictUtils of course).


So this is what I've done:

{
"name" : "DTest",
"description" : "A minimal D bundle.",
"dependencies" : {

"derelict-util": ">=1.0.3",
"derelict-sfml2": "~2.1"
},

"versions-x86_64": ["UseAmd64Impl"],
	"lflags": ["-I/home/minas/.dub/packages/derelict-sfml2-2.1/lib", 
"-LDerelictSFML2"]

}


The way I specified the library seems very ugly to me. 
Essentially it's a full path... How can I tell dub to use it by 
locating it automatically from its local repository?

Re: template type deduction of static 2d arrays

[uri via Digitalmars-d-learn]

On Friday, 24 October 2014 at 23:20:02 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Fri, 24 Oct 2014 22:32:57 +
uri via Digitalmars-d-learn  
wrote:



Hi All,

I was wondering why in the code below f1() works but f2 
template version called in the same manner does not. Is there 
a good reason from a language/compiler perspective?


Thanks.
uri


---
auto f1(int[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}
auto f2(T)(T[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}

void main()
{
 auto res = f1( [[1,2],[3,4]]); // works
 assert(res == -2);

 res = f2([[1,2],[3,4]]); // deos not work
}

Calling f2() as done above gives the following error:

Error: cannot deduce function from argument types 
!()(int[][]), candidates are:

f2(T)(T[2][2] m)

by the way, this will work too:

  int[2][2] v = [[1,2],[3,4]];
  res = f2(v);

'cause 'v' has correct type, and initializing 'v' does 'magic 
casting'.


Thanks for replying.

I think it should work because there's no ambiguity. I now have 
to uglify my code and make it !@safe or create a temporary.


I also noticed this when trying things out:

auto f2(T)(int[2][2] m) // Same error as above
auto f2()(int[2][2] m) // Works as per non-template function


On a related note, does the D spec guarantee the following will 
be rectangular in memory?


auto a = [ [1,2],[3,4] ];


Cheers,
uri

Re: Why do some language-defined attributes have @ and some not?

[Chris Williams via Digitalmars-d-learn]

On Thursday, 23 October 2014 at 07:39:21 UTC, Gary Willoughby
wrote:
On Thursday, 23 October 2014 at 00:59:26 UTC, Shriramana Sharma 
via Digitalmars-d-
I submit that the syntax for attributes should be streamlined. 
Shall I

go and open a Bugzilla item?


No need: http://wiki.dlang.org/DIP64


Besides the @ symbols, isn't there also some inconsistency on
whether attributes go before or after the declaration?

@property public static void foo() const @safe pure nothrow

I've never bothered to ascertain how much of the positioning is
optional, but definitely none of it makes sense.

Re: Dynamically Loading a D DLL From a C Program in Linux

[John McFarlane via Digitalmars-d-learn]

On Friday, 24 October 2014 at 22:33:09 UTC, bachmeier wrote:
I can't answer the first question, but for the second, I've 
given an example here:


http://forum.dlang.org/post/zfdvrwvgavykauczb...@forum.dlang.org

I've done that many, many times and do not see any problems 
related to the runtime.


On Friday, 24 October 2014 at 20:59:20 UTC, John McFarlane 
wrote:
I'm following the preliminary example "Dynamically Loading a D 
DLL From a C Program" here: 
http://dlang.org/dll-linux.html#dso9


Firstly, my output is different:

+main()
libdll.so is loaded
dll() function is found
dll()
unloading libdll.so
-main()

If looks like static this and ~this are not being called.

Secondly, when I replace printf with writeln, I get a seg 
fault. Trying to do just about anything beyond adding numbers 
and returning the result causes a similar crash.


I'm wondering whether D runtime is being initialized 
correctly. Can anyone suggest what I would do to ensure this? 
A more finalized example would be useful also.


DMD64 D Compiler v2.066.0
Ubuntu 10.04 64bit

Many thanks,
John


Thanks. That gets me a lot futher.

Re: template type deduction of static 2d arrays

[ketmar via Digitalmars-d-learn]

On Fri, 24 Oct 2014 22:32:57 +
uri via Digitalmars-d-learn  wrote:

> Hi All,
> 
> I was wondering why in the code below f1() works but f2 template 
> version called in the same manner does not. Is there a good 
> reason from a language/compiler perspective?
> 
> Thanks.
> uri
> 
> 
> ---
> auto f1(int[2][2] m)
> {
>  return m[0][0]*m[1][1]-m[0][1]*m[1][0];
> }
> auto f2(T)(T[2][2] m)
> {
>  return m[0][0]*m[1][1]-m[0][1]*m[1][0];
> }
> 
> void main()
> {
>  auto res = f1( [[1,2],[3,4]]); // works
>  assert(res == -2);
> 
>  res = f2([[1,2],[3,4]]); // deos not work
> }
> 
> Calling f2() as done above gives the following error:
> 
> Error: cannot deduce function from argument types !()(int[][]), 
> candidates are:
> f2(T)(T[2][2] m)
by the way, this will work too:

  int[2][2] v = [[1,2],[3,4]];
  res = f2(v);

'cause 'v' has correct type, and initializing 'v' does 'magic casting'.


signature.asc
Description: PGP signature

Re: template type deduction of static 2d arrays

[ketmar via Digitalmars-d-learn]

On Fri, 24 Oct 2014 22:32:57 +
uri via Digitalmars-d-learn  wrote:

D doesn't try to convert types on template argument deduction. what you
really get from '[[1,2],[3,4]]' is (int[][]), not (int[2][2]). note
that static arrays are not the same thing as dynamic arrays. for 'f1'
compiler doing this behind the curtains: 'cast(int[2][2])[[1,2],[3,4]]'.
but for 'f2' compiler can't do this, it must use the type that was
given to it. so it tries template with 'int[][]' and fails.

you can either change your template to `auto f2(T)(T[][] m)` (so it
accepts dynamic arrays', or explicitly cast your array literal:
`res = f2(cast(int[2][2])[[1,2],[3,4]]);`.


signature.asc
Description: PGP signature

Re: template type deduction of static 2d arrays

[Rikki Cattermole via Digitalmars-d-learn]

On 25/10/2014 11:32 a.m., uri wrote:

Hi All,

I was wondering why in the code below f1() works but f2 template version
called in the same manner does not. Is there a good reason from a
language/compiler perspective?

Thanks.
uri


---
auto f1(int[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}
auto f2(T)(T[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}

void main()
{
 auto res = f1( [[1,2],[3,4]]); // works
 assert(res == -2);

 res = f2([[1,2],[3,4]]); // deos not work
}

Calling f2() as done above gives the following error:

Error: cannot deduce function from argument types !()(int[][]),
candidates are:
f2(T)(T[2][2] m)


res = f2(cast(int[2][2])[[1,2],[3,4]]);
Should work.
I believe this the old nefarious type deduction problem for literal arrays.
Basically the array literals are not literally literals but instead 
normal arrays.

Re: DirEntry on Windows - wstring variant?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 24, 2014 21:06:37 dcrepid via Digitalmars-d-learn wrote:
> As a Windows programmer using D, I find a number of questionable
> things with D's focus on using string everywhere. It's not a huge
> deal to add in UTF-8 to UTF-16 mapping in certain areas, but when
> it comes to working with a lot of data and Windows API calls, the
> less needless conversions the better.
>
> I like the DirEntries (std.file) approach to traversing files and
> folders in a directory (almost as nice as C++14's ),
> but I think its a bit odd that native-OS strings aren't used in D
> here.  Sure, I get that having a fairly consistent programming
> interface may make using the language easier for certain
> programmers, but if you're using D with Windows, then you will be
> made well aware of the incompatibilities between D's strings and
> the Windows API (unless you always use ASCII I suppose).
>
> Anyway, I'm curious if proposing changes to those interfaces is
> worthwhile, or if I should just modify it for my own purposes and
> leave the standard library be.
>
> P.S. Its a shame to keep running into Unicode issues with D and
> Windows, and sometimes its a bit discouraging. Right before I
> peeked into DirEntry, I worked a bit on a workaround for
> stdio.File's unicode problems (a documented bug thats 2+ years
> old). I remember trying D a while back and giving up because
> optlink was choking on paths. And just yesterday it choked on
> what the %PATH% environment variable was set to, so I had to
> clear that before running it.

I don't know. The expectation is generally that programs will use string and
that wstring will be used only in the rare cases that you have to interact
directly with the Windows API. When it was suggested previously that the
various functions in std.file be templatized on string type to support other
string types, it was decided that that was unnecessary code bloat and not
worth it.

Also, given how DirEntry works internally, I'd definitely be inclined to argue
that it would be too much of a mess to support wstring unless it's by simply
converting the name to a wstring when requested (which is kind of pointless,
since you can just do to!wstring on the name if that's what you want). Making
it support wstring directly would involve a lot of code duplication, and it
would increase the memory footprint, because the structs involved would then
have to hold the path and whatnot as both a string and wstring. So, I question
that it's at all worth it to try and make dirEntries support wstring. And we
definitely don't want to encourage the use of wstring. It's there for when you
need it (which is great), but programs really should be using string if they
don't actually need to use wstring or dstring.

- Jonathan M Davis

Re: Reflections on isPalindrome

[Nordlöw]

On Friday, 24 October 2014 at 22:29:12 UTC, Peter Alexander wrote:

On Friday, 24 October 2014 at 21:56:20 UTC, Nordlöw wrote:

bool isPalindrome(R)(in R range) @safe pure


Aside: for templates, just let the compiler infer @safe and 
pure. You don't know whether the range operations on R are pure 
or not.


As for the actual algorithm, there's no need for the random 
access version, and you bidirectional version does twice as 
much as necessary:


Just do:

while (!range.empty)
{
  if (range.front != range.back) return false;
  range.popFront();
  if (range.empty) break;
  range.popBack();
}
return true;

This automatically handles narrow strings.


Further, I would like to extend isPalindrome() with a minimum 
length argument minLength that for string and wstring does


import std.uni: byDchar;
range.byDchar.array.length >= minLength.

AFAIK this will however prevent my algorithm from being 
single-pass right?


I'm not sure what you are saying here, but hopefully the above 
code obviates this anyway.


Clever. Thx!

Re: Dynamically Loading a D DLL From a C Program in Linux

[bachmeier via Digitalmars-d-learn]

I can't answer the first question, but for the second, I've given 
an example here:


http://forum.dlang.org/post/zfdvrwvgavykauczb...@forum.dlang.org

I've done that many, many times and do not see any problems 
related to the runtime.


On Friday, 24 October 2014 at 20:59:20 UTC, John McFarlane wrote:
I'm following the preliminary example "Dynamically Loading a D 
DLL From a C Program" here: http://dlang.org/dll-linux.html#dso9


Firstly, my output is different:

+main()
libdll.so is loaded
dll() function is found
dll()
unloading libdll.so
-main()

If looks like static this and ~this are not being called.

Secondly, when I replace printf with writeln, I get a seg 
fault. Trying to do just about anything beyond adding numbers 
and returning the result causes a similar crash.


I'm wondering whether D runtime is being initialized correctly. 
Can anyone suggest what I would do to ensure this? A more 
finalized example would be useful also.


DMD64 D Compiler v2.066.0
Ubuntu 10.04 64bit

Many thanks,
John

template type deduction of static 2d arrays

[uri via Digitalmars-d-learn]

Hi All,

I was wondering why in the code below f1() works but f2 template 
version called in the same manner does not. Is there a good 
reason from a language/compiler perspective?


Thanks.
uri


---
auto f1(int[2][2] m)
{
return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}
auto f2(T)(T[2][2] m)
{
return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}

void main()
{
auto res = f1( [[1,2],[3,4]]); // works
assert(res == -2);

res = f2([[1,2],[3,4]]); // deos not work
}

Calling f2() as done above gives the following error:

Error: cannot deduce function from argument types !()(int[][]), 
candidates are:

f2(T)(T[2][2] m)

Re: new(malloc) locks everything in multithreading

[Sean Kelly via Digitalmars-d-learn]

On Friday, 24 October 2014 at 21:02:05 UTC, Kapps wrote:


Yes, GDB is stopping on SIGUSR1 / SIGUSR2 since that's the 
default settings. D's GC uses these signals for suspending / 
resuming threads during a collection. You need to type what I 
said above, prior to typing 'run'.


I took a look at the Boehm GC earlier today and it appears
they've made the signal set configurable, both to try and not use
SIGUSR1/2 by default and to let the user specify another signal
set if they need SIGUSR1/2 for some reason.  It's probably worth
doing this in our own code as well.  The Boehm GC also does some
magic with clearing signals at various points to make sure the
right signal handlers will be called.  Probably another
enhancement request.

Re: Reflections on isPalindrome

[Peter Alexander via Digitalmars-d-learn]

On Friday, 24 October 2014 at 21:56:20 UTC, Nordlöw wrote:

bool isPalindrome(R)(in R range) @safe pure


Aside: for templates, just let the compiler infer @safe and pure. 
You don't know whether the range operations on R are pure or not.


As for the actual algorithm, there's no need for the random 
access version, and you bidirectional version does twice as much 
as necessary:


Just do:

while (!range.empty)
{
  if (range.front != range.back) return false;
  range.popFront();
  if (range.empty) break;
  range.popBack();
}
return true;

This automatically handles narrow strings.


Further, I would like to extend isPalindrome() with a minimum 
length argument minLength that for string and wstring does


import std.uni: byDchar;
range.byDchar.array.length >= minLength.

AFAIK this will however prevent my algorithm from being 
single-pass right?


I'm not sure what you are saying here, but hopefully the above 
code obviates this anyway.

Re: Reflections on isPalindrome

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

On Fri, Oct 24, 2014 at 09:56:18PM +, "Nordlöw" via Digitalmars-d-learn 
wrote:
> I would appreciate comments on my palindrome predicate function
> 
> bool isPalindrome(R)(in R range) @safe pure
> if (isBidirectionalRange!(R))
> {
> import std.range: retro, take;
> import std.algorithm: equal;
> static if (hasLength!R)
> {
> const mid = range.length/2; // too long for string
> return equal(range.retro.take(mid),
>  range.take(mid));
> }
> else
> {
> return range.retro.equal(range);
> }
> }
[...]

I'd just do it the simple way using range primitives:

bool isPalindrome(R)(in R range)
if (isBidirectionalRange!R)
{
auto r = range.save;
while (!r.empty)
{
if (r.front != r.back)
return false;
r.popFront();
r.popBack();
}
return true;
}

This is guaranteed to work on all bidirectional ranges in single-pass,
handles odd/even lengths correctly, and doesn't depend on .length.

Offhand remark: in general you shouldn't annotate template functions
with @safe or pure. Instead, let the compiler infer those attributes,
and use @safe/pure unittests with known @safe/pure ranges to ensure your
code itself doesn't introduce any un-@safe or impure operations.
Otherwise, your function cannot be used with a range that has un-@safe
or impure range methods.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.

Reflections on isPalindrome

[Nordlöw]

I would appreciate comments on my palindrome predicate function

bool isPalindrome(R)(in R range) @safe pure
if (isBidirectionalRange!(R))
{
import std.range: retro, take;
import std.algorithm: equal;
static if (hasLength!R)
{
const mid = range.length/2; // too long for string
return equal(range.retro.take(mid),
 range.take(mid));
}
else
{
return range.retro.equal(range);
}
}
unittest
{
assert("dallassallad".isPalindrome);
assert(!"ab".isPalindrome);
assert("a".isPalindrome);
assert("åäå".isPalindrome);
assert("".isPalindrome);
assert([1, 2, 2, 1].isPalindrome);
}
alias isSymmetrical = isPalindrome;

also defined here

https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L773

Specifically I wonder what to do with

const mid = range.length/2; // TODO too long for string

when R is a string.

Further, I would like to extend isPalindrome() with a minimum 
length argument minLength that for string and wstring does


import std.uni: byDchar;
range.byDchar.array.length >= minLength.

AFAIK this will however prevent my algorithm from being 
single-pass right?

DirEntry on Windows - wstring variant?

[dcrepid via Digitalmars-d-learn]

As a Windows programmer using D, I find a number of questionable 
things with D's focus on using string everywhere. It's not a huge 
deal to add in UTF-8 to UTF-16 mapping in certain areas, but when 
it comes to working with a lot of data and Windows API calls, the 
less needless conversions the better.


I like the DirEntries (std.file) approach to traversing files and 
folders in a directory (almost as nice as C++14's ), 
but I think its a bit odd that native-OS strings aren't used in D 
here.  Sure, I get that having a fairly consistent programming 
interface may make using the language easier for certain 
programmers, but if you're using D with Windows, then you will be 
made well aware of the incompatibilities between D's strings and 
the Windows API (unless you always use ASCII I suppose).


Anyway, I'm curious if proposing changes to those interfaces is 
worthwhile, or if I should just modify it for my own purposes and 
leave the standard library be.


P.S. Its a shame to keep running into Unicode issues with D and 
Windows, and sometimes its a bit discouraging. Right before I 
peeked into DirEntry, I worked a bit on a workaround for 
stdio.File's unicode problems (a documented bug thats 2+ years 
old). I remember trying D a while back and giving up because 
optlink was choking on paths. And just yesterday it choked on 
what the %PATH% environment variable was set to, so I had to 
clear that before running it.

Re: Dynamically Loading a D DLL From a C Program in Linux

[John McFarlane via Digitalmars-d-learn]

Apologies. That should be Ubuntu 14.04.

On Friday, 24 October 2014 at 20:59:20 UTC, John McFarlane wrote:
I'm following the preliminary example "Dynamically Loading a D 
DLL From a C Program" here: http://dlang.org/dll-linux.html#dso9


Firstly, my output is different:

+main()
libdll.so is loaded
dll() function is found
dll()
unloading libdll.so
-main()

If looks like static this and ~this are not being called.

Secondly, when I replace printf with writeln, I get a seg 
fault. Trying to do just about anything beyond adding numbers 
and returning the result causes a similar crash.


I'm wondering whether D runtime is being initialized correctly. 
Can anyone suggest what I would do to ensure this? A more 
finalized example would be useful also.


DMD64 D Compiler v2.066.0
Ubuntu 10.04 64bit

Many thanks,
John

Re: new(malloc) locks everything in multithreading

[Kapps via Digitalmars-d-learn]

On Friday, 24 October 2014 at 18:38:39 UTC, tcak wrote:

On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:

On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:

Not sure if this is the same issue, but by default gdb breaks 
on signals that the GC uses, which would explain why it's 
breaking in gdb but not normally.


What happens if you try:
handle SIGUSR1 noprint nostop
handle SIGUSR2 noprint nostop

In GDB before starting execution of the program?


This is what I did on shell: (I put some spaces for readability)

tolga@tolga:~/dev/d/bug$ dmd -gc -debug test.d

tolga@tolga:~/dev/d/bug$ gdb ./test



Yes, GDB is stopping on SIGUSR1 / SIGUSR2 since that's the 
default settings. D's GC uses these signals for suspending / 
resuming threads during a collection. You need to type what I 
said above, prior to typing 'run'.

Dynamically Loading a D DLL From a C Program in Linux

[John McFarlane via Digitalmars-d-learn]

I'm following the preliminary example "Dynamically Loading a D 
DLL From a C Program" here: http://dlang.org/dll-linux.html#dso9


Firstly, my output is different:

+main()
libdll.so is loaded
dll() function is found
dll()
unloading libdll.so
-main()

If looks like static this and ~this are not being called.

Secondly, when I replace printf with writeln, I get a seg fault. 
Trying to do just about anything beyond adding numbers and 
returning the result causes a similar crash.


I'm wondering whether D runtime is being initialized correctly. 
Can anyone suggest what I would do to ensure this? A more 
finalized example would be useful also.


DMD64 D Compiler v2.066.0
Ubuntu 10.04 64bit

Many thanks,
John

Re: Vibe.d compiler errors...

[WhatMeWorry via Digitalmars-d-learn]

On Friday, 24 October 2014 at 19:58:37 UTC, WhatMeWorry wrote:


I just started to dip my toes into vibe.d and I tried to stay 
on the beaten track. I downloaded vibe, and did the "First 
Steps" as recommended:


$ cd /path/to/my/projects
$ dub init  vibe.d

But when I try compiling the default code in app.d which is 
created after the "dub init" above, I get:


N:\VibeMyProject\MyProject\source>dmd app.d -IN:\vibe.d\source  
-IN:\Deimos\openssl-master
N:\Deimos\openssl-master\deimos\openssl\bn.d(907): Error: 
matching '}' expected, not EOF
N:\vibe.d\source\vibe\templ\parsertools.d(12): Error: module 
metastrings is in file 'std\metastrings.d' which cannot be read

import path[0] = N:\vibe.d\source
import path[1] = N:\Deimos\openssl-master
import path[2] = N:\D\dmd2\windows\bin\..\..\src\phobos
import path[3] = N:\D\dmd2\windows\bin\..\..\src\druntime\import

Isn't the first a syntax error and the second one I read that 
metastrings was Deprecated and it would be removed in March 
2014.


I realize that vibe is a volunteer project, but the whole 
project seems so elegant and professional, I was expecting at 
least a successful compile.


I guess I'm really asking is before I go tweaking code, I want 
to make sure I haven't done anything bone-headed here?


thanks.


Oops.  Just realized that there is a Vibe discussion group I 
should have posted to.

Sorry.

Vibe.d compiler errors...

[WhatMeWorry via Digitalmars-d-learn]

I just started to dip my toes into vibe.d and I tried to stay on 
the beaten track. I downloaded vibe, and did the "First Steps" as 
recommended:


$ cd /path/to/my/projects
$ dub init  vibe.d

But when I try compiling the default code in app.d which is 
created after the "dub init" above, I get:


N:\VibeMyProject\MyProject\source>dmd app.d -IN:\vibe.d\source  
-IN:\Deimos\openssl-master
N:\Deimos\openssl-master\deimos\openssl\bn.d(907): Error: 
matching '}' expected, not EOF
N:\vibe.d\source\vibe\templ\parsertools.d(12): Error: module 
metastrings is in file 'std\metastrings.d' which cannot be read

import path[0] = N:\vibe.d\source
import path[1] = N:\Deimos\openssl-master
import path[2] = N:\D\dmd2\windows\bin\..\..\src\phobos
import path[3] = N:\D\dmd2\windows\bin\..\..\src\druntime\import

Isn't the first a syntax error and the second one I read that 
metastrings was Deprecated and it would be removed in March 2014.


I realize that vibe is a volunteer project, but the whole project 
seems so elegant and professional, I was expecting at least a 
successful compile.


I guess I'm really asking is before I go tweaking code, I want to 
make sure I haven't done anything bone-headed here?


thanks.

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 16:51:02 UTC, Kapps wrote:

On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:

Not sure if this is the same issue, but by default gdb breaks 
on signals that the GC uses, which would explain why it's 
breaking in gdb but not normally.


What happens if you try:
handle SIGUSR1 noprint nostop
handle SIGUSR2 noprint nostop

In GDB before starting execution of the program?


This is what I did on shell: (I put some spaces for readability)

tolga@tolga:~/dev/d/bug$ dmd -gc -debug test.d

tolga@tolga:~/dev/d/bug$ gdb ./test

GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.

(gdb) run

Starting program: /home/tolga/dev/d/bug/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

[New Thread 0x775ed700 (LWP 4940)]

Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0x775ed700 (LWP 4940)]
__lll_lock_wait_private () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95	../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such 
file or directory.


(gdb) backtrace full

#0  __lll_lock_wait_private () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95

No locals.
#1  0x77bc52f1 in _L_lock_3358 () from 
/lib/x86_64-linux-gnu/libpthread.so.0

No symbol table info available.
#2  0x77bc4382 in start_thread (arg=0x775ed700) at 
pthread_create.c:301

oldtype = 0
pd = 0x775ed700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = 
{140737343575808, 9112392114346628883, 1, 0,
140737343576512, 140737343575808, 
-9112375355952097517, -9112375093712283885},
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
0x0}, data = {prev = 0x0,

  cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#3  0x776e8fbd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

No locals.

(gdb)

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 12:38:48 UTC, Kagamin wrote:

On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png


Hmm... where is __lll_lock_wait_private now? And how mmap can 
hang at all?


Here it is.
http://i.imgur.com/5ZDuYRF.png

I didn't notice mmap before you said it, but it seems like that 
happened as well.

Re: Patterns for functions in template parameters

[via Digitalmars-d-learn]

On Friday, 24 October 2014 at 16:12:48 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Fri, 24 Oct 2014 16:00:41 +
via Digitalmars-d-learn  
wrote:


On Friday, 24 October 2014 at 14:06:08 UTC, ketmar via 
Digitalmars-d-learn wrote:

> On Thu, 23 Oct 2014 18:28:04 +
> Max Samukha via Digitalmars-d-learn 
> 

> wrote:
>
> um-hm... maybe this:
>
>   void Foo(T, U) (T delegate (U) a) {
> // here T is bool, U is int for the following sample
> import std.stdio;
> writeln(a(3));
>   }
>
>   Foo((int x) => x%2 == 0);

I thought the same thing, but it doesn't compile with DMD from 
Git:
Foo is a function, not declaration. put in in main(), for 
example:


  void main () { Foo((int x) => x%2 == 0); }


Now I'm feeling really stupid :-P

Re: Basic DerelictOrg and Deimos question

[Justin Whear via Digitalmars-d-learn]

On Fri, 24 Oct 2014 18:04:13 +, WhatMeWorry wrote:
 
> Just for clarity's sake, should I consider the DerelictOrg and Deimos
> (packages, projects, or libraries) as separate from one another?  Or
> does DerelictOrg use Deimos behind the scenes?

They are quite different.  The Deimos packages are static bindings to the 
C
libraries--requiring you to statically link.  This, incidentally is why 
there
is no Deimos binding for OpenGL: it cannot be statically linked (unless 
you go
with a software implementation like MESA) because libGL is provided by the
end user's video hardware drivers.

If you're writing games or similar that you want to distribute, 
definitely go
with the dynamic bindings that Derelict provides.  It allows the end-user 
to use
whatever version they already have installed.

Basic DerelictOrg and Deimos question

[WhatMeWorry via Digitalmars-d-learn]

within DerelictOrg, I've used DerelictGL3 and DerelictGLFW3 
packages successfully. But just today I stumbled across 
D-Programming-Deimos and noticed that it has a glfw and an OpenGL 
as well.


I've read some of the descriptions and Derelict talks about 
"dynamic bindings" where Deimos mentions "D interfaces".


Just for clarity's sake, should I consider the DerelictOrg and 
Deimos (packages, projects, or libraries) as separate from one 
another?  Or does DerelictOrg use Deimos behind the scenes?

Re: Patterns for functions in template parameters

[Max Samukha via Digitalmars-d-learn]

On Friday, 24 October 2014 at 17:08:00 UTC, Max Samukha wrote:

Apparently, D doesn't allow type variables in value parameters 
at all.


Nor does it allow passing delegates to value parameters, only 
alias parameters.

Re: Patterns for functions in template parameters

[Max Samukha via Digitalmars-d-learn]

On Friday, 24 October 2014 at 14:13:10 UTC, ketmar via 
Digitalmars-d-learn wrote:


sorry if this is not what you mean, template magic sometimes 
scares me

and i'm loosing my mind. ;-)


What I meant was your example with the delegate parameter moved 
to the template list:


template Foo(T delegate(U) a, T, U) {}
Foo!((int x) => true); // T == bool, U == int


Or generalized to functions (and maybe "functors" in the 
unfortunate C++ sense):


template Foo(T(U) a, T, U) {}


Apparently, D doesn't allow type variables in value parameters at 
all.

Re: new(malloc) locks everything in multithreading

[Kapps via Digitalmars-d-learn]

On Friday, 24 October 2014 at 10:49:42 UTC, tcak wrote:

On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:

On Friday, 24 October 2014 at 10:29:10 UTC, Kagamin wrote:
Looks like your IDE filters too much. Can you configure it to 
filter less and show address locations?


This is what I have found:

Main Thread
http://i.imgur.com/6ElZ3Fm.png

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png


BTW, instead of using Monodevelop with Mono-D, I used same code 
on a text
file, and compiled with "dmd test.d", then run with "./test", 
then everything
works fine. When I run it with "gdb ./test", then I can see 
those errors again.


Not sure if this is the same issue, but by default gdb breaks on 
signals that the GC uses, which would explain why it's breaking 
in gdb but not normally.


What happens if you try:
handle SIGUSR1 noprint nostop
handle SIGUSR2 noprint nostop

In GDB before starting execution of the program?

Re: Patterns for functions in template parameters

[ketmar via Digitalmars-d-learn]

On Fri, 24 Oct 2014 16:00:41 +
via Digitalmars-d-learn  wrote:

> On Friday, 24 October 2014 at 14:06:08 UTC, ketmar via 
> Digitalmars-d-learn wrote:
> > On Thu, 23 Oct 2014 18:28:04 +
> > Max Samukha via Digitalmars-d-learn 
> > 
> > wrote:
> >
> > um-hm... maybe this:
> >
> >   void Foo(T, U) (T delegate (U) a) {
> > // here T is bool, U is int for the following sample
> > import std.stdio;
> > writeln(a(3));
> >   }
> >
> >   Foo((int x) => x%2 == 0);
> 
> I thought the same thing, but it doesn't compile with DMD from 
> Git:
Foo is a function, not declaration. put in in main(), for example:

  void main () { Foo((int x) => x%2 == 0); }


signature.asc
Description: PGP signature

Re: Patterns for functions in template parameters

[via Digitalmars-d-learn]

On Friday, 24 October 2014 at 14:06:08 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Thu, 23 Oct 2014 18:28:04 +
Max Samukha via Digitalmars-d-learn 


wrote:

um-hm... maybe this:

  void Foo(T, U) (T delegate (U) a) {
// here T is bool, U is int for the following sample
import std.stdio;
writeln(a(3));
  }

  Foo((int x) => x%2 == 0);


I thought the same thing, but it doesn't compile with DMD from 
Git:


test.d(7): Error: function declaration without return type. (Note 
that constructors are always named 'this')

test.d(7): Error: found '=>' when expecting ')'
test.d(7): Error: no identifier for declarator Foo(int x)
test.d(7): Error: semicolon expected following function 
declaration

test.d(7): Error: no identifier for declarator x
test.d(7): Error: Declaration expected, not '%'

Re: Why do some language-defined attributes have @ and some not?

[Gary Willoughby via Digitalmars-d-learn]

On Friday, 24 October 2014 at 15:06:25 UTC, Ola Fosheim Grøstad 
wrote:
I agree that "@"-stuff is trivial, but I don't think Python 
sets a good example. The codebase is basically divided in two, 
libraries have to support both, and I think they should have 
changed more if going to the trouble.


Yes, Python has a real problem with this.

I would like to see a proper deprecation path implemented in D. I 
don't want my code breaking but i'm willing to accept *informed* 
deprecation, followed by removal. Even if this process takes 
place over a few years.

Re: non-const method permitted on rvalue?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/24/14 10:49 AM, Shriramana Sharma via Digitalmars-d-learn wrote:

Hello. I realize the wording "non-const method" is probably a C++-ism
but please see the following code. In both C++ and D, the compilers
are complaining only when I try to assign directly to the member of an
rvalue, but if I try to assign via a non-const ref returned by a
non-const method, then it's apparently fine?!! At least shouldn't D
prohibit this? [Yet another case of rvalue refs being allowed to
escape?]

nonconst.d:
--
struct Pair {
 int x, y ;
 ref Pair handle() { return this ; }
}
void main () {
 Pair(1, 2).x = 5 ;
 Pair(1, 2).handle.x = 5 ;
}
--
nonconst.cpp:
--
struct Pair {
 int x, y ;
 Pair(int x, int y) : x(x), y(y) {}
 Pair & handle() { return *this ; }
} ;
int main () {
 Pair(1, 2).x = 5 ;
 Pair(1, 2).handle().x = 5 ;
}



As a matter of practicality, rvalues are allowed to bind to the 'this' 
parameter of a method. I agree it's a large hole in the current 
philosophy of not letting rvalues bind to references.


Most irritatingly, are things that are typically only values, and don't 
have any references.


For example:

struct S
{
int v;
S opBinary(string op)(ref const(S) s2) const if(op == "+")
{
return S(v + s2.v);
}
}

void main()
{
auto s = S(2);
//  auto s2 = s + S(3); // fails
auto s2 = S(3) + s; // OK
}

-Steve

Re: non-const method permitted on rvalue?

[Ali Çehreli via Digitalmars-d-learn]

On 10/24/2014 07:49 AM, Shriramana Sharma via Digitalmars-d-learn wrote:

> the compilers
> are complaining only when I try to assign directly to the member of an
> rvalue, but if I try to assign via a non-const ref returned by a
> non-const method, then it's apparently fine?!! At least shouldn't D
> prohibit this? [Yet another case of rvalue refs being allowed to
> escape?]
>
> nonconst.d:
> --
> struct Pair {
>  int x, y ;
>  ref Pair handle() { return this ; }
> }
> void main () {
>  Pair(1, 2).x = 5 ;

Just to be clear, the above does not compile and the following does compile.

>  Pair(1, 2).handle.x = 5 ;
> }

Without flow analysis, it is impossible for the compiler to see that 
what handle() returns is an rvalue. Assuming that 'that' is an lvalue, 
the following should not be disallowed:


ref Pair handle() {
return isSomeCondition() ? this : that ;
}

Ali

Re: Why do some language-defined attributes have @ and some not?

[via Digitalmars-d-learn]

On Friday, 24 October 2014 at 14:23:04 UTC, Shriramana Sharma via 
Digitalmars-d-learn wrote:
As for the cases when serious changes to the grammar are 
needed, I
feel the Py2 to Py3 transition is a good example to emulate. 
Lots of
cleanup happened in Py3, Py2 is still supported, and there 
exists
tools like 2to3 and six (https://pypi.python.org/pypi/six) to 
help

people bridge the gap.


I agree that "@"-stuff is trivial, but I don't think Python sets 
a good example. The codebase is basically divided in two, 
libraries have to support both, and I think they should have 
changed more if going to the trouble.


In essence you should either change so little that upgrading is 
trivial or you should improve the language enough to ensure that 
all new projects choose the improved language.


However, Python is in widespread use on a fairly massive scale 
and is dynamic, which makes breaking very serious as it happens 
at runtime.


D could with little trouble undergo a massive change where the 
static type system catch the issues and call it D3.


The real problem is that there is no design for a D3 rooted in a 
semantic model that is clean. Such a transition would require a 
solid formal specification where you eliminate all weird aspects.


But I don't think anyone is working on a new spec? I am willing 
to help out if other people are interested.

non-const method permitted on rvalue?

[Shriramana Sharma via Digitalmars-d-learn]

Hello. I realize the wording "non-const method" is probably a C++-ism
but please see the following code. In both C++ and D, the compilers
are complaining only when I try to assign directly to the member of an
rvalue, but if I try to assign via a non-const ref returned by a
non-const method, then it's apparently fine?!! At least shouldn't D
prohibit this? [Yet another case of rvalue refs being allowed to
escape?]

nonconst.d:
--
struct Pair {
int x, y ;
ref Pair handle() { return this ; }
}
void main () {
Pair(1, 2).x = 5 ;
Pair(1, 2).handle.x = 5 ;
}
--
nonconst.cpp:
--
struct Pair {
int x, y ;
Pair(int x, int y) : x(x), y(y) {}
Pair & handle() { return *this ; }
} ;
int main () {
Pair(1, 2).x = 5 ;
Pair(1, 2).handle().x = 5 ;
}

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Why do some language-defined attributes have @ and some not?

[Shriramana Sharma via Digitalmars-d-learn]

Hi people and thanks for weighing in. It's nice to note that there's
already a DIP on this. I hope it's refined and implemented in a future
version in a meaningful manner. Is it OK to edit the wiki to add one's
opinions?

And in this case, personally I'm not sure why people are talking about
code *breakage*, which is a big word IMO. It's after all removing or
adding @ in a few cases. It's relatively straightforward a fix to
automate. If there can be a dfix to relocate the const from before to
after the function name, then this should be much easier, no? It
wouldn't even need a D3, but could be done in a future D2 point
release. And as someone else said, there's a difference between
outright breakage and planned deprecation.

As for the cases when serious changes to the grammar are needed, I
feel the Py2 to Py3 transition is a good example to emulate. Lots of
cleanup happened in Py3, Py2 is still supported, and there exists
tools like 2to3 and six (https://pypi.python.org/pypi/six) to help
people bridge the gap.

Finally in general I'd also like to suggest that rather than saying
something like "you won't be able to convince Walter of this because
it's not important", which IMHO tends to somewhat put off newbies who
are excited by the language and want to contribute, and tends to put
the project masters in an autocratic light (which people won't like to
hear), one might consider saying something like "D 2 is now aiming for
stability so we are trying to minimize the number of grammar changes".

Thanks again, all!

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Patterns for functions in template parameters

[ketmar via Digitalmars-d-learn]

On Fri, 24 Oct 2014 17:05:57 +0300
ketmar via Digitalmars-d-learn 
wrote:

> On Thu, 23 Oct 2014 18:28:04 +
> Max Samukha via Digitalmars-d-learn
>  wrote:
> 
> um-hm... maybe this:
> 
>   void Foo(T, U) (T delegate (U) a) {
> // here T is bool, U is int for the following sample
> import std.stdio;
> writeln(a(3));
>   }
> 
>   Foo((int x) => x%2 == 0);
sorry if this is not what you mean, template magic sometimes scares me
and i'm loosing my mind. ;-)


signature.asc
Description: PGP signature

Re: Patterns for functions in template parameters

[ketmar via Digitalmars-d-learn]

On Thu, 23 Oct 2014 18:28:04 +
Max Samukha via Digitalmars-d-learn 
wrote:

um-hm... maybe this:

  void Foo(T, U) (T delegate (U) a) {
// here T is bool, U is int for the following sample
import std.stdio;
writeln(a(3));
  }

  Foo((int x) => x%2 == 0);


signature.asc
Description: PGP signature

Re: Patterns for functions in template parameters

[Max Samukha via Digitalmars-d-learn]

On Friday, 24 October 2014 at 08:53:05 UTC, Kagamin wrote:

maybe
template Foo(T a, T: T[U], U)


No luck. Error: undefined identifier T

Re: Constructor params with same name as members

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/23/14 3:22 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " 
wrote:

On Thursday, 23 October 2014 at 18:57:33 UTC, Ali Çehreli wrote:

On 10/22/2014 11:37 PM, Jonathan M Davis wrote:

> x = x;
>
> which is so obviously wrong that I don't know how much of
anyone could
> make that mistake. But simply making it illegal to assign a
variable to
> itself would solve that problem, and that arguably should be
done, since
> it's a essentially a no-op.

Steve said the same thing and it's true for fundamental types but just
to annoy you two, assignment can have side effects. :)


But it wouldn't be a no-op then.


Was about to say the same thing :)

I think the compiler might be able to tell the difference between x = x; 
when x is an int and x is a struct with opAssign.


-Steve

Re: Bug?

[deed via Digitalmars-d-learn]

OK, I tried with OSX 64-bit compiler. Perhaps 32 bit would not 
fare as well. What platform are you testing on?


Have tried Linux and Windows 64-bit and it seems to be an issue 
when compiled with -m32. Tests are provided here 
http://dpaste.dzfl.pl/5f55f4152aa8.


I agree that one cannot compare double and real and expect 
equality, so the ones marked with [1] are not incorrect 
behaviour, while [2] and [4] seem to be bugs.

Re: Bug?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/23/14 2:46 PM, deed wrote:

On Thursday, 23 October 2014 at 18:26:53 UTC, Steven Schveighoffer wrote:

On 10/23/14 2:18 PM, deed wrote:

Using equality is not a good idea with floating point.

The compiler will on a whim, or depending on whether it can inline or
not, use higher precision floats, changing the outcome slightly.

I cannot say for certain whether this explains all the issues you
have, the very last one seems troubling to me at least.



Sure, in many cases it's a bad idea. While I understand that sin(PI) !=
0.0, but approxEqual(sin(PI), 0.0) == true, I would expect the following
to pass:

assert (0.0 == 0.0);
assert (1.2345 == 1.2345);
F a = 1.2345, b = 9.8765;

assert (a+b == b+a);
assert (a*b == b*a);


None of these fail on my system


Same for me, that's the point; it's perfectly valid to compare floating
points.


OK. I think to be frank, your explanation by example needs to be 
accompanied with what the result is (you do this below, thanks). From 
the above, it sounds like they did not pass, but you expected them to.


As to your assertion that it's perfectly valid to compare floating 
points, I think examples where they compare equal do not prove all 
equivalent floating point calculations should compare equal.


Is it valid? Yes. Is it wise? No.


F fun (F a) pure;

assert (fun(a) + fun(b) == fun(b) + fun(a));
assert (fun(a) * fun(b) == fun(b) * fun(a));

auto a = fun(100);
auto b = fun(100);

assert (a == b);
assert (fun(100) == fun(100));



Not sure what body of fun is, so I cannot test this.


Could be anything taking a floating point and returning a floating point.
You would expect to get the same back for the same input, especially when
it's pure. If so, the asserts above are expected to hold.


OK, I get that. I agree, it should be equal.


Now, if fun's body is { return sin(a); }, the behaviour changes to:

auto c = fun(100);
auto d = fun(100);

assert (c == d);  // Ok
assert (fun(100) != fun(100)) // I have a hard time understanding
  // this is correct behaviour


Tried that out, it does not fail on my machine. Can you be more
specific on your testing? What compiler/platform? Stock compiler, or
did you build it yourself?


Right. It doesn't fail, and that's the problem.


Sorry, I said this wrong. I tried out fun(100) == fun(100) and the 
assert passed.




assert (fun(100) == fun(100));  // Should pass, and does with
 // body { return a + 1; }
 // but not with
 // body { return sin(a); }


Does not fail for me for sin(a) case.


Compiler: DMD32 D Compiler v2.066.0


OK, I tried with OSX 64-bit compiler. Perhaps 32 bit would not fare as 
well. What platform are you testing on?


-Steve

Re: new(malloc) locks everything in multithreading

[Kagamin via Digitalmars-d-learn]

On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png


Hmm... where is __lll_lock_wait_private now? And how mmap can 
hang at all?

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 10:29:10 UTC, Kagamin wrote:
Looks like your IDE filters too much. Can you configure it to 
filter less and show address locations?


This is what I have found:

Main Thread
http://i.imgur.com/6ElZ3Fm.png

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 10:46:57 UTC, tcak wrote:

On Friday, 24 October 2014 at 10:29:10 UTC, Kagamin wrote:
Looks like your IDE filters too much. Can you configure it to 
filter less and show address locations?


This is what I have found:

Main Thread
http://i.imgur.com/6ElZ3Fm.png

Second Thread (TestThread)
http://i.imgur.com/w4y5gYB.png


BTW, instead of using Monodevelop with Mono-D, I used same code 
on a text
file, and compiled with "dmd test.d", then run with "./test", 
then everything
works fine. When I run it with "gdb ./test", then I can see those 
errors again.

Re: new(malloc) locks everything in multithreading

[Kagamin via Digitalmars-d-learn]

Looks like your IDE filters too much. Can you configure it to 
filter less and show address locations?

Re: Why do some language-defined attributes have @ and some not?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, October 24, 2014 08:19:48 Paolo Invernizzi via Digitalmars-d-learn 
wrote:
> On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:
> > There are people out there using D who do not participate in
> > the newsgroups. Walter has told us before that he gets emails
> > from companies using D in production. He has to deal with
> > complaints about code breakage that we aren't going to see here
> > in the NG. Just keep in mind that no matter how many of us here
> > agree on a breaking change, we are not the entirety of the D
> > user base. And it has nothing to do with Reddit.
>
> I think that Walter talked about emails complaining about "silent
> breakage" or "regressions", and that's a totally different matter.
>
> To be honest, I only remember that he talked about one single
> case, but maybe I'm wrong.
> And I don't remember any complain about code deprecations.

Walter doesn't seem to understand that unintended breakage and planned,
communicated breakage via a proper deprecation process are two totally
different issues. He's definitely had folks complain about regressions, and
the response to that has sometimes been that changes that we were considering
got axed, because he'd just had someone complain about (unintended) code
breakage, and for him, that meant that pretty much _anything_ which would
eventually result in code breakage was bad and therefore raised the bar on
changes that much more (IIRC, that happened just after the virtual keyword had
been introduced, and the result was that it was removed, and the plans to
switch to final by default were axed).

So no, I don't think that folks have complained to him about deprecations
(though they could have, and he just never said anything about it), but they
have complained often enough about other stuff, and he doesn't seem to
distinguish between planned breakage and unintentional breakage in the same
way that many of the rest of us do.

- Jonathan M Davis

Re: Parsing a date string into a std.datetime.datetime

[Colin via Digitalmars-d-learn]

On Thursday, 23 October 2014 at 21:17:23 UTC, Jonathan M Davis 
wrote:

On Thursday, 23 October 2014 at 11:13:26 UTC, Colin wrote:

Hi,

I'm looking for an easy way to parse a dates into a datetime 
object.


Most of my dates will be of the form:
mmm dd,  HH:MM AM|PM

So like: "May 30, 2014 12:12 PM"

I can easily write a regex or whatever to pull these out of 
that one format, but it's not guaranteed they'll all be in the 
one format and I may have to deal with others.


Is there a helper function that I'm missing that can parse 
these dates? Maybe something similar to pythons 
dateutil.parser [1] ?


If not maybe adding this function to std.datetime would be a 
good project to undertake for myself...


[1] - https://labix.org/python-dateutil


std.datetime supports the ISO formats but, it does not 
currently support generating or parsing custom strings for 
dates or times. It's on my todo list (probably after splitting 
std.datetime into a package), but I don't know exactly when I'm 
going to get to it. The first step will be figuring out what 
the format strings will look like, since what languages like C 
do is a complete mess. I had a proposal on it that was 
discussed a while ago, but it was too complicated. It'll 
probably end up being something closer to this 
http://pr.stewartsplace.org.uk/d/sutil/datetime_format.html 
though I'm afraid that that approach as it's presented might 
not be flexible enough. I'll probably need to do something like 
add a templated function that returns a custom struct with the 
values that you want so that you can get them effeiently to 
build the string yourself in the cases where you need to do 
something wacky enough that the normal custom string formatting 
functions aren't flexible enough. Then leaving the normal 
custom string format generating and parsing functions simpler 
works better.


In any case, I intend to get to it, but I've been dreadfully 
slow about it. It's the number one thing missing from 
std.datetime. I'd prefer to do it myself, but there's certainly 
no reason why someone else can't do it if they really want to.


- Jonathan M Davis


Ok, thanks for the informative reply Jonathan.

For now I'll go with parsing the few types of dates I may need, 
and maybe port over in the future when you get to it.


Cheers!

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 09:12:57 UTC, tcak wrote:

On Friday, 24 October 2014 at 08:55:17 UTC, Kagamin wrote:

Do you see recursive call to malloc in the stack trace?


I further simplified the example:

import std.stdio;
import core.thread;

class ThreadTest{
public this(){
new core.thread.Thread( &threadRun ).start();
}

private void threadRun(){
writeln("It works");
readln();
}
}


void main(){
new ThreadTest();
char[] abc = new char[4096];
}


This is what I see on screen:
http://imgur.com/Pv9Rulw

Same result.


And this is the thread of malloc.
http://imgur.com/e8ofRte

It suspends all threads and cannot get out of there it seems like.

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 08:55:17 UTC, Kagamin wrote:

Do you see recursive call to malloc in the stack trace?


I further simplified the example:

import std.stdio;
import core.thread;

class ThreadTest{
public this(){
new core.thread.Thread( &threadRun ).start();
}

private void threadRun(){
writeln("It works");
readln();
}
}


void main(){
new ThreadTest();
char[] abc = new char[4096];
}


This is what I see on screen:
http://imgur.com/Pv9Rulw

Same result.

Re: new(malloc) locks everything in multithreading

[Kagamin via Digitalmars-d-learn]

Do you see recursive call to malloc in the stack trace?

Re: Patterns for functions in template parameters

[Kagamin via Digitalmars-d-learn]

maybe
template Foo(T a, T: T[U], U)

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 08:47:55 UTC, Kagamin wrote:
If it's deterministic, looks more like 
https://issues.dlang.org/show_bug.cgi?id=4890

(11981 is not deterministic)


Yes, it is deterministic. Run it as many times as you
want, and it does the same thing. I ran it now again, and
still same.

Re: new(malloc) locks everything in multithreading

[Kagamin via Digitalmars-d-learn]

If it's deterministic, looks more like 
https://issues.dlang.org/show_bug.cgi?id=4890

(11981 is not deterministic)

Re: Why do some language-defined attributes have @ and some not?

[Paolo Invernizzi via Digitalmars-d-learn]

On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:


There are people out there using D who do not participate in 
the newsgroups. Walter has told us before that he gets emails 
from companies using D in production. He has to deal with 
complaints about code breakage that we aren't going to see here 
in the NG. Just keep in mind that no matter how many of us here 
agree on a breaking change, we are not the entirety of the D 
user base. And it has nothing to do with Reddit.


I think that Walter talked about emails complaining about "silent 
breakage" or "regressions", and that's a totally different matter.


To be honest, I only remember that he talked about one single 
case, but maybe I'm wrong.

And I don't remember any complain about code deprecations.
---
/Paolo

Re: Bug?

[deed via Digitalmars-d-learn]

On Thursday, 23 October 2014 at 21:42:46 UTC, anonymous wrote:

On Thursday, 23 October 2014 at 21:17:25 UTC, deed wrote:

Some testing can be found on http://dpaste.dzfl.pl/5f55f4152aa8
for both Windows and Linux. This just illustrates the sin 
function.


I think the tests marked "[1]" are expected to fail. They 
involve

converting one operand of the comparison to double, but not the
other. The comparison is done using real precision. So, one
operand goes through a real->double->real conversion, which
changes the value.


You're right about those marked [1]; sin returns real and 
shouldn't be expected to equal the same value truncated to double 
or float and then extended back to real.


Converting the sin to double and compare is expected to work for 
those, and it does when compiled with -m64, but not with -m32, on 
Linux:


--
import std.math : sin;
import std.conv : to;
double fun (double a) { return sin(a); }

immutable double a = 3.
assert (fun(a) == sin(a).to!double);  // Works when compiled with 
-m64

--

The behaviour of those only marked [2] and [4] (the 32-bit 
versions) seems to be a bug.

Re: new(malloc) locks everything in multithreading

[tcak via Digitalmars-d-learn]

On Friday, 24 October 2014 at 03:42:29 UTC, safety0ff wrote:

On Friday, 24 October 2014 at 02:51:20 UTC, tcak wrote:


I don't want to blame dmd directly because as far as I see 
from the search I did with "__lll_lock_wait_private", some C++ 
programs are having same problem with malloc operation as 
well. But still, can this be because of compiler?


Looks like bug #11981 [1], which should be fixed in the latest 
versions of the compiler. Which version are you using?


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


I am on DMD 2.066 64-bit
Linux 3.13.0-37-generic