Re: enums extension

[Robert DaSilva]

On Wednesday, 16 May 2012 at 05:49:01 UTC, Mehrdad wrote:

On Wednesday, 16 May 2012 at 04:22:18 UTC, Comrad wrote:

Dear developers and community,
I want to draw you attention to the topic which was already 
discussed here:

http://forum.dlang.org/thread/9to6n8$12d6$1...@digitaldaemon.com
and here:
http://forum.dlang.org/thread/bl1n0e$1km5$1...@digitaldaemon.com

My question is: was something similar already done? are there 
some plans to do that?


Dunno... but the way I'd use them would be more like:

enum AccessMask
{
GENERIC_READ = 0x8000,
GENERIC_WRITE = 0x4000,
GENERIC_EXECUTE = 0x2000,
GENERIC_ALL = 0x1000,
//
}

enum FileAccessMask : AccessMask
{
FILE_READ_DATA = 0x0001,
//...
}


The inheritances notation implies that it's a subset and can be 
assigned to an instances of the base. This would not be true with 
enums.


FileAccessMask foo = FileAccessMask.FILE_READ_DATA;
AccessMask bar = foo; // Error

Re: scope(exit) without exception handling?

[Jonathan M Davis]

On Wednesday, May 16, 2012 07:30:44 Mehrdad wrote:
> Well, RAII is pretty much just a finally block...
> It seems like all of these emit references _d_local_unwind2 and
> stuff, so it seems like it's not the way you expect...

It all depends on how it's implemented I guess. RAII doesn't directly have 
anything to do with exceptions (though it's a good way to write exception-safe 
code), so it would be perfectly possible to have it in a language with no 
exceptions at all, but I guess that it could be implemented in a manner 
similar to finally blocks, much as I wouldn't have expected it. I haven't 
looked at what exactly the compiler generates though, so if you've dug into 
that, you know more about it than I do.

- Jonathan M Davis

Re: scope(exit) without exception handling?

[Jonathan M Davis]

On Tuesday, May 15, 2012 22:38:58 Brad Roberts wrote:
> On 5/15/2012 10:06 PM, Jonathan M Davis wrote:
> > On Wednesday, May 16, 2012 05:54:04 Mehrdad wrote:
> >> I'm writing some (low-level) code with no exception handling
> >> available whatsoever... either the code runs, or it doesn't.
> >> 
> >> Is there any way for me to use scope(exit) (or perhaps a
> >> destructor, like RAII) to mean, "Execute this block of code for
> >> me when the block is exited, will ya?", *without* introducing
> >> dependencies on exception handling?
> > 
> > scope(exit) stuff;
> > otherStuff;
> > 
> > is lowered to something like
> > 
> > try
> > {
> > 
> > otherStuff;
> > 
> > }
> > finally
> > {
> > 
> > stuff;
> > 
> > }
> > 
> > So, you can use scope(exit) if the above code is acceptable for whatever
> > you're doing. Otherwise, no, you can't.
> > 
> > Destructors should work regardless of what you're doing with exceptions
> > though, so I would expect RAII to work.
> > 
> > - Jonathan M Davis
> 
> And if otherStuff is marked all nothrow, then the exception parts are pulled
> out.  It's pretty much the entire point of having nothrow annotations.

Cool.

- Jonathan M Davis

Re: scope(exit) without exception handling?

[Robert DaSilva]

On Wednesday, 16 May 2012 at 05:46:03 UTC, Mehrdad wrote:=
Oooh, *that* I did not know. Very interesting, thanks for 
pointing that out!


You could try scope(success), but the nothrow annotations sound 
like a better idea

Re: enums extension

[Simen Kjaeraas]

On Wed, 16 May 2012 06:22:15 +0200, Comrad  
 wrote:



Dear developers and community,
I want to draw you attention to the topic which was already discussed  
here:

http://forum.dlang.org/thread/9to6n8$12d6$1...@digitaldaemon.com
and here:
http://forum.dlang.org/thread/bl1n0e$1km5$1...@digitaldaemon.com

My question is: was something similar already done? are there some plans  
to do that?


I have implemented this functionality in user code, with some caveats:

module enumMagic;

string EnumDefAsString(T)()
if (is(T == enum))
{
string result = "";
foreach (e; __traits(allMembers, T)) {
result ~= e ~ " = T." ~ e ~ ",";
}
return result;
}

template ExtendEnum(T, string s)
if (is(T == enum) &&
is(typeof({mixin("enum a{"~s~"}");})))
{
mixin(
"enum ExtendEnum {"
~ EnumDefAsString!T()
~ s
~ "}");
}

unittest {
enum Foo {
a,
b,
c
}
alias ExtendEnum!( Foo, q{
d,
e
}) Bar;

Bar b;
b = Bar.a; // Look ma, I stole this from Foo!
b = Bar.d;
assert( Bar.a == Foo.a ); // Can compare the two.
//b = Foo.a; // But cannot assign from one to the other.
}

void main( ) {
}

A library implementation with the missing features is possible, but would  
use a

struct instead of an enum, an be a rather larger piece of code than this.

Re: scope(exit) without exception handling?

[Mehrdad]

On Wednesday, 16 May 2012 at 05:39:08 UTC, Brad Roberts wrote:

On 5/15/2012 10:06 PM, Jonathan M Davis wrote:

On Wednesday, May 16, 2012 05:54:04 Mehrdad wrote:

I'm writing some (low-level) code with no exception handling
available whatsoever... either the code runs, or it doesn't.

Is there any way for me to use scope(exit) (or perhaps a
destructor, like RAII) to mean, "Execute this block of code 
for

me when the block is exited, will ya?", *without* introducing
dependencies on exception handling?


scope(exit) stuff;
otherStuff;

is lowered to something like

try
{
otherStuff;
}
finally
{
stuff;
}

So, you can use scope(exit) if the above code is acceptable 
for whatever you're doing. Otherwise, no, you can't.


Destructors should work regardless of what you're doing with 
exceptions though, so I would expect RAII to work.


- Jonathan M Davis


And if otherStuff is marked all nothrow, then the exception 
parts are pulled out.  It's pretty much the entire point of

having nothrow annotations.


Oooh, *that* I did not know. Very interesting, thanks for 
pointing that out!

Re: scope(exit) without exception handling?

[Brad Roberts]

On 5/15/2012 10:06 PM, Jonathan M Davis wrote:
> On Wednesday, May 16, 2012 05:54:04 Mehrdad wrote:
>> I'm writing some (low-level) code with no exception handling
>> available whatsoever... either the code runs, or it doesn't.
>>
>> Is there any way for me to use scope(exit) (or perhaps a
>> destructor, like RAII) to mean, "Execute this block of code for
>> me when the block is exited, will ya?", *without* introducing
>> dependencies on exception handling?
> 
> scope(exit) stuff;
> otherStuff;
> 
> is lowered to something like
> 
> try
> {
> otherStuff;
> }
> finally
> {
> stuff;
> }
> 
> So, you can use scope(exit) if the above code is acceptable for whatever 
> you're doing. Otherwise, no, you can't.
> 
> Destructors should work regardless of what you're doing with exceptions 
> though, so I would expect RAII to work.
> 
> - Jonathan M Davis

And if otherStuff is marked all nothrow, then the exception parts are pulled 
out.  It's pretty much the entire point of
having nothrow annotations.

Re: scope(exit) without exception handling?

[Mehrdad]

On Wednesday, 16 May 2012 at 05:06:51 UTC, Jonathan M Davis wrote:


scope(exit) stuff;
otherStuff;

is lowered to something like

try
{
otherStuff;
}
finally
{
stuff;
}

So, you can use scope(exit) if the above code is acceptable for 
whatever you're doing. Otherwise, no, you can't.


Thanks, though I already knew that...


Destructors should work regardless of what you're doing with 
exceptions though, so I would expect RAII to work.



Well, RAII is pretty much just a finally block...
It seems like all of these emit references _d_local_unwind2 and 
stuff, so it seems like it's not the way you expect...

Re: scope(exit) without exception handling?

[Jonathan M Davis]

On Wednesday, May 16, 2012 05:54:04 Mehrdad wrote:
> I'm writing some (low-level) code with no exception handling
> available whatsoever... either the code runs, or it doesn't.
> 
> Is there any way for me to use scope(exit) (or perhaps a
> destructor, like RAII) to mean, "Execute this block of code for
> me when the block is exited, will ya?", *without* introducing
> dependencies on exception handling?

scope(exit) stuff;
otherStuff;

is lowered to something like

try
{
otherStuff;
}
finally
{
stuff;
}

So, you can use scope(exit) if the above code is acceptable for whatever 
you're doing. Otherwise, no, you can't.

Destructors should work regardless of what you're doing with exceptions 
though, so I would expect RAII to work.

- Jonathan M Davis

Re: MBCS character code support

[Alex Rønne Petersen]

On 16-05-2012 06:18, Katayama Hirofumi MZ wrote:

On Wednesday, 16 May 2012 at 04:12:04 UTC, Alex Rønne Petersen wrote:

I really do not understand why you want to use Shift-JIS. Unicode has
long superseded all these magical encodings used all over the world.
Why oppose a unified encoding?


On Windows 9x, there is no Unicode support. Instead, native MBCS
encoding exists.

So, if the D Windows program could use UTF-8 only, then the programmer
should let the D program convert these strings to Shift_JIS.


D does not support Windows versions older than Windows 2000.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: MBCS character code support

[Katayama Hirofumi MZ]

On Wednesday, 16 May 2012 at 04:12:04 UTC, Alex Rønne Petersen 
wrote:
I really do not understand why you want to use Shift-JIS. 
Unicode has long superseded all these magical encodings used 
all over the world. Why oppose a unified encoding?


On Windows 9x, there is no Unicode support. Instead, native MBCS
encoding exists.

So, if the D Windows program could use UTF-8 only, then the 
programmer

should let the D program convert these strings to Shift_JIS.

Re: MBCS character code support

[H. S. Teoh]

On Wed, May 16, 2012 at 06:12:03AM +0200, Alex Rønne Petersen wrote:
> On 16-05-2012 06:04, Katayama Hirofumi MZ wrote:
> >All Japaneses and/or other Asians want native MBCS support.
> >Please let the D compiler generate Shift_JIS code for literal strings.
> 
> I really do not understand why you want to use Shift-JIS. Unicode
> has long superseded all these magical encodings used all over the
> world. Why oppose a unified encoding?
[...]

Unfortunately, Unicode is not yet universally adopted. Many of these
encodings are still widely use for various reasons. While I don't agree
that dmd should support these other encodings, and all D programs should
always use Unicode internally, I do think that we need _some_ way to
convert between encodings, probably in the way of a conversion library.

OTOH, to answer the OP, you could just put the Shift-JIS text in a
separate file, and load them into your D program at runtime as byte[]
data. If you need unusual encodings, you shouldn't be using string
literals in the first place; put them in a l10n file and use an i18n
library to translate from internal string literals to whatever encoding
the user environment requires.


T

-- 
Life would be easier if I had the source code. -- YHL

Re: MBCS character code support

[Alex Rønne Petersen]

On 16-05-2012 06:04, Katayama Hirofumi MZ wrote:

All Japaneses and/or other Asians want native MBCS support.
Please let the D compiler generate Shift_JIS code for literal strings.


I really do not understand why you want to use Shift-JIS. Unicode has 
long superseded all these magical encodings used all over the world. Why 
oppose a unified encoding?


--
- Alex

Re: MBCS character code support

[Katayama Hirofumi MZ]

All Japaneses and/or other Asians want native MBCS support.
Please let the D compiler generate Shift_JIS code for literal 
strings.

scope(exit) without exception handling?

[Mehrdad]

I'm writing some (low-level) code with no exception handling 
available whatsoever... either the code runs, or it doesn't.


Is there any way for me to use scope(exit) (or perhaps a 
destructor, like RAII) to mean, "Execute this block of code for 
me when the block is exited, will ya?", *without* introducing 
dependencies on exception handling?

Re: Windows application manifests

[Mehrdad]

On Tuesday, 15 May 2012 at 14:03:47 UTC, Gor Gyolchanyan wrote:
Can anyone, please, tell me what these manifests are, where do 
they fit in my application binaries, why is one needed to get 
the pretty windows 7 buttons and how to use them with DMD?


Just FYI, you don't actually *need* to include manifests in your 
executable, if you know another DLL already has them.


Here's a hack to show what I mean, for enabling visual styles:

void enableVisualStyles()
{
TCHAR[MAX_PATH] dir;
dir[GetSystemDirectory(dir.ptr, dir.length)] = '\0';
enum
{
ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID = 0x0004,
ACTCTX_FLAG_RESOURCE_NAME_VALID = 0x0008,
ACTCTX_FLAG_SET_PROCESS_DEFAULT = 0x0010,
}
auto actCtx = ACTCTX(ACTCTX.sizeof,
ACTCTX_FLAG_RESOURCE_NAME_VALID |
ACTCTX_FLAG_SET_PROCESS_DEFAULT |
ACTCTX_FLAG_ASSEMBLY_DIRECTORY_VALID,
"shell32.dll", PROCESSOR_ARCHITECTURE_INTEL,
0, dir.ptr, MAKEINTRESOURCE(124), null, null);
auto hActCtx = CreateActCtx(actCtx);
assert(hActCtx != INVALID_HANDLE_VALUE);
ULONG_PTR ulpActivationCookie;
BOOL success = ActivateActCtx(hActCtx, ulpActivationCookie);
assert(success);
}

Basically, since shell32.dll already has our manifest, I can just 
call this function instead. :-)

Re: input completion system

[Katayama Hirofumi MZ]

Thanks, James.

digitalmars-d@puremagic.com

[Mehrdad]

On Tuesday, 15 May 2012 at 21:58:56 UTC, Alex Rønne Petersen 
wrote:

On 15-05-2012 23:27, deadalnix wrote:

Le 15/05/2012 21:33, Mehrdad a écrit :

How do get the address of a function in naked assembly code?

void foo()
{
asm
{
naked;
mov EAX, &foo;
}
}

This doesn't work...


As it is naked,

mov EAX, EIP;

is enough.


I suspect he wanted a solution where he could load an arbitrary 
function's address.


indeed

Re: MBCS character code support

[Katayama Hirofumi MZ]

You can convert UTF-8 to Shift_JIS by the following code.


/* Linux, FreeBSD or UNIX */
#include 
iconv_t g_icUTF8toSJIS;

char *convert_utf8_to_sjis(char *in)
{
char *out, *p_in, *p_out,
size_t in_size, out_size;

in_size = strlen(in);
out_size = in_size;
out = (char *)malloc(out_size + 1);
if (out == NULL)
return NULL;

p_in = in;
p_out = out;
iconv(g_icUTF8toSJIS, &p_in, &in_size, &p_out, &out_size);
*p_out = 0;

return out;
}


int main(void)
{
char *out;
g_icUTF8toSJIS = iconv_open("UTF-8", "SJIS");
if (g_icUTF8toSJIS == (iconv_t)-1) {
// error
}
...
out = convert_utf8_to_sjis(...);
...
free(out);
...

iconv_close(g_icUTF8toSJIS);
return 0;
}

/* Windows */
#include 

char *UTF8toSJIS(char *utf8)
{
char *wide, *sjis;
int size;

size = MultiByteToWideChar(CP_UTF8, 0, utf8, -1, 0, 0);
wide = (char *)malloc((size + 1) * sizeof(WCHAR));
if (wide == NULL)
return NULL;
MultiByteToWideChar(CP_UTF8, 0, utf8, -1, wide, size);

size = WideCharToMultiByte(CP_ACP, 0, wide, -1, 0, 0, 0, 0);
sjis = malloc(size * 2 + 1);
if (sjis == NULL) {
free(wide);
return NULL;
}

WideCharToMultiByte(CP_ACP, 0, wide, -1, sjis, size, 0, 0);
free(wide);

return sjis;
}

int main(void)
{
char *out;
...
out = UTF8toSJIS(...);
...
free(out);
...
return 0;
}

Re: input completion system

[James Miller]

On Wednesday, 16 May 2012 at 02:27:26 UTC, Katayama Hirofumi MZ 
wrote:

Hi, everyone!

Could you make input completion system for D?


Hi Katayama Hirofumi, welcome to the D community.

I notice that your last two posts have a tone of expectation to 
them. Now I'm not saying that you are demanding or even expecting 
people to do things, but asking "Could you make input completion 
system for D?" is not helpful.


D is a programming language, so something like an "input 
completion system" makes no sense. I assume you are talking about 
an IDE, in which case you want to look at Mono-D or Visual D.


Anyway, making these short requests is not considered to be good 
form, since they add little to the community. Ignoring the 
irrelevance of the question, there is no place for discussion, no 
reasoning or explanation, it is a simple yes or no question at 
best, and an expectant demand at worst.


I hope that helps.

--
James Miller

input completion system

[Katayama Hirofumi MZ]

Hi, everyone!

Could you make input completion system for D?

MBCS character code support

[Katayama Hirofumi MZ]

Hello, everyone!

I want multibyte character string (MBCS) support except Unicode, UTF-8 and 
UTF-16.


Could you make the D compiler generate Shift_JIS, EUC-JP code for every 
string literals by a specific command line option?


Shift_JIS and EUC-JP are Japanese character set. 

Re: Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 08:18 PM, Chris Cain wrote:

On Tuesday, 15 May 2012 at 23:36:38 UTC, Chad J wrote:

The idea /was/ to store the @instance variable with the object
specifically to avoid complex indirections. Still have to trust
programmers though :/


But you /can't/ store the @instance variable with the object. As per the
language reference, immutables may be stored in ROM. If the object is
immutable (and const objects might be immutable), then the @instance
variable would be stored in ROM, in which case it physically couldn't
change no matter how hard you tried (or it would vomit run-time errors
or some undefined behavior). The only "workable" solution would be an
immutable pointer to the mutable variable.

Link: http://dlang.org/const3.html



I guess this matters for toHash... so now we not only want 
pure/const/nothrow methods, but there is this implication that we are 
desiring to mutate immutable things.  If we really wanted to overcome 
this, we could have things that behave as if immutable, but carry 
mutable state internally.  These would not be eligible for placement in 
ROM.


The other thing that I'm wondering about is if there are use-cases 
/besides/ hashing.  Are there any?  If not, it might be worth 
special-casing somehow.  It's a difficult route to travel though, 
because it's very difficult to know that there won't be any roadblocks 
besides caching in the future.  Still, I suspect this is not well 
researched.

Re: New Traits

[Nick Sabalausky]

"F i L"  wrote in message 
news:amhbhvoaaxncbyalo...@forum.dlang.org...
>
> This is great! Can't wait to use these in action (codeof mostly), 
> hopefully it'll make it into 2.030.
>

Little too late for that. Maybe for 2.060, though. 

Re: UFCS on forward reference

[John Belmonte]

On Tuesday, 15 May 2012 at 05:02:20 UTC, Timon Gehr wrote:

On 05/15/2012 04:28 AM, John Belmonte wrote:
C API's often use a opaque struct pointer as a handle. Mapping 
such a
struct to D using a forward declaration, I noticed that UFCS 
doesn't work:


struct State;
...
State* s = new_state();
foo(s); // ok
s.foo(); // compile error

Error detail:

Error: struct State is forward referenced when looking for 
'foo'
Error: struct State is forward referenced when looking for 
'opDot'
Error: struct State is forward referenced when looking for 
'opDispatch'


I'm wondering if anything would be harmed by removing this 
restriction.


As a workaround I can use "struct State {}", but that feels 
wrong.




This is a compiler bug. You can report it here: 
http://d.puremagic.com/issues/


Thanks-- filed http://d.puremagic.com/issues/show_bug.cgi?id=8104.

Re: New Traits

[F i L]

On Monday, 14 May 2012 at 23:13:29 UTC, John Maschmeyer wrote:

I implemented some new traits that seemed to have a lot of
interest recently.

I've implemented parameterNames, isPublic, isPrivate,
isProtected, isPackge, isExport, and codeof traits.

parameterNames lets you get access to the names of function
parameters

isPublic, isPrivate, etc let you query access modifiers

codeof was discussed recently in
http://forum.dlang.org/thread/huyqfcoosgzfneswn...@forum.dlang.org.
   It gives you access to the source code of functions, classes,
etc.

I'm pretty new to the dmd code, so could someone take a look at
them?

https://github.com/D-Programming-Language/dmd/pull/951
https://github.com/D-Programming-Language/dmd/pull/952
https://github.com/D-Programming-Language/dmd/pull/953


This is great! Can't wait to use these in action (codeof mostly), 
hopefully it'll make it into 2.030.


:D

Re: Getting the const-correctness of Object sorted once and for all

[Chris Cain]

On Tuesday, 15 May 2012 at 23:36:38 UTC, Chad J wrote:
The idea /was/ to store the @instance variable with the object 
specifically to avoid complex indirections.  Still have to 
trust programmers though :/


But you /can't/ store the @instance variable with the object. As 
per the language reference, immutables may be stored in ROM. If 
the object is immutable (and const objects might be immutable), 
then the @instance variable would be stored in ROM, in which case 
it physically couldn't change no matter how hard you tried (or it 
would vomit run-time errors or some undefined behavior). The only 
"workable" solution would be an immutable pointer to the mutable 
variable.


Link: http://dlang.org/const3.html

Re: deprecating std.stream, std.cstream, std.socketstream

[H. S. Teoh]

On Tue, May 15, 2012 at 04:43:05PM -0700, Sean Kelly wrote:
[...]
> One thing I'd like in a buffered input API is a way to perform
> transactional reads such that if the full read can't be performed, the
> read state remains unchanged. The best you can do with most APIs is to
> check for a desired length, but what I'd I don't want to read until a
> full line is available, and I don't know the exact length?  Typically,
> you end up having to double buffer, which stinks. 

This would be very nice to have, but how would you go about implementing
such a thing, though? Wouldn't you need OS-level support for it?


T

-- 
Let's eat some disquits while we format the biskettes.

Re: Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 06:41 PM, Chris Cain wrote:

On Tuesday, 15 May 2012 at 21:18:11 UTC, Chad J wrote:

On 05/15/2012 03:32 PM, Chris Cain wrote:

On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:

An idea I thought of is to introduce a method local declaration that
allows a method to access instance-specific-state that isn't
accessible to the rest of the class:


This is an interesting idea (as it seems to really try to keep
the state changes internal to the function, which can be seen as
how D handles purity)... however, it breaks the point of purity due to
this:

pure nothrow hash_t toHash() const {
@instance hash_t bad = 0;
++bad;
return hashfn(field) + bad;
}

Now it violates everyone's definition of purity and we can no
longer make our sweet optimizations and reasoning about the code.
Sure, we could "trust the programmers to not do this" ... but
that's another debate entirely.



Yes. I intend to "trust the programmers to not do this".

Otherwise we need to find some way to ensure that a function that
alters external state will always return the same value as long as the
rest of the program doesn't change the state it looks at.


It still wouldn't work though. Your @instance variables couldn't
be stored with the object (and, thus, would have to be a pointer
to mutable memory). So it'd require some backend work to make
sure that's even feasible (it is, you could have an immutable
pointer to a mutable pointer to the int, but let's face it:
that's further spitting in the face of the way D's type system
has been designed).

So, you'd have invisible indirections, additional complexity, and
you'd have to trust the programmers to be responsible. In other
words, C++ + the slowness of indirections.



The idea /was/ to store the @instance variable with the object 
specifically to avoid complex indirections.  Still have to trust 
programmers though :/


Otherwise it's better to just memoize things using external lookups and 
whatnot.  That solution does have complex indirections, but it doesn't 
require trusting the programmer and it exists already.



On Tuesday, 15 May 2012 at 22:33:56 UTC, Era Scarecrow wrote:

Perhaps an alternate workaround... a thought coming to mind, is that
the constructor for a const object lets you set it once in the
constructor (but not touch it again after) So Maybe...?


This is a good approach, but I think a lot of people want something
that's lazy ... if they don't need a hash, they don't want it to be
calculated for them.


FWIW, my idea: the thing we really need to do is to R&D some
design patterns & idioms for D. There's solutions for using const
and caching and such, but formalizing them and working out the
kinks to make sure it's optimal for everyone's circumstances
would be helpful. And people will have to accept that C++'s
particular idioms can't be used with D (and vice versa ... some
things you can do easily in D is infeasible or incorrect/invalid
with C++).

Book idea? :) I'd do it, but I'm just a student, so I haven't
seen even a decent subset of all possible software engineering
problems.

Re: deprecating std.stream, std.cstream, std.socketstream

[Sean Kelly]

On May 15, 2012, at 3:34 PM, "Nathan M. Swan"  wrote:

> On Monday, 14 May 2012 at 15:02:11 UTC, Steven Schveighoffer wrote:
>> In other words, a stream of bytes, not a good range (who wants to get one 
>> byte at a time?).  A stream of UTF text broken into lines, a very good range.
> 
> There are several cases where one would want one byte at the time; e.g. as an 
> input to another range that produces the utf text as an output.
> 
> I do agree for e.g. with binary data some data can't be read with ranges 
> (when you need to read small chunks of varying size), but that doesn't mean 
> most things shouldn't be ranged-based.

You really want both, depending on the situation. I don't see what's weird 
about this. C++ iostreams have input and output iterators built on top as well, 
for much the same reason. The annoying part is that once you've moved to a 
range interface it's hard to go back. Like say I want a ZipRange on top of a 
FileRange.  But now I wan to read structs as binary blobs from that 
uncompressed output. 

One thing I'd like in a buffered input API is a way to perform transactional 
reads such that if the full read can't be performed, the read state remains 
unchanged. The best you can do with most APIs is to check for a desired length, 
but what I'd I don't want to read until a full line is available, and I don't 
know the exact length?  Typically, you end up having to double buffer, which 
stinks. 

Re: arrays: if(null == [ ])

[Jonathan M Davis]

On Wednesday, May 16, 2012 00:48:44 Gor Gyolchanyan wrote:
> No, no and no. toUTFz could be called at compile-time. Absolutely no extra
> run-time allocations, absolutely no run-time overhead.

So, you're going to create a bunch of enums just to pass string literals to C 
functions? Stuff like this happens all the time when interfacing with C code

func("hello world", 5, someVar);

I really don't see why it would be desirable to make

assert("" is null);

pass. And I _really_ don't see a problem with string literals being zero-
terminated. It makes dealing with them easier, and changing it would break a 
lot of code.

- Jonathan M Davis

Re: Getting the const-correctness of Object sorted once and for all

[Chris Cain]

On Tuesday, 15 May 2012 at 21:18:11 UTC, Chad J wrote:

On 05/15/2012 03:32 PM, Chris Cain wrote:

On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:
An idea I thought of is to introduce a method local 
declaration that

allows a method to access instance-specific-state that isn't
accessible to the rest of the class:


This is an interesting idea (as it seems to really try to keep
the state changes internal to the function, which can be seen 
as
how D handles purity)... however, it breaks the point of 
purity due to

this:

pure nothrow hash_t toHash() const {
@instance hash_t bad = 0;
++bad;
return hashfn(field) + bad;
}

Now it violates everyone's definition of purity and we can no
longer make our sweet optimizations and reasoning about the 
code.

Sure, we could "trust the programmers to not do this" ... but
that's another debate entirely.



Yes.  I intend to "trust the programmers to not do this".

Otherwise we need to find some way to ensure that a function 
that alters external state will always return the same value as 
long as the rest of the program doesn't change the state it 
looks at.


It still wouldn't work though. Your @instance variables couldn't
be stored with the object (and, thus, would have to be a pointer
to mutable memory). So it'd require some backend work to make
sure that's even feasible (it is, you could have an immutable
pointer to a mutable pointer to the int, but let's face it:
that's further spitting in the face of the way D's type system
has been designed).

So, you'd have invisible indirections, additional complexity, and
you'd have to trust the programmers to be responsible. In other
words, C++ + the slowness of indirections.

On Tuesday, 15 May 2012 at 22:33:56 UTC, Era Scarecrow wrote:
 Perhaps an alternate workaround... a thought coming to mind, 
is that the constructor for a const object lets you set it once 
in the constructor (but not touch it again after) So 
Maybe...?


This is a good approach, but I think a lot of people want 
something that's lazy ... if they don't need a hash, they don't 
want it to be calculated for them.



FWIW, my idea: the thing we really need to do is to R&D some
design patterns & idioms for D. There's solutions for using const
and caching and such, but formalizing them and working out the
kinks to make sure it's optimal for everyone's circumstances
would be helpful. And people will have to accept that C++'s
particular idioms can't be used with D (and vice versa ... some
things you can do easily in D is infeasible or incorrect/invalid
with C++).

Book idea? :) I'd do it, but I'm just a student, so I haven't
seen even a decent subset of all possible software engineering
problems.

Re: deprecating std.stream, std.cstream, std.socketstream

[Nathan M. Swan]

On Monday, 14 May 2012 at 15:02:11 UTC, Steven Schveighoffer 
wrote:
In other words, a stream of bytes, not a good range (who wants 
to get one byte at a time?).  A stream of UTF text broken into 
lines, a very good range.


There are several cases where one would want one byte at the 
time; e.g. as an input to another range that produces the utf 
text as an output.


I do agree for e.g. with binary data some data can't be read with 
ranges (when you need to read small chunks of varying size), but 
that doesn't mean most things shouldn't be ranged-based.


NMS

Re: Getting the const-correctness of Object sorted once and for all

[Era Scarecrow]

On Tuesday, 15 May 2012 at 21:18:11 UTC, Chad J wrote:

On 05/15/2012 03:32 PM, Chris Cain wrote:
Yep, ya got me.



Maybe there's a solution, but I doubt the solution is something
the programmer can/should do completely transparently.


 Perhaps an alternate workaround... a thought coming to mind, is 
that the constructor for a const object lets you set it once in 
the constructor (but not touch it again after) So Maybe...?


class X {
  uint cached_hash;

  this() {

cached_hash = X.toHash(this); //last line, only if we can 
send 'this'

  }

  static uint toHash(const X x) {
return hashedResult;
  }

  uint toHash(){
return X.toHash(this);
  }

  uint toHash() const {
return hash;
  }
}

 Although there's a lot there, with a const and non-const version 
the const version is optimized and always returned the proper 
precalculated hash, and if it isn't it creates it on the fly as 
appropriate.


 You'd almost say an interface you can attach would be the way to 
get the same basic functionality with minimal effort. So maybe... 
Perhaps a template is better used. Mmm


interface CachedHash(T) {
  private uint cachedHash;

  //your hashing function
  static uint toHash(T);

  //call from constructor
  private void setHash() {
cachedHash = T.toHash(this);
  }
  uint toHash() const {
return cachedHash;
  }

  override uint toHash() {
return T.toHash(this);
  }
}

 You should get the basic idea. Same thing would be done for 
toString with a cached result.

digitalmars-d@puremagic.com

[ponce]

Le 15/05/2012 23:58, Alex Rønne Petersen a écrit :


I suspect he wanted a solution where he could load an arbitrary
function's address.



I'm also searching for a way to get a label address from inline assembly.
This would be useful for hard-coded jumptables.

Re: arrays: if(null == [ ])

[Andrej Mitrovic]

On 5/15/12, Gor Gyolchanyan  wrote:
> No, no and no. toUTFz could be called at compile-time. Absolutely no extra
> run-time allocations, absolutely no run-time overhead.

How about programmer-time overhead? Are *you* volunteering to edit all
the codebases out there that rely on having 0-terminated string
literals?

Re: arrays: if(null == [ ])

[deadalnix]

Le 15/05/2012 15:29, Alex Rønne Petersen a écrit :

On 15-05-2012 15:22, Gor Gyolchanyan wrote:

On Tue, May 15, 2012 at 4:00 PM, Alex Rønne Petersen
mailto:xtzgzo...@gmail.com>> wrote:


Yes, because using a Phobos function in druntime is perfectly
possible! Totally!
--
- Alex


Isn't it obvious what needs to be done? Come on, it's no too hard to
see...


--
Bye,
Gor Gyolchanyan.


No, it should not be moved to druntime. druntime is the low-level
abstraction layer over the compiler, nothing else.

Further, all the write* functions perform GC allocation, which is
unacceptable in druntime.



I do agree that it does not belong to druntime.

However :
1/ druntime already perfom GC aloc.
2/ druntime isn't supposed to printf anyway.

Re: The more interesting question

[deadalnix]

Le 15/05/2012 17:51, Christophe a écrit :

deadalnix , dans le message (digitalmars.D:167404), a écrit :

This looks to me like a bad practice. C string and D string are
different beasts, and we have toStringz .


C string and D string are different, but it's not a bad idea to have
string *literals* that works for both C and D strings, otherwise using
printf will lead to a bug each time the programmer forget the trailing
\0.



Due to slicing, it is already unsafe to pass a D string to C code. The 
main problem is array casting silently to pointers, making the error 
easy to do.


Fixing the problem for literal isn't going to solve it at all.

The real solution is toStringz

Re: The more interesting question

[deadalnix]

Le 15/05/2012 20:34, Alex Rønne Petersen a écrit :

Besides, this is probably not going to change anyway. We're focusing on
stabilizing the language, not changing it.



This always have been a design mistake to auto cast array in pointers. 
This is silent fallback to usafe world, and what we want to avoid.


This has no benefit because using .ptr isn't really complex and make the 
transition obvious.


This has been raised many time in the past as being an issue, and it fit 
nicely here.


Having \0 terminated string in D were it has no usage is quite dumb.

Re: The more interesting question

[deadalnix]

Le 15/05/2012 21:57, Andrew Wiley a écrit :

On Tue, May 15, 2012 at 11:46 AM, deadalnix mailto:deadal...@gmail.com>> wrote:

Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :



On Tue, May 15, 2012 at 7:51 PM, Christophe
mailto:trav...@phare.normalesup.org>
>> wrote:

using printf will lead to a bug each time the programmer
forget the
trailing
\0.


First of all, printf shouldn't be used! There's writef and it's
superior
to printf in any way!
Second of all, if the zero-termination of literals are to be
removed,
the literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use
toUTF8z
to get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of
toUTF8z to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any
security
or performance flaws in this scheme.
--
Bye,
Gor Gyolchanyan.


May god ear you !


Unfortunately, using writef/writefln would make DRuntime depend on
Phobos, which is unacceptable.



druntime isn't supposed to printf stuff.

digitalmars-d@puremagic.com

[Alex Rønne Petersen]

On 15-05-2012 23:27, deadalnix wrote:

Le 15/05/2012 21:33, Mehrdad a écrit :

How do get the address of a function in naked assembly code?

void foo()
{
asm
{
naked;
mov EAX, &foo;
}
}

This doesn't work...


As it is naked,

mov EAX, EIP;

is enough.


I suspect he wanted a solution where he could load an arbitrary 
function's address.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

digitalmars-d@puremagic.com

[ponce]

Le 15/05/2012 23:27, deadalnix a écrit :


mov EAX, EIP;

is enough.


I think this is illegal in assembly, try to call a label in your 
function then pop.


void* selfAddress() // actually tested
{
asm
{
naked;
call my_label;
my_label:
pop EAX;
sub EAX, 5;
ret;
}
}

digitalmars-d@puremagic.com

[deadalnix]

Le 15/05/2012 21:33, Mehrdad a écrit :

How do get the address of a function in naked assembly code?

void foo()
{
asm
{
naked;
mov EAX, &foo;
}
}

This doesn't work...


As it is naked,

mov EAX, EIP;

is enough.

Re: New Traits

[John Maschmeyer]

On Tuesday, 15 May 2012 at 17:18:57 UTC, Philippe Sigaud wrote:
Can you give us a simple example of what codeof produces? How 
does it

deal with functions overloads?


import std.stdio;

void bar() {
   writeln("testing");
}

struct Foo {
 public:
  int x;
  int y;
}

void main() {
   writeln("*");
   writeln(__traits(codeof, bar));
   writeln("*");
   writeln(__traits(codeof, Foo));
   writeln("*");
}

This prints:
*
void bar()
{
writeln("testing");
}

*
struct Foo
{
public
{
int x;
int y;
}
}

*

I'm not sure how well this works with overloads.  If you just use 
the symbol name, it works like other traits and returns the 
source code for the first match.  I tried using the getOverloads 
trait and some alias magic, but all I've been able to do so far 
is get the prototype for overloads.  I'm guessing it has 
something to do with using an alias instead of the actual symbol. 
 I think we need a better way to reference an overloaded symbol.

Re: Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 03:32 PM, Chris Cain wrote:

On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:

An idea I thought of is to introduce a method local declaration that
allows a method to access instance-specific-state that isn't
accessible to the rest of the class:


This is an interesting idea (as it seems to really try to keep
the state changes internal to the function, which can be seen as
how D handles purity)... however, it breaks the point of purity due to
this:

pure nothrow hash_t toHash() const {
@instance hash_t bad = 0;
++bad;
return hashfn(field) + bad;
}

Now it violates everyone's definition of purity and we can no
longer make our sweet optimizations and reasoning about the code.
Sure, we could "trust the programmers to not do this" ... but
that's another debate entirely.



Yes.  I intend to "trust the programmers to not do this".

Otherwise we need to find some way to ensure that a function that alters 
external state will always return the same value as long as the rest of 
the program doesn't change the state it looks at.





To communicate intents to invalidate the cache:

class Foo
{
private toStringCacheValid = false;

public void methodThatInvalidatesCache()
{
...
toStringCacheValid = false;
}

public pure nothrow string toString() const
{
// strCache gets stored in an instance of Foo
// strCache is only accessable in this method body.
@instance string strCache = null;

if ( !toStringCacheValid )
{
// Observable change in strCache!
// ... because isCaching reveals it
// to everyone.
strCache = someComplicatedCalculation();
toStringCacheValid = true;
return strCache;
}
else
return strCache;
}
}


... and setting toStringCacheValid to true in toString violates
const, so this is absolutely not allowed. Sorry.



Yep, ya got me.



Maybe there's a solution, but I doubt the solution is something
the programmer can/should do completely transparently.

digitalmars-d@puremagic.com

[Alex Rønne Petersen]

On 15-05-2012 22:51, Gor Gyolchanyan wrote:

I think I had that one before. Try this one:
void foo()
{
 void* foopt = cast(void*)&foo;
 asm
 {
 naked;
 mov EAX fooptr;
 }
}

On Tue, May 15, 2012 at 11:33 PM, Mehrdad mailto:wfunct...@hotmail.com>> wrote:

How do get the address of a function in naked assembly code?

void foo()
{
asm
{
naked;
mov EAX, &foo;
}
}

This doesn't work...




--
Bye,
Gor Gyolchanyan.


That's not naked inline asm, though.

Something like this might work:

void foo()
{
asm
{
naked;
mox EAX, dword ptr foo;
/* whatever... */
}
}

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

digitalmars-d@puremagic.com

[Gor Gyolchanyan]

I think I had that one before. Try this one:
void foo()
{
void* foopt = cast(void*)&foo;
asm
{
naked;
mov EAX fooptr;
}
}

On Tue, May 15, 2012 at 11:33 PM, Mehrdad  wrote:

> How do get the address of a function in naked assembly code?
>
> void foo()
> {
>asm
>{
>naked;
>mov EAX, &foo;
>}
> }
>
> This doesn't work...
>



-- 
Bye,
Gor Gyolchanyan.

Re: Windows application manifests

[Gor Gyolchanyan]

Thanks a lot! I'll look into it!

On Tue, May 15, 2012 at 11:21 PM, Denis Shelomovskij <
verylonglogin@gmail.com> wrote:

> 15.05.2012 22:08, Gor Gyolchanyan написал:
>
>  Thanks!
>> It doesn't compile. After I fixed the path to the Windows SDK, I got the
>> error: C:\Program Files (x86)\Microsoft
>> SDKs\Windows\v7.0A\Include\**SpecStrings.h(11) : fatal error RC1015:
>> cannot open include file 'sal.h'
>>
>
> Looks like you didn't change `/i"%ProgramFiles%\Microsoft Visual Studio
> 9.0\VC\include"` to your path (sal.h is there) or you hasn't it installed.
>
>
> --
> Денис В. Шеломовский
> Denis V. Shelomovskij
>



-- 
Bye,
Gor Gyolchanyan.

Re: arrays: if(null == [ ])

[Gor Gyolchanyan]

No, no and no. toUTFz could be called at compile-time. Absolutely no extra
run-time allocations, absolutely no run-time overhead.

On Tue, May 15, 2012 at 11:05 PM, Jonathan M Davis wrote:

> On Tuesday, May 15, 2012 17:35:58 Gor Gyolchanyan wrote:
> > Even if it's wrong to move writef to druntime, the toUTFz is still a very
> > small word to write.
>
> Using toStringz or toUTFz instead of having string literals be
> zero-terminated
> would force allocating extra strings (string literals are in an RO portion
> of
> memory - at least on Linux - so you can't append to them without
> reallocating).
>
> Making it so that string literals weren't null terminated would break a
> _lot_
> of code for little-to-no benefit and a definite cost. I really don't see
> the
> problem with "" being different from cast(string)[] - particularly when the
> fact that "" is non-null is _useful_.
>
> - Jonathan M Davis
>



-- 
Bye,
Gor Gyolchanyan.

Re: Properties don't behave like variables?

[Michael]

On Monday, 14 May 2012 at 21:29:52 UTC, Mehrdad wrote:

On Monday, 14 May 2012 at 21:08:15 UTC, Michael wrote:

I see.
So where to vote for this enhancement?


Ugh, wrong link...

should've been: 
http://d.puremagic.com/issues/show_bug.cgi?id=8056


Done.

Re: UFCS on forward reference

[Jens Mueller]

Timon Gehr wrote:
> On 05/15/2012 11:18 AM, Jens Mueller wrote:
> >Timon Gehr wrote:
> >>On 05/15/2012 07:44 AM, Ali Çehreli wrote:
> >>>On 05/14/2012 10:02 PM, Timon Gehr wrote:
> On 05/15/2012 04:28 AM, John Belmonte wrote:
> >C API's often use a opaque struct pointer as a handle. Mapping such a
> >struct to D using a forward declaration, I noticed that UFCS doesn't
> >work:
> >
> >struct State;
> >...
> >State* s = new_state();
> >foo(s); // ok
> >s.foo(); // compile error
> >
> >Error detail:
> >
> >Error: struct State is forward referenced when looking for 'foo'
> >Error: struct State is forward referenced when looking for 'opDot'
> >Error: struct State is forward referenced when looking for 'opDispatch'
> >
> >I'm wondering if anything would be harmed by removing this restriction.
> >
> >As a workaround I can use "struct State {}", but that feels wrong.
> >
> 
> This is a compiler bug. You can report it here:
> http://d.puremagic.com/issues/
> >>>
> >>>I would expect the compiler to need to see the definition of S to know
> >>>that it really does not have a matching foo() member function.
> >>>
> >>>Ali
> >>>
> >>
> >>S is opaque. It does not have any visible member functions.
> >
> >How should the compiler infer that S is opaque? How does it know when
> >you write "struct State;" that State has no members? Is opaqueness
> >implied when I do a forward declaration?
> >
> >Jens
> 
> This is a compile time error:
> struct S;
> struct S{}

Yes. But how does this relate to the issue?

Jens

Re: The more interesting question

[Andrew Wiley]

On Tue, May 15, 2012 at 11:46 AM, deadalnix  wrote:

> Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :
>
>>
>>
>> On Tue, May 15, 2012 at 7:51 PM, Christophe
>> > >
>> wrote:
>>
>>using printf will lead to a bug each time the programmer forget the
>>trailing
>>\0.
>>
>>
>> First of all, printf shouldn't be used! There's writef and it's superior
>> to printf in any way!
>> Second of all, if the zero-termination of literals are to be removed,
>> the literals will no longer be accepted as a pointer to a character.
>> The appropriate type mismatch error will force the user to use toUTF8z
>> to get ht e zero-terminated utf-8 version of the original string.
>> In case it's a literal, one could use the compile-time version of
>> toUTF8z to avoid run-time overhead.
>> This all doesn't sound like a bad idea to me. I don't see any security
>> or performance flaws in this scheme.
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> May god ear you !
>

Unfortunately, using writef/writefln would make DRuntime depend on Phobos,
which is unacceptable.

digitalmars-d@puremagic.com

[Mehrdad]

How do get the address of a function in naked assembly code?

void foo()
{
asm
{
naked;
mov EAX, &foo;
}
}

This doesn't work...

Re: Getting the const-correctness of Object sorted once and for all

[Chris Cain]

On Tuesday, 15 May 2012 at 18:07:12 UTC, Chad J wrote:
An idea I thought of is to introduce a method local declaration 
that allows a method to access instance-specific-state that 
isn't accessible to the rest of the class:


This is an interesting idea (as it seems to really try to keep
the state changes internal to the function, which can be seen as
how D handles purity)... however, it breaks the point of purity 
due to this:


pure nothrow hash_t toHash() const {
@instance hash_t bad = 0;
++bad;
return hashfn(field) + bad;
}

Now it violates everyone's definition of purity and we can no
longer make our sweet optimizations and reasoning about the code.
Sure, we could "trust the programmers to not do this" ... but
that's another debate entirely.


To communicate intents to invalidate the cache:

class Foo
{
private toStringCacheValid = false;

public void methodThatInvalidatesCache()
{
...
toStringCacheValid = false;
}

public pure nothrow string toString() const
{
// strCache gets stored in an instance of Foo
// strCache is only accessable in this method body.
@instance string strCache = null;

if ( !toStringCacheValid )
{
// Observable change in strCache!
// ... because isCaching reveals it
//   to everyone.
strCache = someComplicatedCalculation();
toStringCacheValid = true;
return strCache;
}
else
return strCache;
}
}


... and setting toStringCacheValid to true in toString violates
const, so this is absolutely not allowed. Sorry.


Maybe there's a solution, but I doubt the solution is something
the programmer can/should do completely transparently.

Re: Windows application manifests

[Denis Shelomovskij]

15.05.2012 22:08, Gor Gyolchanyan написал:

Thanks!
It doesn't compile. After I fixed the path to the Windows SDK, I got the
error: C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Include\SpecStrings.h(11) : fatal error RC1015:
cannot open include file 'sal.h'


Looks like you didn't change `/i"%ProgramFiles%\Microsoft Visual Studio 
9.0\VC\include"` to your path (sal.h is there) or you hasn't it installed.


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/15/2012 02:49 PM, Christophe wrote:

Chad J , dans le message (digitalmars.D:167461), a écrit :

An idea I thought of is to introduce a method local declaration that
allows a method to access instance-specific-state that isn't accessible
to the rest of the class:


It is not good for caching results, since the cache often has to be
erased when the object is modified.


I did outline a way to invalidate caches with this.

Re: deprecating std.stream, std.cstream, std.socketstream

[Jonas Drewsen]

On Sunday, 13 May 2012 at 22:26:17 UTC, Walter Bright wrote:

On 5/13/2012 3:16 PM, Nathan M. Swan wrote:
Trying to make it read lazily is even harder, as all std.utf 
functions work on

arrays, not ranges. I think this should change.


Yes, std.utf should be upgraded to present range interfaces.


+1 on that.

I really needed it when doing the std.net.curl stuff and would be
happy to move it to a more generic handling in std.utf.

Re: arrays: if(null == [ ])

[Jonathan M Davis]

On Tuesday, May 15, 2012 17:35:58 Gor Gyolchanyan wrote:
> Even if it's wrong to move writef to druntime, the toUTFz is still a very
> small word to write.

Using toStringz or toUTFz instead of having string literals be zero-terminated 
would force allocating extra strings (string literals are in an RO portion of 
memory - at least on Linux - so you can't append to them without 
reallocating).

Making it so that string literals weren't null terminated would break a _lot_ 
of code for little-to-no benefit and a definite cost. I really don't see the 
problem with "" being different from cast(string)[] - particularly when the 
fact that "" is non-null is _useful_.

- Jonathan M Davis

Re: The more interesting question

[Andrej Mitrovic]

On 5/15/12, Alex Rønne Petersen  wrote:
> PS: Removing null-terminated string literals

Someone needs to put a big fat sign on the dlang page that says
LANGUAGE STABLE - NO MORE CODE BREAKAGE PLANNED. Although additive
improvements might be ok..

But what is up with these suggestions lately? Removing
null-termination would break a ton of code that interoperates with C
libraries.

Re: Getting the const-correctness of Object sorted once and for all

[Christophe]

Chad J , dans le message (digitalmars.D:167461), a écrit :
> An idea I thought of is to introduce a method local declaration that 
> allows a method to access instance-specific-state that isn't accessible 
> to the rest of the class:

It is not good for caching results, since the cache often has to be 
erased when the object is modified.

Re: UFCS on forward reference

[Timon Gehr]

On 05/15/2012 11:18 AM, Jens Mueller wrote:

Timon Gehr wrote:

On 05/15/2012 07:44 AM, Ali Çehreli wrote:

On 05/14/2012 10:02 PM, Timon Gehr wrote:

On 05/15/2012 04:28 AM, John Belmonte wrote:

C API's often use a opaque struct pointer as a handle. Mapping such a
struct to D using a forward declaration, I noticed that UFCS doesn't
work:

struct State;
...
State* s = new_state();
foo(s); // ok
s.foo(); // compile error

Error detail:

Error: struct State is forward referenced when looking for 'foo'
Error: struct State is forward referenced when looking for 'opDot'
Error: struct State is forward referenced when looking for 'opDispatch'

I'm wondering if anything would be harmed by removing this restriction.

As a workaround I can use "struct State {}", but that feels wrong.



This is a compiler bug. You can report it here:
http://d.puremagic.com/issues/


I would expect the compiler to need to see the definition of S to know
that it really does not have a matching foo() member function.

Ali



S is opaque. It does not have any visible member functions.


How should the compiler infer that S is opaque? How does it know when
you write "struct State;" that State has no members? Is opaqueness
implied when I do a forward declaration?

Jens


This is a compile time error:
struct S;
struct S{}

Re: arrays: if(null == [ ])

[Timon Gehr]

On 05/15/2012 12:09 PM, Gor Gyolchanyan wrote:

There's not reason to use printf! This is ridiculous! We haev a
type-safe writef, which does exactly that and does it better.
Besides, wrapping the literal into a toUTFz is not too difficult!

Re: Windows application manifests

[Gor Gyolchanyan]

Thanks for the detailed info! Definitely will check it out!

On Tue, May 15, 2012 at 10:38 PM, Andrej Mitrovic <
andrej.mitrov...@gmail.com> wrote:

> On 5/15/12, Gor Gyolchanyan  wrote:
> > But what do windows resources have to do with the manifests?
>
> You use a resource file to load a manifest into the executable. There
> are a couple of examples here:
>
>
> https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/VisualStyles
>
> https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/VisualStyles2
>
> https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/ThemedSimpleWakeUp
>
> https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/ThemedWakeUp
>
> enable-theme.xml is the manifest, and resource.rc just references this
> xml file. The resource file is compiled into a .res file, and this
> file is then passed directly to DMD.
>
> For your own purposes try to just take the .rc/.res/.xml files, pass
> .res to dmd when compiling your app and see if the visual styles work
> for you.
>
> The last example loads the manifest dynamically, based on a sample
> from the DFL library.
>



-- 
Bye,
Gor Gyolchanyan.

Re: The more interesting question

[Timon Gehr]

On 05/15/2012 06:19 PM, Gor Gyolchanyan wrote:



On Tue, May 15, 2012 at 7:51 PM, Christophe
mailto:trav...@phare.normalesup.org>> wrote:

using printf will lead to a bug each time the programmer forget the
trailing
\0.


First of all, printf shouldn't be used!


First of all, 'is' shouldn't be used to compare built-in arrays!


There's writef and it's superior to printf in any way!


No it is not! printf and scanf are so much faster than writef/readf that 
it is relevant! The poor performance of writef/readf makes it 
embarrassing for a university to use D as a teaching language!



Second of all, if the zero-termination of literals are to be removed,
the literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use toUTF8z
to get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of
toUTF8z to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any security
or performance flaws in this scheme.


There are none in the current scheme.

Re: The more interesting question

[Timon Gehr]

On 05/15/2012 06:45 PM, deadalnix wrote:

Le 15/05/2012 17:51, Christophe a écrit :

deadalnix , dans le message (digitalmars.D:167404), a écrit :

This looks to me like a bad practice. C string and D string are
different beasts, and we have toStringz .


C string and D string are different, but it's not a bad idea to have
string *literals* that works for both C and D strings, otherwise using
printf will lead to a bug each time the programmer forget the trailing
\0.


It is kind of dumb to create a WAT is the language because druntime dev
did mistakes. It have to be fixed.


You can't rely on an empty string to be null since you must be able to
reserve place at the end of the array, and or the string could be the
result of poping a full string.


This is why I stated put null when the string length is SET to 0, not
when it is 0.

So it is nulled when I create an empty slice, or do arr.length = 0


Might as well start Microsoft Flight Simulator when the length is set to 
9797.


If you want to clear the contents of the array, use arr=null or arr=[].

Re: The more interesting question

[Alex Rønne Petersen]

On 15-05-2012 19:29, Gor Gyolchanyan wrote:
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen  > wrote:
>  >> Nope. write* perform GC allocation.
>
> 1. Give me the top 3 use cases, where GC allocation is intolerable when
> writing to an output stream.

Who the hell am I or you to dictate use cases? But a few off the top of 
my head:


1) Building without a GC *at all* (and yes, it is possible).
2) When writing high performance tools for doing UNIX-style program 
output piping.


> 2. writef and friends could get cousins like nogcwritef and
> nogcwritefln. (see comments beloaw)

Patches welcome.

> 3. GC can be turned off and gc-allocated memory can be GC.freeed.

Yes, if you alter the implementation. You can't free it from the call 
site. Again, patches welcome.


> 4. printf could get wrapped to take d-strings by malloc-ing new buffers
> for the c-strings if necessary.

And just about every C function taking strings, ever. This is a bad 
strategy, and makes D's C interoperability worse.


>
>  >> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen  > wrote:
>  >> You're assuming everyone uses Phobos. This is not the case.
>
> I'm assuming everyone is sane, because Phobos is called "the standard
> library" for a damned good reason. For those who don't - they're welcome
> to use whatever they want and convert d-strings to c-strings any way
> they choose if necessary.

Yes, let's cripple a systems language for the comfort of the non-systems 
programmers. Excellent idea.


>
> --
> Bye,
> Gor Gyolchanyan.

PS: Removing null-terminated string literals is not going to fix the 
array slice corner cases by itself. I think this discussion is fairly 
pointless. If you want to fix slices, go all the way with it, not just 
half the way.


Besides, this is probably not going to change anyway. We're focusing on 
stabilizing the language, not changing it.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Windows application manifests

[Andrej Mitrovic]

On 5/15/12, Gor Gyolchanyan  wrote:
> But what do windows resources have to do with the manifests?

You use a resource file to load a manifest into the executable. There
are a couple of examples here:

https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/VisualStyles
https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/VisualStyles2
https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/ThemedSimpleWakeUp
https://github.com/AndrejMitrovic/DWinProgramming/tree/master/Samples/Extra/ThemedWakeUp

enable-theme.xml is the manifest, and resource.rc just references this
xml file. The resource file is compiled into a .res file, and this
file is then passed directly to DMD.

For your own purposes try to just take the .rc/.res/.xml files, pass
.res to dmd when compiling your app and see if the visual styles work
for you.

The last example loads the manifest dynamically, based on a sample
from the DFL library.

Re: SSE and AVX with D

[jerro]

You can use the inline assembler for shufps, also for AVX.


Of course you can, I forgot to mention that. I do that in
parts of pfft when it is compiled using DMD (but only for
SSE). But because of the overhead of copying values from the
stack to registers and back to the stack or calling a function
it only makes sense to do that when the chunk of code you are
replacing with inline assmbly takes longer than a few cycles.
This forces you to write larger chunks of code in inline
assembly, which is not always practical.

Re: The more interesting question

[Timon Gehr]

On 05/15/2012 10:39 AM, deadalnix wrote:

Le 14/05/2012 19:38, Alex Rønne Petersen a écrit :

On 14-05-2012 15:21, Gor Gyolchanyan wrote:

I thing the zero-terminated literal shtick is pointless. Literals are
rarely passed to C functions, so we gotta use the std.utf.toUTFz anyway.

On Mon, May 14, 2012 at 5:03 PM, Christophe
mailto:trav...@phare.normalesup.org>>
wrote:

deadalnix , dans le message (digitalmars.D:167258), a écrit :
> A good solution would be to set the pointer to 0 when the length
is set
> to 0.

String literal are zero-terminated. "" cannot point to 0x0,
unless we drop this rule. Maybe we should...




--
Bye,
Gor Gyolchanyan.


This is very false. I invite you to read almost any module in druntime.
You'll find that it makes heavy use of printf debugging.

That being said, dropping the null-termination rule when passing strings
to non-const(char)* parameters/variables/etc would be sane enough (I
think).



This looks to me like a bad practice. C string and D string are
different beasts, and we have toStringz .



It is not. Claiming valid use cases are bad practice does not help the 
discussion. It is disrespectful and patronising.



It is kind of dumb to create a WAT is the language because druntime dev
did mistakes.


The conclusion is based on a wrong premise therefore it is meaningless.


It have to be fixed.


It can be fixed better by making (null !is []) hold instead of making 
("" is null) hold.

Re: Getting the const-correctness of Object sorted once and for all

[Chad J]

On 05/13/2012 12:39 PM, Stewart Gordon wrote:

http://d.puremagic.com/issues/show_bug.cgi?id=1824

This has gone on for too long.

Object.toString, .toHash, .opCmp and .opEquals should all be const.
(It's also been stated somewhere that they should be pure and nothrow,
or something like that, but I forget where.)

This makes it a nightmare to use const objects in data structures, among
other things, at best forcing the use of ugly workarounds. There are
probably other, more serious effects of this that can't easily be worked
around.

It seems that the main obstacle is rewriting the relevant methods in
std.stream. The current implementation doesn't make sense anyway -
reading the entire contents of a file is certainly not the way to
generate a hash or string representation of the stream. I'm thinking the
hash should probably be the stream handle, and the string representation
could perhaps be the full pathname of the file. Of course, what it
should be for non-file streams is another matter. (This would be a
change at the API level, but when the API's as fundamentally flawed as
this)

Are there any other bits of druntime/Phobos that need to be sorted out
before these methods can be declared const/pure/nothrow once and for all?

Stewart.


I haven't read all of the replies here, but the gist I'm getting is that 
we have two contradictory interests:
(1.)  .toString(), .toHash(), .opCmp(), .opEquals(), should be 
const/pure/nothrow because their operations are inherently 
const/pure/nothrow and it would be both unintuitive and less reusable if 
they weren't.
(2.)  Marking these as const/pure/nothrow prevents caching and 
optimizations that are important for real-world code.


When I see a dichotomy like this forming, I have to think that we're 
missing something.  There is definitely a better way!  I, for one, 
wouldn't give up until it's found.




So I'll toss out an idea:

I think the const we want is a kind of "interface const" rather than an 
"implementation const".  Interface const means that calling the method 
will not cause any /observable/ state-changes in the referred object. 
Implementation const is stricter: it means that calling the method will 
not cause ANY state-changes in the referred object at all.


I am going to be fairly strict about my notion of observable.  Changes 
to private members are observable:


class Foo
{
private string strCache = null;

// The isCaching method makes strCache "observable".
public bool isCaching()
{
if ( strCache is null )
return false;
else
return true;
}

public string toString()
{
if ( strCache is null )
{
// Observable change in strCache!
// ... because isCaching reveals it
//   to everyone.
strCache = someComplicatedCalculation();
return strCache;
}
else
return strCache;
}
}


An idea I thought of is to introduce a method local declaration that 
allows a method to access instance-specific-state that isn't accessible 
to the rest of the class:


class Foo
{
// The isCaching method is no longer possible.

public pure nothrow string toString() const
{
// strCache gets stored in an instance of Foo
// strCache is only accessable in this method body.
@instance string strCache = null;

if ( strCache is null )
{
// Observable change in strCache!
// ... because isCaching reveals it
//   to everyone.
strCache = someComplicatedCalculation();
return strCache;
}
else
return strCache;
}
}

Now it is not possible (or at least, not very easy at all) for the 
statefulness of strCache to leak into the rest of the class (or 
program).  It is not "observable".  If the implementor does their 
caching wrong, then the statefulness might be observable from the 
toString method, but nowhere else (except for methods that call 
toString).  It's not a perfect situation, but it's /a lot/ better.  We 
may be required to trust the implementor a little bit and assume that 
they know how to make sure strCache's statefulness isn't observable (ex: 
two calls to toString() should return the same results).


To communicate intents to invalidate the cache:

class Foo
{
private toStringCacheValid = false;

public void methodThatInvalidatesCache()
{
...
toStringCacheValid = false;
}

public pure nothrow string toString() const
{
// strCache gets stored in an instance of 

Re: Windows application manifests

[Gor Gyolchanyan]

Thanks!
It doesn't compile. After I fixed the path to the Windows SDK, I got the
error: C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Include\SpecStrings.h(11) : fatal error RC1015: cannot
open include file 'sal.h'

But what do windows resources have to do with the manifests?

On Tue, May 15, 2012 at 9:53 PM, Denis Shelomovskij <
verylonglogin@gmail.com> wrote:

> 15.05.2012 20:16, Gor Gyolchanyan написал:
>
>> On Tue, May 15, 2012 at 8:07 PM, Kagamin > > wrote:
>>
>>Manifests are extensible resources, they are used for various things
>>which require storing metadata in executable modules, for example
>>they're used to load version 6 of comctl32.dll instead of version 5
>>(pre-XP), thus getting different set of common controls, which
>>support ux themes.
>>
>>
>> Thanks for the reply! How do I include such a manifest to my DMD-built
>> executable?
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> An example of my own preferred configuration:
> http://deoma-cmd.ru/files/**other/DWinResExample.7z
>
> Everything in common folder is really common.
>
> `requestedExecutionLevel` should be also defined in manifest or Windows
> 6.x's UAC will use heuristics to choose required privilege level.
>
> --
> Денис В. Шеломовский
> Denis V. Shelomovskij
>



-- 
Bye,
Gor Gyolchanyan.

Re: Windows application manifests

[Denis Shelomovskij]

15.05.2012 20:16, Gor Gyolchanyan написал:

On Tue, May 15, 2012 at 8:07 PM, Kagamin mailto:s...@here.lot>> wrote:

Manifests are extensible resources, they are used for various things
which require storing metadata in executable modules, for example
they're used to load version 6 of comctl32.dll instead of version 5
(pre-XP), thus getting different set of common controls, which
support ux themes.


Thanks for the reply! How do I include such a manifest to my DMD-built
executable?

--
Bye,
Gor Gyolchanyan.


An example of my own preferred configuration:
http://deoma-cmd.ru/files/other/DWinResExample.7z

Everything in common folder is really common.

`requestedExecutionLevel` should be also defined in manifest or Windows 
6.x's UAC will use heuristics to choose required privilege level.


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: SSE and AVX with D

[Walter Bright]

On 5/15/2012 9:39 AM, jerro wrote:

Note that core.simd currently only defines SSE intrinsics for
instructions of the form

INSTRUCTION xmm1, xmm2/m128

which means that instructions such as shufps are not supported.
You could take a look at gdc, which provides gcc builtins
through module gcc.builtins. To find the builtin names you can
take a look at gcc implementation of xmmintrin.h. GDC also
produces faster code than DMD, especially for floating point
code. It does not yet support AVX, though.

If you want to use AVX for operations that don't have an
operator, currently your only choice (AFAIK) is to use LDC
and an ugly workaround that I used at
https://github.com/jerro/pfft. You write your"intrinsics"
in c and use clang to compile them to .bc (or write a .ll
file manually if you know the llvm assembly language). Then
you compile your D code with LLVM using the flags -output-bc
and -single-obj. You merge the resulting .bc file with the
"intrinsics" file using llvm-link, then optimize it using
opt and convert them to assembly using llc. Here is an
example:

https://github.com/jerro/pfft/blob/master/build-ldc2.sh

I have only tried this on linux.


You can use the inline assembler for shufps, also for AVX.

Re: The more interesting question

[David Nadlinger]

On Tuesday, 15 May 2012 at 17:30:53 UTC, Gor Gyolchanyan wrote:
It can't be accurately measured, because the number of string 
literals

available at a single compiler pass is vastly varying.


Of course the actual amount varies from application to 
application, but it should be possible to obtain some ballpark 
figures for usual and for string-heavy applications…


David

Re: The more interesting question

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 9:23 PM, David Nadlinger  wrote:

> On Tuesday, 15 May 2012 at 16:22:22 UTC, Dmitry Olshansky wrote:
>
>> Moreover compiler can do some extra string pooling iff zero termination
>> goes away. Like:
>> "Hello World!" & "Hello" sharing the same piece of ROM.
>>
>
> Has anyone actually done some research on how much space this could
> actually save in practice?
>
> David
>

It can't be accurately measured, because the number of string literals
available at a single compiler pass is vastly varying.

-- 
Bye,
Gor Gyolchanyan.

Re: The more interesting question

[Gor Gyolchanyan]

>> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen wrote:
>> Nope. write* perform GC allocation.

1. Give me the top 3 use cases, where GC allocation is intolerable when
writing to an output stream.
2. writef and friends could get cousins like nogcwritef and nogcwritefln.
(see comments beloaw)
3. GC can be turned off and gc-allocated memory can be GC.freeed.
4. printf could get wrapped to take d-strings by malloc-ing new buffers for
the c-strings if necessary.

>> On Tue, May 15, 2012 at 9:16 PM, Alex Rønne Petersen 
 wrote:
>> You're assuming everyone uses Phobos. This is not the case.

I'm assuming everyone is sane, because Phobos is called "the standard
library" for a damned good reason. For those who don't - they're welcome to
use whatever they want and convert d-strings to c-strings any way they
choose if necessary.

-- 
Bye,
Gor Gyolchanyan.

Re: The more interesting question

[David Nadlinger]

On Tuesday, 15 May 2012 at 16:22:22 UTC, Dmitry Olshansky wrote:
Moreover compiler can do some extra string pooling iff zero 
termination goes away. Like:

"Hello World!" & "Hello" sharing the same piece of ROM.


Has anyone actually done some research on how much space this 
could actually save in practice?


David

Re: D dropped in favour of C# for PSP emulator

[Kirill]

On Monday, 14 May 2012 at 10:31:47 UTC, Simen Kjaeraas wrote:
On Mon, 14 May 2012 12:01:06 +0200, Peter Alexander 
 wrote:



On Sunday, 13 May 2012 at 10:08:47 UTC, bearophile wrote:

Andrei Alexandrescu:


assumeSorted(range).contains(object)

is still one line, safer, and IMHO more self-explanatory.


It's self-explanatory if the name there contains something 
like

"binarySearch". Otherwise it is NOT self-explanatory, I can't
assume it will use a binary search.
So it's surely not intuitive.

Bye,
bearophile


100% agree with this.

How anyone can possibly think that using 
assumeSorted(r).contains(x) to do a binary search is more 
self-explanatory than just writing binarySearch(r, x) is 
beyond me. It's mind-boggling.


It is not intuitive, I agree. It is, however, documenting. 
You're not
calling binarySearch on any old array, you assume it is sorted, 
*then*

search it.

Perhaps it would be better to have a binarySearch function, 
which can
only take a SortedRange, and gives an explanatory error message 
when used

with a NonSortedRange.


How about users who don't know what binary search is. binary 
search is an intuitive concept for people who have good 
programming experience but assumeSorted(r).contains(x) is more 
intuitive to higher level users. see how many searches you get 
with binary search on google and how many with contains and 
sorted. I'm not a developer, I do quantum chemistry and write 
based on formulas and algorithms in papers, not on libraries. I 
would prefer people to write code in more general concepts so 
it's easier for me to understand and learn. And if you know 
binary search, it's not that much harder to change your style to 
assumeSorted(r).contains(x); in comparison, to a newbie learning 
binary search. Also having multiple ways of doing the same thing 
makes usage more confusing, so it should be avoided unless really 
needed.

So in short, I support that Andrei aims for larger audience.

Re: New Traits

[Philippe Sigaud]

On Tue, May 15, 2012 at 1:13 AM, John Maschmeyer  wrote:
> I implemented some new traits that seemed to have a lot of
> interest recently.

> I've implemented parameterNames, isPublic, isPrivate,
> isProtected, isPackge, isExport, and codeof traits.

> codeof was discussed recently in
> http://forum.dlang.org/thread/huyqfcoosgzfneswn...@forum.dlang.org.
>   It gives you access to the source code of functions, classes,
> etc.

Awesome!

Can you give us a simple example of what codeof produces? How does it
deal with functions overloads?

Re: The more interesting question

[Alex Rønne Petersen]

On 15-05-2012 18:19, Gor Gyolchanyan wrote:



On Tue, May 15, 2012 at 7:51 PM, Christophe
mailto:trav...@phare.normalesup.org>> wrote:

using printf will lead to a bug each time the programmer forget the
trailing
\0.


First of all, printf shouldn't be used! There's writef and it's superior
to printf in any way!


Nope. write* perform GC allocation.


Second of all, if the zero-termination of literals are to be removed,
the literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use toUTF8z
to get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of
toUTF8z to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any security
or performance flaws in this scheme.
--
Bye,
Gor Gyolchanyan.


You're assuming everyone uses Phobos. This is not the case.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: The more interesting question

[deadalnix]

Le 15/05/2012 17:51, Christophe a écrit :

deadalnix , dans le message (digitalmars.D:167404), a écrit :

This looks to me like a bad practice. C string and D string are
different beasts, and we have toStringz .


C string and D string are different, but it's not a bad idea to have
string *literals* that works for both C and D strings, otherwise using
printf will lead to a bug each time the programmer forget the trailing
\0.


It is kind of dumb to create a WAT is the language because druntime dev
did mistakes. It have to be fixed.


You can't rely on an empty string to be null since you must be able to
reserve place at the end of the array, and or the string could be the
result of poping a full string.


This is why I stated put null when the string length is SET to 0, not 
when it is 0.


So it is nulled when I create an empty slice, or do arr.length = 0

Re: The more interesting question

[deadalnix]

Le 15/05/2012 18:19, Gor Gyolchanyan a écrit :



On Tue, May 15, 2012 at 7:51 PM, Christophe
mailto:trav...@phare.normalesup.org>> wrote:

using printf will lead to a bug each time the programmer forget the
trailing
\0.


First of all, printf shouldn't be used! There's writef and it's superior
to printf in any way!
Second of all, if the zero-termination of literals are to be removed,
the literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use toUTF8z
to get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of
toUTF8z to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any security
or performance flaws in this scheme.
--
Bye,
Gor Gyolchanyan.


May god ear you !

Re: SSE and AVX with D

[jerro]

On Tuesday, 15 May 2012 at 14:32:20 UTC, Pavel Umnikov wrote:
On Tuesday, 15 May 2012 at 14:28:51 UTC, Alex Rønne Petersen 
wrote:

On 15-05-2012 16:27, Pavel Umnikov wrote:

Hello everyone,

I am just recently jumped to D Language from C++ and want to 
rewrite my
current engine from scratch using this language. My math and 
physics
libraries were written utilizing many SSE functions(and AVX 
if such CPU
is presented). Can I use SSE/AVX code in D? SSE/AVX direct 
intrinsics or

Assember inlining with SSE/AVX?

Thanks!


Have a look at these:

* http://dlang.org/phobos/core_cpuid.html
* http://dlang.org/iasm.html
* http://dlang.org/simd.html


Thank you, Alex!


Note that core.simd currently only defines SSE intrinsics for
instructions of the form

INSTRUCTION xmm1, xmm2/m128

which means that instructions such as shufps are not supported.
You could take a look at gdc, which provides gcc builtins
through module gcc.builtins. To find the builtin names you can
take a look at gcc implementation of xmmintrin.h. GDC also
produces faster code than DMD, especially for floating point
code. It does not yet support AVX, though.

If you want to  use AVX for operations that don't have an
operator, currently your only choice (AFAIK) is to use LDC
and an ugly workaround that I used at
https://github.com/jerro/pfft. You write your"intrinsics"
in c and use clang to compile them to .bc (or write a .ll
file manually if you know the llvm assembly language). Then
you compile your D code with LLVM using the flags -output-bc
and -single-obj. You merge the resulting .bc file with the
"intrinsics" file using llvm-link, then optimize it using
opt and convert them to assembly using llc. Here is an
example:

https://github.com/jerro/pfft/blob/master/build-ldc2.sh

I have only tried this on linux.

Re: Request for Review: DI Generation Improvements

[Adam Wilson]

On Tue, 15 May 2012 02:51:44 -0700, kenji hara  wrote:


Old days import/core/thread.di was generated from src/core/thread.d .
Current import/core/thread.di is generated from src/core/thread.*di* .

Kenji Hara


Well, I've updated the make file to just copy thread.di instead of running  
it through the generator.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: The more interesting question

[Dmitry Olshansky]

On 15.05.2012 20:19, Gor Gyolchanyan wrote:



On Tue, May 15, 2012 at 7:51 PM, Christophe
mailto:trav...@phare.normalesup.org>> wrote:

using printf will lead to a bug each time the programmer forget the
trailing
\0.


First of all, printf shouldn't be used! There's writef and it's superior
to printf in any way!
Second of all, if the zero-termination of literals are to be removed,
the literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use toUTF8z
to get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of
toUTF8z to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any security
or performance flaws in this scheme.


Moreover compiler can do some extra string pooling iff zero termination 
goes away. Like:

"Hello World!" & "Hello" sharing the same piece of ROM.


--
Dmitry Olshansky

Re: The more interesting question

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 7:51 PM, Christophe wrote:

> using printf will lead to a bug each time the programmer forget the
> trailing
> \0.


First of all, printf shouldn't be used! There's writef and it's superior to
printf in any way!
Second of all, if the zero-termination of literals are to be removed, the
literals will no longer be accepted as a pointer to a character.
The appropriate type mismatch error will force the user to use toUTF8z to
get ht e zero-terminated utf-8 version of the original string.
In case it's a literal, one could use the compile-time version of toUTF8z
to avoid run-time overhead.
This all doesn't sound like a bad idea to me. I don't see any security or
performance flaws in this scheme.

-- 
Bye,
Gor Gyolchanyan.

Re: Windows application manifests

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 8:07 PM, Kagamin  wrote:

> Manifests are extensible resources, they are used for various things which
> require storing metadata in executable modules, for example they're used to
> load version 6 of comctl32.dll instead of version 5 (pre-XP), thus getting
> different set of common controls, which support ux themes.
>

Thanks for the reply! How do I include such a manifest to my DMD-built
executable?

-- 
Bye,
Gor Gyolchanyan.

Re: Is dsource .org completely deserted?

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:jottlr$stf$1...@digitalmars.com...
> "foobar"  wrote in message 
> news:cuucmsymdqnsrurlk...@forum.dlang.org...
>
>> Sure it doesn't support pull requests but that's the base for
>> GitHub's business model - they make money by offering useful
>> extensions on top of their hosting plans. There is no blunder
>> here, it's all very deliberate for the purpose of making money.
>> There's no point on ranting about that.
>>
>
> I'm well aware that it's deliberate, but it's still anti-competetive, 
> asinine and anachronistic. And it's not as if the whole hosting thing 
> isn't worth anything. That is, after all, what they *do*.
>

Wait, what the hell am I thinking? Even if is deliberate, and even if 
"$$$!!" did excuse everything, it *still* doesn't even make a shred of sense 
anyway: They *already* offer a free API which can be used for any of the 
different forms of interop I was suggesting. So they're *already* ok with 
all of what I suggested. Locking out interop is *not* part of their business 
model. They've just implemented that interop in a colossally dumb way, 
that's all.

Re: Windows application manifests

[Kagamin]

Manifests are extensible resources, they are used for various 
things which require storing metadata in executable modules, for 
example they're used to load version 6 of comctl32.dll instead of 
version 5 (pre-XP), thus getting different set of common 
controls, which support ux themes.

Re: The more interesting question

[Christophe]

deadalnix , dans le message (digitalmars.D:167404), a écrit :
> This looks to me like a bad practice. C string and D string are 
> different beasts, and we have toStringz .

C string and D string are different, but it's not a bad idea to have 
string *literals* that works for both C and D strings, otherwise using 
printf will lead to a bug each time the programmer forget the trailing 
\0.

> It is kind of dumb to create a WAT is the language because druntime dev 
> did mistakes. It have to be fixed.

You can't rely on an empty string to be null since you must be able to 
reserve place at the end of the array, and or the string could be the 
result of poping a full string.

Re: very strange segmentation fault interfacing a GSL-function

[Gor Gyolchanyan]

Does it crash if you just call the function with no extra multiplication?

On Tue, May 15, 2012 at 7:44 PM, Stephan  wrote:

> Hi,
>
> I am currently trying to call functions from the GNU Scientific Library
> (GSL) with my code, and I observed a very strange behaviour. The following
> test-program compiles, but generates a Segmentation fault when run.
>
>
> gsltest.d
> --
> import std.stdio;
>
> extern (C) double gsl_sf_hyperg_2F1(double a, double b, double c, double
> x);
>
> void main() {
>  double f = 0.0025;
>  // The following line causes a crash
>  auto ret = f * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - f / 0.025);
>
>  // The following line should be identical, but it does not cause the seg
> fault.
>  // auto ret = 0.0025 * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - f /
> 0.025);
>
>  writeln(ret);
> }
> ---
>
> If you comment out the crashing line and comment in the line below, the
> program runs and returns 0.015681, which is the numerically correct result.
>
> To compile and run the code, I used the following command line:
>
> rdmd -L-L/opt/local/lib -L-lgsl -L-lgslcblas gsltest.d
>
>
> I tested this on Unix and Mac OS X. Can anyone reproduce the error and
> have an idea what is going on?
>
> Cheers,
>
> Stephan
>
>


-- 
Bye,
Gor Gyolchanyan.

Re: Is dsource .org completely deserted?

[Gor Gyolchanyan]

On Tue, May 15, 2012 at 7:43 PM, Nick Sabalausky <
seewebsitetocontac...@semitwist.com> wrote:

> This is why OSS software will always be better (on average) than
> commercial:
> No managers to fuck things up.
>

This is so true! Commercial software sucks not because it costs money, but
because of being made exclusively for money.
I'm yet to see a good manager, who really knows what's good for the
product. The worst part is, that when you know, that the manager is not
doing a good job, you can't just ignore him, unless you're self-employed.


-- 
Bye,
Gor Gyolchanyan.

very strange segmentation fault interfacing a GSL-function

[Stephan]

Hi,

I am currently trying to call functions from the GNU Scientific 
Library (GSL) with my code, and I observed a very strange 
behaviour. The following test-program compiles, but generates a 
Segmentation fault when run.



gsltest.d
--
import std.stdio;

extern (C) double gsl_sf_hyperg_2F1(double a, double b, double c, 
double x);


void main() {
  double f = 0.0025;
  // The following line causes a crash
  auto ret = f * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - f / 
0.025);


  // The following line should be identical, but it does not 
cause the seg fault.
  // auto ret = 0.0025 * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - 
f / 0.025);


  writeln(ret);
}
---

If you comment out the crashing line and comment in the line 
below, the program runs and returns 0.015681, which is the 
numerically correct result.


To compile and run the code, I used the following command line:

rdmd -L-L/opt/local/lib -L-lgsl -L-lgslcblas gsltest.d


I tested this on Unix and Mac OS X. Can anyone reproduce the 
error and have an idea what is going on?


Cheers,

Stephan

Re: Is dsource .org completely deserted?

[Nick Sabalausky]

"foobar"  wrote in message 
news:cuucmsymdqnsrurlk...@forum.dlang.org...
> On Tuesday, 15 May 2012 at 02:36:25 UTC, Nick Sabalausky wrote:
>> "Kapps"  wrote in message
>> news:gvuqhcqczjqmdtpsa...@forum.dlang.org...
>>> It would be nice to make a replacement to dsource. There's a fair few 
>>> problems with it. For one, people prefer hosting their source on Github 
>>> or Bitbucket or such, it's silly to try and get people to use your own 
>>> source control hosting instead of just pointing to one of those.
>>
>> I firmly believe that GitHub/BitBucket/etc-style features need to be
>> standard *protocols*, not features bundled inseparably to project 
>> hosting.
>> What the hell is this, 1980 all over again where data is routinely tied
>> inseparably to the software it originated from?
>>
>> It makes *no* sense for GitHub/BitBucket to be designed so that:
>>
>> 1. Forking/Pull requests/etc are all isolated from other project hosting
>> providers (It's *DISTRIBUTED* fucking version control, for christsakes!),
>> and
>>
>> 2. Interfaces [very, very VERY slw and half-broken ones] are tied to 
>> the
>> project hosting site/software.
>>
>> It's like that twitface shit all over again (ie, all that "walled-off
>> sub-internets" bullshit), or those god-awful "web photo-viewer" programs,
>> but with programmers - exactly the people who *should know better*. This 
>> is
>> 2012, there's *no* excuse for software design blunders that were already
>> going out of date 30 fucking years ago.
>>
>> Of course, such anachronisms will never be reverted so long as the "cell 
>> and
>> internet generation" is still around...
>>
>
> There *is* such a protocol - it's called Git.

Right, I agree, but these days, Git (or Hg) is essentially only a half-VCS 
without such things. And Git and Hg don't have such things.

> Sure it doesn't support pull requests but that's the base for
> GitHub's business model - they make money by offering useful
> extensions on top of their hosting plans. There is no blunder
> here, it's all very deliberate for the purpose of making money.
> There's no point on ranting about that.
>

I'm well aware that it's deliberate, but it's still anti-competetive, 
asinine and anachronistic. And it's not as if the whole hosting thing isn't 
worth anything. That is, after all, what they *do*.

People have this bizarre idea that the pursuit of $$$ automatically excuses 
anything and everything. "WTF, that's terrible!" "No, it's ok: They're 
making $$$ off of it!" "Oh, ok then! If they're making $$$!"

This is why OSS software will always be better (on average) than commercial: 
No managers to fuck things up.

Re: deprecating std.stream, std.cstream, std.socketstream

[Lars T. Kyllingstad]

On Tuesday, 15 May 2012 at 15:22:03 UTC, Lars T. Kyllingstad 
wrote:

On Tuesday, 15 May 2012 at 02:56:20 UTC, Walter Bright wrote:

On 5/14/2012 8:02 AM, Steven Schveighoffer wrote:
I keep trying to avoid talking about this, because I'm 
writing a replacement
library for std.stream, and I don't want to step on any toes 
while it's still

not accepted.

But I have to say, ranges are *not* a good interface for 
generic data providers.

They are *very* good for structured data providers.

In other words, a stream of bytes, not a good range (who 
wants to get one byte
at a time?). A stream of UTF text broken into lines, a very 
good range.


[...]


I'll say in advance without seeing your design that it'll be a 
tough sell if it is not range based.


I've been doing some range based work on the side. I'm 
convinced there is enormous potential there, despite numerous 
shortcomings with them I ran across in Phobos. Those 
shortcomings can be fixed, they are not fatal.


[...]


I have to say, I'm with Steve on this one.  While I do believe
ranges will have a very important role to play in D's future I/O
paradigm, I also think there needs to be a layer beneath the
ranges that more directly maps to OS primitives.  And as D is a
systems programming language, that layer needs to be publicly
available.  (Note that this is how std.stdio works now, more or
less.)


Also, I wouldn't mind std.*stream getting deprecated.  
Personally, I've never used those modules -- not even once.  As a 
first step their documentation could be removed from dlang.org, 
so new users aren't tempted to start using them.  No 
functionality is better than poor functionality, IMO.


-Lars

Re: Return by 'ref' problems...

[Manu]

On 15 May 2012 16:28, Andrei Alexandrescu wrote:

> On 5/15/12 8:16 AM, Manu wrote:
>
>> Okay, here's another problem due to ref not being a type constructor.
>> If I have some function that receives an argument by ref, and then I
>> take parameterTypeTuple! of that functions parameter list, the ref bits
>> are gone from the typetuple.
>> If I give that tuple as a template arg, then the template parameters no
>> longer match the function it's wrapping...
>>
>
> Correct. That means there needs to be an additional trait that tells which
> parameters of a function are ref.
>

This just creates a mess, and lots of redundant work. Now, rather than
simply:
  template myTemplate(T...) {}
  myTemplate!(parameterTypeTuple!func)

I need to jump through a whole bunch of hoops to reconstruct an argument
list that actually represents the function args.
I'm CONSTANTLY working around this, I have a file approaching 1000 loc just
full of these sorts of workarounds given different situations.
Most of which elevate the problem beyond a simple template arg to a full
blown string mixin where I have to start coding in between quotes, and with
~ as every second token.


I'm still thinking more and more that there's no solution to all the
>> problems with ref, other than changing it to use the syntax: ref(type),
>> and be a type constructor, like const/immutable/shared/etc...
>> I have problems with ref almost every day. If not in templates, in
>> function/delegate definitions, and the prior issues previously discussed..
>>
>>
>> No matter how I look at it, 'ref' really should be a type constructor.
>>
>
> Ref on a parameter or the return value is a property of the function, not
> a property of the parameter.


I can't agree with that. Whether a parameter is a size_t pointer, or a 10kb
struct is absolutely a property of the parameter. The data actually being
passed is fundamentally different (size_t or buffer), the local storage
mechanism for that data is fundamentally different, it affects the ABI,
interaction with other languages is affected.

Additionally, ref shouldn't only be for function parameters. This is the
source of a bunch more problems.

ref T func();
auto r = func(); <-- r is not a ref. D can't express local references, but
it needs to in many cases.

This is also extremely common in loops to reduce code noise and clutter;
improve readability.

I listed a bunch of problem cases with ref in another thread (thought it
was this one), they would all be solved instantly (and intuitively) if
ref(T) were a type constructor.


The use of 'ref' fundamentally changes the variable from T to T*, that's
>> a critical difference, and can't just be lost when taking the typeof
>> something.
>>
>
> Ref int is not int*


Well... it is and it isn't. It's a pointer with some usage/syntactical
tweaks; must be assigned on declaration, suppress pointer assignment syntax
(enabling regular objective assignment) + arithmetic/indexing suppressed,
etc.


Ref fundamentally dictates how the parameter binds to the argument;
> otherwise, it doesn't affect the behavior of the parameter's type itself.
>

I can see this point, but I don't know if that breaks my argument. Ie. this
isn't a problem, and there are so many real issues with the existing
implementation.


To lift this one level up, what problem are you trying to solve?


1. I can't 'cut and paste' arguments/argument lists from functions to
templates; the ref properties are lost. Leads to bloat, workarounds and
inevitable string mixins.
2. auto doesn't work with ref return values.
3. Syntax is obscure and confused, how to I pass a reference to a function
that returns a ref? Intuitive solution: void func( ref(ref(T) function())
fp )
4. I want to use ref anywhere: ref return values need to assign to ref
locals, loops frequently create a ref as a resolution of a complex lookup
expression for each iteration of the loop, etc.

Right now, the problem is that template args do not transfer the ref-ness
of a given argument; it is an important detail of the type that must be
conveyed.


Perhaps you can clarify why it was done this way; ie, intentionally break
the mould of existing familiar (and perfectly good) implementation like C++
and C#? (C# being a great example of a modern implementation)
There must be some advantages the current implementation offers? I can only
see losses of functionality.

Re: deprecating std.stream, std.cstream, std.socketstream

[Lars T. Kyllingstad]

On Tuesday, 15 May 2012 at 02:56:20 UTC, Walter Bright wrote:

On 5/14/2012 8:02 AM, Steven Schveighoffer wrote:
I keep trying to avoid talking about this, because I'm writing 
a replacement
library for std.stream, and I don't want to step on any toes 
while it's still

not accepted.

But I have to say, ranges are *not* a good interface for 
generic data providers.

They are *very* good for structured data providers.

In other words, a stream of bytes, not a good range (who wants 
to get one byte
at a time?). A stream of UTF text broken into lines, a very 
good range.


[...]


I'll say in advance without seeing your design that it'll be a 
tough sell if it is not range based.


I've been doing some range based work on the side. I'm 
convinced there is enormous potential there, despite numerous 
shortcomings with them I ran across in Phobos. Those 
shortcomings can be fixed, they are not fatal.


[...]


I have to say, I'm with Steve on this one.  While I do believe
ranges will have a very important role to play in D's future I/O
paradigm, I also think there needs to be a layer beneath the
ranges that more directly maps to OS primitives.  And as D is a
systems programming language, that layer needs to be publicly
available.  (Note that this is how std.stdio works now, more or
less.)

-Lars

Re: Getting the const-correctness of Object sorted once and for all

[Stewart Gordon]

On 14/05/2012 18:08, Tove wrote:


class Outer
{
  int i = 6; // mutable

  class Inner {
int y=0;

int foo() const
{
  // ++y; // fail
  return ++i; // look ma, mutable const
}
  }
  Inner inner;
  this()
  {
inner = new Inner;
  }
  alias inner this;
}


Indeed, you've found a hole in the const system nobody seems to have noticed 
before!

Inner.foo is const, so from foo's point of view, Inner.outer needs to be.

To expand your example a bit:
--
import std.stdio;

class Outer {
int i = 6;

class Inner {
int y=0;

int foo() const {
pragma(msg, "this.outer: " ~ typeof(this.outer).stringof);
pragma(msg, "i:  " ~ typeof(i).stringof);
return ++i;
}
}
Inner inner;
this() {
inner = new Inner;
}
}

void main() {
const(Outer) x = new Outer;
pragma(msg, "x:  " ~ typeof(x).stringof);
pragma(msg, "x.inner:" ~ typeof(x.inner).stringof);
x.inner.foo();
writeln(x.i);
}
--
C:\Users\Stewart\Documents\Programming\D\Tests>dmd inner_const.d
this.outer: const(Outer)
i:  const(int)
x:  const(Outer)
x.inner:const(Inner)
--

but nonetheless, it allows i to be modified!

http://d.puremagic.com/issues/show_bug.cgi?id=8098

Stewart.

Re: SSE and AVX with D

[Pavel Umnikov]

On Tuesday, 15 May 2012 at 14:28:51 UTC, Alex Rønne Petersen 
wrote:

On 15-05-2012 16:27, Pavel Umnikov wrote:

Hello everyone,

I am just recently jumped to D Language from C++ and want to 
rewrite my
current engine from scratch using this language. My math and 
physics
libraries were written utilizing many SSE functions(and AVX if 
such CPU
is presented). Can I use SSE/AVX code in D? SSE/AVX direct 
intrinsics or

Assember inlining with SSE/AVX?

Thanks!


Have a look at these:

* http://dlang.org/phobos/core_cpuid.html
* http://dlang.org/iasm.html
* http://dlang.org/simd.html


Thank you, Alex!

Re: SSE and AVX with D

[Alex Rønne Petersen]

On 15-05-2012 16:27, Pavel Umnikov wrote:

Hello everyone,

I am just recently jumped to D Language from C++ and want to rewrite my
current engine from scratch using this language. My math and physics
libraries were written utilizing many SSE functions(and AVX if such CPU
is presented). Can I use SSE/AVX code in D? SSE/AVX direct intrinsics or
Assember inlining with SSE/AVX?

Thanks!


Have a look at these:

* http://dlang.org/phobos/core_cpuid.html
* http://dlang.org/iasm.html
* http://dlang.org/simd.html

--
- Alex