Re: Implementing Pure Functions

[Kagamin]

Andrei Alexandrescu Wrote:

> This has sparked an interesting discussion, to which I added my bit.

int fun(int a) pure { if (a > 10) writeln("I'm impure); }

As I understand, even if some calls to a function have some repeatability 
properties, this doesn't mean the function is pure. In this example fun is 
obviously impure. Here one can talk about allowing to call impure functions 
from pure ones, but that's a way different task.

Re: TempAlloc Overhaul

[Andrei Alexandrescu]

On 6/11/11 11:26 AM, dsimcha wrote:

I've overhauled my TempAlloc proposal based on some of the suggestions
I've received.


Review:

* Mention no safety at disadvantages: deallocating memory may leave 
pointers dangling.


* The synopsis should use scope(exit) TempAlloc.frameFree(); as that is 
a robust idiom.


* newArray -> "For performance reasons, the returned array is not 
initialized." Then call it newUninitializedArray. Make safety the 
default and lack thereof the verbose alternative.


* newArray -> "It is not scanned for pointers by the garbage collector 
unless GC.addRange is called." I'd agree that malloc() shouldn't do so 
because it doesn't know the type, but with newArray you do know the type 
so you could automatically call GC.addRange appropriately. If the client 
doesn't want that, they can obtain it with extra syntax. Since now you 
have two things (uninitialized and noscan) you may want to make them 
function parameters instead of part of the function name.


* I'm a bit unsure about free(). People already have the pointer, so 
free() should use it as a cheap way to check that they're freeing the 
right thing. There should be free(void*), freeLastAllocated(), and 
possibly destroyAndFree(T)(T *).


* segmentSlack() -> segmentAvailable().

* stackCat() is a bit surprising. A better way would be something like a 
TempAlloc appender that accepts a chain().


* In fact looking at tempArray() just below that's all - it can accept 
chain(). No need for stackCat.


* mixin newFrame should be renamed to scopedFrame.


Andrei

Issue 6169

[bearophile]

Pure functions in D keep producing new and new ideas. There are some 
purity-related ideas yet to be implemented, but (I think) accepted by Walter, 
like allowing an implicit cast to const of the result of a strongly pure 
function, or generating an error if you don't assign the result of a strongly 
pure function to a variable. And there is my not so much appreciated idea of 
the @transparent too (and maybe there are other ideas I don't remember at the 
moment).

A new idea has just appeared in Bugzilla, by Timon Gehr:
http://d.puremagic.com/issues/show_bug.cgi?id=6169

It asks to allow code like this too, where a pure function calls a impure one 
and assigns the result with enum:

int x = 10;
int foo(bool b) {
if (b)
x++;
return 0;
}
pure void main() {
enum y = foo(false);
}


After thinking some about it, I think it's acceptable. See my comment in the 
bug report for more info.

Bye,
bearophile

Re: Article discussing Go, could well be D

[Andrei Alexandrescu]

On 6/16/11 4:19 PM, Jacob Carlborg wrote:

I'm already working on a package management tool for D.


Excellent. Suggestion: at the risk of getting flooded with suggestions, 
post your design early and often.


Andrei

Re: SSE asm with functions

[Walter Bright]

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

Re: Article discussing Go, could well be D

[Jacob Carlborg]

On 2011-06-10 20:00, Andrew Wiley wrote:

On Fri, Jun 10, 2011 at 9:29 AM, Caligo mailto:iteronve...@gmail.com>> wrote:

On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>> wrote:
 > That's it. We need a package management expert on board to either
revive
 > dsss or another similar project, or define a new package manager
altogether.
 > No "yeah I have some code somewhere feel free to copy from it";
we need
 > professional execution. Then we need to make that tool part of
the standard
 > distribution such that library discovery, installation, and
management is as
 > easy as running a command.
 >
 > I'm putting this up for grabs. It's an important project of high
impact.
 > Wondering what you could do to help D? Take this to completion.
 >
 >
 > Andrei
 >

Andrei, I have to respectfully disagree with you on that, sorry.

D is supposed to be a system programming language, not some scripting
language like Ruby.  Besides, the idea of some kind of package
management for a programming language is one of the worst ideas ever,
specially when it's a system programming language.  You have no idea
how much pain and suffering it's going to cause the OS developers and
package maintainers.  I can see how the idea might be attractive to
non-*nix users, but most other *nix OSs have some kind of package
management system and searching for, installing, and managing software
is as easy as running a command.

It doesn't have to be hard if you build the package manager in such a
way that it can be integrated into the OS package manager, whether that
means letting the OS package manager modify the language package
manager's database or just adding a switch that turns your package
manager into a dumb build tool so dependency checks can be left to the
OS package manager. That's my theory, anyway.


Windows doesn't have a OS package and Mac OS X doesn't have one out of 
the box. Only on Linux there are several package managers to integrate 
with, seems to be a lot of work. I think it's easier to build a custom, 
specific for D.


--
/Jacob Carlborg

Re: SSE asm with functions

[Walter Bright]

On 6/16/2011 10:20 AM, Byron wrote:

I reduced the complexity of the problem, seems to be SSE and returning local 
copies.


What you've run into is the "named return value" optimization. 'r' is rewritten 
by the compiler as a reference to a vector in the caller's stack frame, this 
avoids unnecessary copying when returning r.


The trouble is, the inline assembler does no such rewrites.

I'll file this in bugzilla. In the meantime, you've already discovered the 
workaround in test2().

Re: Article discussing Go, could well be D

[Jacob Carlborg]

On 2011-06-09 01:06, Andrei Alexandrescu wrote:

On 6/8/11 4:38 PM, Brad Anderson wrote:

On Wed, Jun 8, 2011 at 12:46 AM, Lars T. Kyllingstad
 wrote:

http://www.reddit.com/r/programming/comments/hudvd/
the_go_programming_language_or_why_all_clike/

The author presents a "wish list" for his perfect systems programming
language, and claims that Go is the only one (somewhat) fulfilling it.
With the exception of item 7, the list could well be an
advertisement for
D.

-Lars


I found the comments on the Hacker News post
 about this article more
interesting.

Regards,
Brad Anderson


Agreed. The top poster does repeat a point made by others: D does fail
on point 7. Allow me to paste it:

=
7. Module Library and Repository
I want all the niceties I have grown used to in scripting languages
built-in or part of the standard library. A public package repository
with a decent portable package manager is even better. Typical packages
include internet protocols, parsing of common syntaxes, GUI, crypto,
common mathematical algorithms, data processing and so on. (Example:
Perl 5 CPAN)
=

That's it. We need a package management expert on board to either revive
dsss or another similar project, or define a new package manager
altogether. No "yeah I have some code somewhere feel free to copy from
it"; we need professional execution. Then we need to make that tool part
of the standard distribution such that library discovery, installation,
and management is as easy as running a command.

I'm putting this up for grabs. It's an important project of high impact.
Wondering what you could do to help D? Take this to completion.


Andrei


I'm already working on a package management tool for D.

--
/Jacob Carlborg

Re: Article discussing Go, could well be D

[Jacob Carlborg]

On 2011-06-11 09:28, Nick Sabalausky wrote:

"Andrei Alexandrescu"  wrote in message
news:isu8vs$d2f$1...@digitalmars.com...

On 6/10/11 6:14 PM, Nick Sabalausky wrote:

"Andrei Alexandrescu"   wrote in message
news:isovj2$2133$1...@digitalmars.com...


That's it. We need a package management expert on board to either revive
dsss or another similar project, or define a new package manager
altogether. No "yeah I have some code somewhere feel free to copy from
it"; we need professional execution. Then we need to make that tool part
of the standard distribution such that library discovery, installation,
and management is as easy as running a command.

I'm putting this up for grabs. It's an important project of high impact.
Wondering what you could do to help D? Take this to completion.



Just a thought: DVM is already set up to handle managing multiple
versions
of DMD. And I don't think it's a stretch to figure that support for GDC
and
LDC would be natural extensions at some point, plus some dmd.conf/sc.ini
management functionality (which would be needed for installing D
libraries).
So maybe DVM could be expanded to handle arbitrary D packages as well?


I think that's an excellent idea. Jacob, would you be interested in
working on that?



If he isn't interested and no one else wants to jump in, then I'd be willing
to volunteer for it. I'm already familiar with DVM's internals from doing
the Windows port.

Or maybe Andrew Wiley would want to be involved. He did say that he hoped to
turn his xfbuild-like tool into a DSSS replacement. Might be good not to
duplicate efforts.



See my reply to Andrei.

--
/Jacob Carlborg

Re: Article discussing Go, could well be D

[Jacob Carlborg]

On 2011-06-11 01:18, Andrei Alexandrescu wrote:

On 6/10/11 6:14 PM, Nick Sabalausky wrote:

"Andrei Alexandrescu" wrote in message
news:isovj2$2133$1...@digitalmars.com...


That's it. We need a package management expert on board to either revive
dsss or another similar project, or define a new package manager
altogether. No "yeah I have some code somewhere feel free to copy from
it"; we need professional execution. Then we need to make that tool part
of the standard distribution such that library discovery, installation,
and management is as easy as running a command.

I'm putting this up for grabs. It's an important project of high impact.
Wondering what you could do to help D? Take this to completion.



Just a thought: DVM is already set up to handle managing multiple
versions
of DMD. And I don't think it's a stretch to figure that support for
GDC and
LDC would be natural extensions at some point, plus some dmd.conf/sc.ini
management functionality (which would be needed for installing D
libraries).
So maybe DVM could be expanded to handle arbitrary D packages as well?


I think that's an excellent idea. Jacob, would you be interested in
working on that?

Andrei


I'm already working on another tool for handling D packages,
DVM will never be able to do that. To elaborate, I'm building this tool 
(and later rebuilding DVM) as a library with a thin wrapper consisting 
of the command line interface. So they could be build into one single 
tool (from the users point of view) if people would want this.


--
/Jacob Carlborg

Re: Implementing Pure Functions

[Walter Bright]

On 6/16/2011 6:29 AM, Don wrote:

bearophile wrote:

Walter:


Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski
for their helpful comments and corrections on this post.<


*pulls Walter's ears* You have forgotten who has found this problem :-)


So have I. It was mentioned at the start of 2008 with respect to pure, but the
same problem was mentioned with regard to CTFE much earlier, in 2006 I think. I
think Daniel Keep was the first to mention it.


The acknowledgments did not attempt to credit where the idea came from, just the 
people who made comments on a draft of that post.


This thread is particularly relevant:

http://www.digitalmars.com/d/archives/digitalmars/D/Temporarily_disable_all_purity_for_debug_prints_134460.html

As for the problem, which is doing I/O in a pure function, that goes back 
decades.

Re: Rename std.ctype to std.ascii?

[Jonathan M Davis]

On 2011-06-16 12:51, Jouko Koski wrote:
> "Jonathan M Davis"  wrote:
> > On 2011-06-14 11:53, Jouko Koski wrote:
> >> I would not consider it being good idea to include this kind of
> >> ascii-only
> >> utilities in the standard-ish library.
> > 
> > For some classes of operations, it makes perfect sense to be checking for
> > ASCII characters only. For others, it's just people not worrying about
> > internationalization like they should be. For instance, format strings
> > don't
> > care about unicode as far as their escape sequences go. %a, %d, etc. are
> > all
> > pure ASCII.
> 
> Do we really need a common library utility for such a bounded domain? I
> would vote dropping ascii-only std.ctype altogether. Those who know and
> ensure that they are dealing with ascii-only, ebcdic-only or whatever-only
> representations can easily write their own utilities to their particular
> domains - maybe even better optimized than std.ctype because the domain may
> be even more restricted. A common use ascii-only utility will be used
> inevitably in places where it shouldn't.
> 
> > std.ctype/std.ascii deals with ASCII for those situations where you
> > really do
> > only care about ASCII. It deals with unicode characters, but it returns
> > false
> > for everything with them which returns a bool, and it never tries to
> > change
> > their case. std.uni actually deals with unicode and worries about things
> > like
> > whether a unicode character is uppercase or not.
> 
> That is what  (or ) utilities do when the default locale
> setting is in effect. Some other posters seem to suggest that a more
> generalized library module does this, too, without losing performance. 

You actually do get a performance loss for a number of functions. They do tend 
to shortcut on ASCII in many cases, but they tend to become too large to be 
inlined, and if all you care about is ASCII, even if there are unicode 
characters in the string (which is common enough in domains that have nothing 
to do with English - e.g. regular expressions), you take a performance hit for 
all characters which aren't ASCII. There are also a number of functions which 
arguably don't make much sense to try and turn into unicode functions (e.g. 
isDigit) but are heavily used. Another fun one is isWhite vs isUniWhite. In 
most cases, you _don't_ care about unicode whitespace, and it is definitely 
more expensive to call isUniWhite than isWhite, because there are a _lot_ of 
extraneous whitespace characters in unicode.

std.ctype/std.ascii is _not_ going away. Too many people find those functions 
to be useful. I grant you that too many programmers don't worry about unicode 
when they should, but there are so many issues surrounding the proper handling 
of unicode that programmers aren't going to get it right unless they're 
actully trying to get it right. D provides a lot of the tools to make unicode 
mostly work correctly out of the box, but it's still complicated enough that 
you can't expect it to "just work" without programmers having some clue of 
what they're doing. And forcing people to come up with their own functions for 
basic ASCII operations (which pretty much every other programming language 
has) isn't going to help any.

- Jonathan M Davis

Re: Rename std.string.toStringz?

[Jonathan M Davis]

On 2011-06-16 12:16, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > stringz is neither a type nor a word.
> 
> It *is* a word. A stringz is a string that ends in zero. This
> family of traditional names (STRINGZ, ASCIZ, etc.) predates C itself.
> 
> On the other hand, there is *no such thing* as a StringZ. You'd
> never call it a "string zero". You'd call it a "zero terminated
> string", or maybe a "C string".
> 
> Changing it to "toCString" is completely pointless, a cost without
> a benefit, but at least it's not a completely nonsensical name like
> toStringZ.

Well, I'd argue that stringz is just as nonsensical as stringZ. I have _never_ 
heard the term stringz used outside of D. Searching for it online brings up 
_nothing_ (not even D). And I wouldn't really consider an identifier which is 
completely uppercase to necessarily say anything about where the beginning and 
end of a word is anyway, so I wouldn't really consider that much of a 
precedent. But it doesn't really matter.

What matters is whether we as a group think that renaming toStringz is 
worthwhile, and if so, what we name it to. _No one_ thus far has liked the 
name toStringZ, even if they agree that toStringz should be changed. They're 
pretty much all voting for toCString. So, there's no way that it's going to 
end up as toStringZ.

I'm going to let this thread go a bit longer before I decide what I'm going to 
do, but from the looks of it, we're not reaching any kind of consensus on 
this, and I'm not going to change toStringz unless we actually reach a 
consensus on the matter.

The discussions on fixing the function names in Phobos (and in particular, 
std.string) resulted in an almost unanimous decision to fix the function names 
in Phobos to be properly camelcased. So, in general, it's worth making those 
changes. However, this particular discussion about this particular function is 
anything but unanimous, so unless a greater agreement is reached than is 
currently happening, toStringz isn't going to be changed.

- Jonathan M Davis

Re: Rename std.ctype to std.ascii?

[Jouko Koski]

"Jonathan M Davis"  wrote:

On 2011-06-14 11:53, Jouko Koski wrote:


I would not consider it being good idea to include this kind of 
ascii-only

utilities in the standard-ish library.



For some classes of operations, it makes perfect sense to be checking for
ASCII characters only. For others, it's just people not worrying about
internationalization like they should be. For instance, format strings 
don't
care about unicode as far as their escape sequences go. %a, %d, etc. are 
all

pure ASCII.


Do we really need a common library utility for such a bounded domain? I 
would vote dropping ascii-only std.ctype altogether. Those who know and 
ensure that they are dealing with ascii-only, ebcdic-only or whatever-only 
representations can easily write their own utilities to their particular 
domains - maybe even better optimized than std.ctype because the domain may 
be even more restricted. A common use ascii-only utility will be used 
inevitably in places where it shouldn't.


std.ctype/std.ascii deals with ASCII for those situations where you really 
do
only care about ASCII. It deals with unicode characters, but it returns 
false
for everything with them which returns a bool, and it never tries to 
change
their case. std.uni actually deals with unicode and worries about things 
like

whether a unicode character is uppercase or not.


That is what  (or ) utilities do when the default locale 
setting is in effect. Some other posters seem to suggest that a more 
generalized library module does this, too, without losing performance.


--
Jouko 

Re: Rename std.string.toStringz?

[Adam D. Ruppe]

Jonathan M Davis wrote:
> stringz is neither a type nor a word.

It *is* a word. A stringz is a string that ends in zero. This
family of traditional names (STRINGZ, ASCIZ, etc.) predates C itself.

On the other hand, there is *no such thing* as a StringZ. You'd
never call it a "string zero". You'd call it a "zero terminated
string", or maybe a "C string".

Changing it to "toCString" is completely pointless, a cost without
a benefit, but at least it's not a completely nonsensical name like
toStringZ.

Re: Rename std.string.toStringz?

[Daniel Gibson]

Am 16.06.2011 20:30, schrieb Kagamin:
> Daniel Gibson Wrote:
> 
 So c_long converts a long to a c-long?
 (Is this a D function/type? I couldn't find it on the homepage)
>>>
>>> It's not a conversion function, but an alias. It's declared, along with
>>> c_ulong, in core.stdc.config.
>>
>> So it has nothing to do with toStringz and similar names would be confusing.
> 
> May be
> 
> struct c_str{}
> to!c_str();

No.
The whole point of toStringz() is that it returns a string that can be
fed to normal C functions that work on strings.
And C functions expect a "string" to be a char* (or wchar*) pointing to
a block of memory containing the string and terminated by '\0'.
The functionality of toStringz() should not change.
This is just about the name.

Cheers,
- Daniel

Re: Rename std.string.toStringz?

[Andrej Mitrovic]

It would be cool if with each release we distributed a tool that can
at least do partial renaming of old function names to new ones. This
should ease porting a codebase to a new version of DMD/Phobos. Think
about how Python has the 2to3 tool, except our tool might just do a
minimal search & replace between two small versions.

Re: Implementing Pure Functions

[Walter Bright]

On 6/16/2011 5:27 AM, Kagamin wrote:

Jimmy Cao Wrote:


pure int square(int x)
{
auto fp = cast(fp_t)&square_debug;
return (*fp)(x); // dereference???
}



Yes, that's correct.


You mean, implementation-defined?


It's typed as pointing to a pure function. So, it's callable from a pure 
function.

Re: Rename std.string.toStringz?

[Jonathan M Davis]

On 2011-06-16 10:44, Paul D. Anderson wrote:
> Jonathan M Davis Wrote:
> > 1. Keep toStringz as it is (as well as toUTF16z) and either consider
> > stringz to be some sort of word unique to the D community or just admit
> > that we're not going to camelcase it because it would break too much
> > code to do so.
> 
> vote++.
> 
> 1) If it ain't broke, don't fix it. Too much disruption for too little
> gain.
> 
> 2) In a language that uses "enum" to mean "manifest constant", worrying
> about an upper or lower case z is straining at a gnat and swallowing a
> camel.

It has been made pretty clear in discussions in this group before that in the 
general case, the consensus is that we want Phobos' function names to 
consistently follow Phobos' naming conventions (which means camelcased 
starting with a lowercase letter in the case of functions), even if it means 
breaking code in the short run in order to fix it. So, following that, if 
toStringz isn't properly camelcased (and I really don't understand anyone who 
thinks that it is), then it should be renamed. Whether it's the biggest 
problem in the language or library or not is irrelevant. Based on past 
discussions in this group, one would think that most people would want 
toStringz to be changed to be properly camelcased.

However, it _is_ a function which is used a _lot_ and changing it will break a 
lot of code, so if we change the name, it needs to be worth doing so. I'm just 
trying to find out if the community at large thinks that it's worth changing 
toStringz to be properly camelcased given the cost, and if so, whether it's 
best to just camelcase it properly (toStringZ) or to rename it entirely. It's 
clear that in the general case, the community believes that it's worth it. The 
question is whether they believe that it's worth it in this particular case. I 
don't find whether there are other, bigger issues in the language or library 
to be particularly relevant unless they affect this particular issue.

- Jonathan M Davis

Re: Rename std.string.toStringz?

[Kagamin]

Daniel Gibson Wrote:

> >> So c_long converts a long to a c-long?
> >> (Is this a D function/type? I couldn't find it on the homepage)
> > 
> > It's not a conversion function, but an alias. It's declared, along with
> > c_ulong, in core.stdc.config.
> 
> So it has nothing to do with toStringz and similar names would be confusing.

May be

struct c_str{}
to!c_str();

Re: SSE asm with functions

[Byron]

Same problem with 64-bit dmd on ubuntu. ( change EAX to RAX )

Re: Rename std.string.toStringz?

[Kagamin]

Daniel Gibson Wrote:

> > It's not a conversion function, but an alias. It's declared, along with
> > c_ulong, in core.stdc.config.
> 
> So it has nothing to do with toStringz and similar names would be confusing.

Not for c++ people.

Re: Rename std.string.toStringz?

[Dmitry Olshansky]

On 16.06.2011 20:07, KennyTM~ wrote:

On Jun 16, 11 23:09, Regan Heath wrote:
On Thu, 16 Jun 2011 13:00:23 +0100, Timon Gehr  
wrote:



Daniel Gibson wrote:

Am 16.06.2011 08:30, schrieb Jonathan M Davis:



3. Rename it to toCString (probably renaming toUTF16z to something 
like

toWCString), so it's then more recognizable to newbies


This + keep around aliases for the old names until D3.


+1


+1. But make it 'toCWString'. :o)


Or toWString (looks nicer to me).



A potential problem is that an immutable(wchar)[] is wstring.


Or toCStr and toWStr (to save 3 characters on each).

winnt.h defines many similar types:

typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
typedef __nullterminated PWSTR *PZPWSTR;
typedef __nullterminated CONST PWSTR *PCZPWSTR;
typedef __nullterminated WCHAR UNALIGNED *LPUWSTR, *PUWSTR;
typedef __nullterminated CONST WCHAR *LPCWSTR, *PCWSTR;
typedef __nullterminated PCWSTR *PZPCWSTR;
typedef __nullterminated CONST WCHAR UNALIGNED *LPCUWSTR, *PCUWSTR;

so variations on any of those make sense.

.. I think the toStringz probably came from the winnt.h defines using 
z..


typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;
typedef __nullterminated PSTR *PZPSTR;
typedef __nullterminated CONST PSTR *PCZPSTR;
typedef __nullterminated CONST CHAR *LPCSTR, *PCSTR;
typedef __nullterminated PCSTR *PZPCSTR;



Stringz means "Z"ero-terminated "String". The usage predates Windows NT.


I suspect it's original name was Z-string and indeed it's usage started 
much earlier (e.g. it was used in PC BIOS).
To be more precise there was notation for ACSII string that comes form 
having two types of strings:

L-string  - Length is in first byte (so up 255 characters)
Z-string - Zero byte at the end. (or ASCIIZ)

Anyway I could live with any of  toStringz, toZString, toStringZ, toCString.

--
Dmitry Olshansky

Re: Rename std.string.toStringz?

[Lars T. Kyllingstad]

On Thu, 16 Jun 2011 13:44:07 -0400, Paul D. Anderson wrote:

> 2) In a language that uses "enum" to mean "manifest constant", worrying
> about an upper or lower case z is straining at a gnat and swallowing a
> camel.

:D

Re: Rename std.string.toStringz?

[Paul D. Anderson]

Jonathan M Davis Wrote:

> 
> 1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz 
> to be some sort of word unique to the D community or just admit that we're 
> not 
> going to camelcase it because it would break too much code to do so.
> 

vote++.

1) If it ain't broke, don't fix it. Too much disruption for too little gain.

2) In a language that uses "enum" to mean "manifest constant", worrying about 
an upper or lower case z is straining at a gnat and swallowing a camel.

Paul

Re: SSE asm with functions

[Byron]

I reduced the complexity of the problem, seems to be SSE and returning local 
copies.

$ dmd -run db.d
v: [1, 2, 3, 4]
test1 r: [nan, nan, nan, nan]
test1: [nan, nan, nan, nan]
test2 r: [1, 2, 3, 4]
test2: [1, 2, 3, 4]
halle109-251:asm byro


//db.d
import std.stdio;

alias float[4] vector;

const(vector) test1( ref const(vector) v )
{
vector r;
asm
{
mov EAX, v;
movups XMM0, [EAX];
movups r, XMM0;
}
writeln( "test1 r: ", r );
return r;
}

const(vector) test2( ref const(vector) v )
{
vector r, s;
asm
{
mov EAX, v;
movups XMM0, [EAX];
movups r, XMM0;
}
writeln( "test2 r: ", r );
s = r;
return s;
}

void main()
{
vector v = [1,2,3,4];
writeln( "v: ", v );
writeln( "test1: ", test1(v));
writeln( "test2: ", test2(v));
}


-Byron
begin 644 db.d
M:6UP;W)T('-T9"YS=&1I;SL*"F%L:6%S(&9L;V%T6S1=('9E8W1OPH@("`@("`@(&UO=B!%05@L('8[
M"B`@("`@("`@;6]V=7!S(%A-33`L(%M%05A=.PH@("`@("`@(&UO=G5PPH@("`@=F5C=&]R('(L(',["B`@("!A

Re: Rename std.string.toStringz?

[Jonathan M Davis]

On 2011-06-16 09:21, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > I'm afraid that I don't understand this view at all, given that
> > string is a word and stringz isn't, though there are a few people
> > that have expressed this view now.
> 
> If we had a function for to!ulong in this style, would you call it
> toULong or toUlong?
> 
> I'd expect the latter - the word is "ulong", a single unit,
> not "U Long".
> 
> D1 also did it this way:
> http://digitalmars.com/d/1.0/phobos/std_conv.html

I'd probably end up calling it to ULong, since U stands for unsigned and it 
looks a lot better that way, but since ulong is a type name, I could easily 
see it being named toUlong.

However, I don't see what that has to do with toStringz. stringz is neither a 
type nor a word. The _only_ place that stringz is used AFAIK is in the name 
toStringz, where the zero presumably stands for zero, as in zero-terminated 
string. If stringz were a type in D, then yeah, toStringz would be properly 
camelcased, but stringz isn't a type.

- Jonathan M Davis

Re: Implementing Pure Functions

[bearophile]

Andrei:

> This has sparked an interesting discussion, to which I added my bit.

In D I suggest version(none){} to disable some code :-)

Bye,
bearophile

Re: unitest problem

[Robert Clipsham]

On 16/06/2011 06:56, Lloyd Dupont wrote:

I'm using VisualD with DMD 2.053 on Windows 7 x64
I am building a static library and an exe, both in D, both with unitest
turned on.
the executable link with the library and use a module in the library
which contains unitests
yet, when Irun it, only the unit test in the exe are running, no
unittest in the library are!
is that a known bug? or just me? or something else?


I believe you have to reference something from each module for the 
unittests to be run. I don't know if this changed or not though, perhaps 
someone else could say.


--
Robert
http://octarineparrot.com/

Re: Rename std.string.toStringz?

[Adam D. Ruppe]

Jonathan M Davis  wrote:
> I'm afraid that I don't understand this view at all, given that
> string is a word and stringz isn't, though there are a few people
> that have expressed this view now.

If we had a function for to!ulong in this style, would you call it
toULong or toUlong?

I'd expect the latter - the word is "ulong", a single unit,
not "U Long".

D1 also did it this way:
http://digitalmars.com/d/1.0/phobos/std_conv.html

Re: Rename std.string.toStringz?

[KennyTM~]

On Jun 16, 11 23:09, Regan Heath wrote:

On Thu, 16 Jun 2011 13:00:23 +0100, Timon Gehr  wrote:


Daniel Gibson wrote:

Am 16.06.2011 08:30, schrieb Jonathan M Davis:



3. Rename it to toCString (probably renaming toUTF16z to something like
toWCString), so it's then more recognizable to newbies


This + keep around aliases for the old names until D3.


+1


+1. But make it 'toCWString'. :o)


Or toWString (looks nicer to me).



A potential problem is that an immutable(wchar)[] is wstring.


Or toCStr and toWStr (to save 3 characters on each).

winnt.h defines many similar types:

typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
typedef __nullterminated PWSTR *PZPWSTR;
typedef __nullterminated CONST PWSTR *PCZPWSTR;
typedef __nullterminated WCHAR UNALIGNED *LPUWSTR, *PUWSTR;
typedef __nullterminated CONST WCHAR *LPCWSTR, *PCWSTR;
typedef __nullterminated PCWSTR *PZPCWSTR;
typedef __nullterminated CONST WCHAR UNALIGNED *LPCUWSTR, *PCUWSTR;

so variations on any of those make sense.

.. I think the toStringz probably came from the winnt.h defines using z..

typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;
typedef __nullterminated PSTR *PZPSTR;
typedef __nullterminated CONST PSTR *PCZPSTR;
typedef __nullterminated CONST CHAR *LPCSTR, *PCSTR;
typedef __nullterminated PCSTR *PZPCSTR;



Stringz means "Z"ero-terminated "String". The usage predates Windows NT.

Re: Rename std.string.toStringz?

[Jonathan M Davis]

On 2011-06-16 07:33, Steven Schveighoffer wrote:
> On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic
> 
>  wrote:
> > I am against the change for ... social reasons.
> > 
> > Simply put, the D community is used to toStringz . I might be wrong, but
> > I think we are all familiar with this function and use it on a daily
> > basis. :)
> 
> I agree with this assessment.  I'll add that toStringz is memorable -- I
> remember how to use it and write it instantly.  I'm not sure why, but I
> think it's because it's name is really unlikely to occur in any other
> context.
> 
> I don't agree that toStringz is incorrectly camel cased

I'm afraid that I don't understand this view at all, given that string is a 
word and stringz isn't, though there are a few people that have expressed this 
view now.

> and I think
> toCString is not as descriptive, because it's identifying the language
> where zero-terminated strings are from, not that the string is zero
> terminated (signified well by the zero).
> 
> I would like to change toUTF16z to toWStringz (and likewise for
> dstrings).  You haven't listed this as an option.  I see a large
> inconsistency there.

Well, my concern at this point is really toStringz, not toUTF16z. If toStringz 
is renamed, then toUTF16z should follow suit. If it isn't, then perhaps 
toUTF16z should still be renamed, but my pull request doesn't do much with 
std.utf, so messing with toUTF16z isn't really the goal. It's just a side 
effect of renaming toStringz. So, if we keep toStringz, we may very well still 
rename toUTF16z, but the real question is whether we want to rename toStringz.

- Jonathan M Davis

Re: About foreach loops

[Simen Kjaeraas]

On Wed, 15 Jun 2011 22:40:24 +0200, bearophile   
wrote:



Don:


The alternative would be to create __iterator1234 as const, and then
cast away const in the ++ step. Ugly, but would eliminate the
performance cost for structs.


Isn't it undefined in D to modify a const?


I believe this is only because the source may be immutable, and thus
reside in ROM or otherwise be optimized away in places. Casting away
const for a variable you have full control of, should not pose
problems.

--
  Simen

Re: Rename std.string.toStringz?

[Mafi]

Am 16.06.2011 16:33, schrieb Steven Schveighoffer:

On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic
 wrote:


I am against the change for ... social reasons.

Simply put, the D community is used to toStringz . I might be wrong,
but I think we are all familiar with this function and use it on a
daily basis. :)


I agree with this assessment. I'll add that toStringz is memorable -- I
remember how to use it and write it instantly. I'm not sure why, but I
think it's because it's name is really unlikely to occur in any other
context.

I don't agree that toStringz is incorrectly camel cased, and I think
toCString is not as descriptive, because it's identifying the language
where zero-terminated strings are from, not that the string is zero
terminated (signified well by the zero).

I would like to change toUTF16z to toWStringz (and likewise for
dstrings). You haven't listed this as an option. I see a large
inconsistency there.

I completely agree!



-Steve


I think stringz is a name as itself and then having a camel-cased 
toStringX is correct IMO.

Re: Implementing Pure Functions

[Andrei Alexandrescu]

On 6/16/11 5:02 AM, Byakkun wrote:

On Thu, 16 Jun 2011 12:27:30 +0300, Walter Bright
 wrote:


http://drdobbs.com/blogs/tools/230700070

Someone want to post this on reddit?


Done
http://www.reddit.com/r/programming/comments/i13qp/implementing_pure_functions_in_d_programming/


This has sparked an interesting discussion, to which I added my bit.

Andrei

Re: Rename std.string.toStringz?

[Regan Heath]

On Thu, 16 Jun 2011 13:00:23 +0100, Timon Gehr  wrote:


Daniel Gibson wrote:

Am 16.06.2011 08:30, schrieb Jonathan M Davis:



3. Rename it to toCString (probably renaming toUTF16z to something like
toWCString), so it's then more recognizable to newbies


This + keep around aliases for the old names until D3.


+1


+1. But make it 'toCWString'. :o)


Or toWString (looks nicer to me).

Or toCStr and toWStr (to save 3 characters on each).

winnt.h defines many similar types:

typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
typedef __nullterminated PWSTR *PZPWSTR;
typedef __nullterminated CONST PWSTR *PCZPWSTR;
typedef __nullterminated WCHAR UNALIGNED *LPUWSTR, *PUWSTR;
typedef __nullterminated CONST WCHAR *LPCWSTR, *PCWSTR;
typedef __nullterminated PCWSTR *PZPCWSTR;
typedef __nullterminated CONST WCHAR UNALIGNED *LPCUWSTR, *PCUWSTR;

so variations on any of those make sense.

.. I think the toStringz probably came from the winnt.h defines using z..

typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;
typedef __nullterminated PSTR *PZPSTR;
typedef __nullterminated CONST PSTR *PCZPSTR;
typedef __nullterminated CONST CHAR *LPCSTR, *PCSTR;
typedef __nullterminated PCSTR *PZPCSTR;

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Rename std.string.toStringz?

[Lars T. Kyllingstad]

On Wed, 15 Jun 2011 23:30:03 -0700, Jonathan M Davis wrote:

> Okay. I have an open pull request whose main goal is to rename various
> string and character functions so that they're properly camelcased (as
> has been discussed previous in this group):
> https://github.com/D-Programming- Language/phobos/pull/101
> 
> All in all, I think that the renaming in there is fairly obvious and
> non- controversial. However, we have the problem of
> std.string.toStringz. [...]

As I said in the pull request, I'd like to keep toStringz the way it is.

-Lars

Re: Rename std.string.toStringz?

[Steven Schveighoffer]

On Thu, 16 Jun 2011 04:47:50 -0400, Dejan Lekic  
 wrote:



I am against the change for ... social reasons.

Simply put, the D community is used to toStringz . I might be wrong, but  
I think we are all familiar with this function and use it on a daily  
basis. :)


I agree with this assessment.  I'll add that toStringz is memorable -- I  
remember how to use it and write it instantly.  I'm not sure why, but I  
think it's because it's name is really unlikely to occur in any other  
context.


I don't agree that toStringz is incorrectly camel cased, and I think  
toCString is not as descriptive, because it's identifying the language  
where zero-terminated strings are from, not that the string is zero  
terminated (signified well by the zero).


I would like to change toUTF16z to toWStringz (and likewise for  
dstrings).  You haven't listed this as an option.  I see a large  
inconsistency there.


-Steve

Re: Rename std.string.toStringz?

[Jesse Phillips]

Timon Gehr Wrote:

> Daniel Gibson wrote:
> > Am 16.06.2011 08:30, schrieb Jonathan M Davis:
> >
> >>
> >> 3. Rename it to toCString (probably renaming toUTF16z to something like
> >> toWCString), so it's then more recognizable to newbies
> >
> > This + keep around aliases for the old names until D3.
> >
> > Cheers,
> > - Daniel
> 
> +1. But make it 'toCWString'. :o)
> 
> Timon

+1

Re: Rename std.string.toStringz?

[KennyTM~]

On Jun 16, 11 14:30, Jonathan M Davis wrote:

Okay. I have an open pull request whose main goal is to rename various string
and character functions so that they're properly camelcased (as has been
discussed previous in this group): https://github.com/D-Programming-
Language/phobos/pull/101

All in all, I think that the renaming in there is fairly obvious and non-
controversial. However, we have the problem of std.string.toStringz. toStringz
isn't properly camelcased (at least, _I_ would definitely argue that it
isn't). Currently (in that pull request), I have it renamed to toStringZ (with
the old version still around and scheduled to be deprecated, so no code would
break immediately if it were merged in). But some have said that they consider
toStringz to be properly camelcased (apparently they view stringz as a special
word indicating a zero-terminated string). Another suggestion was to rename it
to toCString (which is arguably much more obvious for newbies). In addition to
that, we have std.utf.toUTF16z, which matches the naming scheme that toStringz
has, so if we rename toStringz, we should probably rename toUTF16z as well (to
toWCString?). Certainly, there's no consensus on what to do with the name of
toStringz.

Now, toStringz is probably one of the most heavily used string functions in
Phobos. If we rename it, a _lot_ of code is going to have to be changed. So,
if we rename it, we need to give it a name which most people would consider
better than toStringz and worth the consistency that we gain with regards to
the naming of functions in Phobos. So, the question is, should we

1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz
to be some sort of word unique to the D community or just admit that we're not
going to camelcase it because it would break too much code to do so.

2. Just camelcase it properly and rename it to toStringZ (and probably rename
toUTF16z to toUTF16Z). Code will have to be changed, but the function is still
immediately recognizable to long time D programmers.

3. Rename it to toCString (probably renaming toUTF16z to something like
toWCString), so it's then more recognizable to newbies, but it'll take some
getting used to for everyone else (and of course require lots of code to be
changed).

4. Rename toStringz to something else which is properly camelcased.

I don't like leaving toStringz as it is because of its casing, but I also
don't want to cause code breakage without general agreement on the replacement
name. It's just too important of a function to change the name of willy-nilly.
So, I'm looking to see what everyone else thinks.

Thoughts? Opinions?

- Jonathan M Davis


+1 toCString
+0 toStringz
-1 toStringZ & toUTF16Z

Re: Rename std.ctype to std.ascii?

[Regan Heath]

On Tue, 14 Jun 2011 10:20:48 +0100, Jonathan M Davis   
wrote:


So, given the arguably poor name of ctype and the fact that std.ctype  
does not actually match ctype.h's behavior, unless someone comes up with  
a really good reason not to fairly soon, I'm going to schedule std.ctype  
for deprecation and put the properly camelcased functions in std.ascii.


I reckon this is the best option.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Implementing Pure Functions

[Don]

bearophile wrote:

Walter:


Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski for 
their helpful comments and corrections on this post.<


*pulls Walter's ears* You have forgotten who has found this problem :-)


So have I. It was mentioned at the start of 2008 with respect to pure, 
but the same problem was mentioned with regard to CTFE much earlier, in 
2006 I think. I think Daniel Keep was the first to mention it.

Re: Rename std.string.toStringz?

[Daniel Gibson]

Am 16.06.2011 14:56, schrieb Mike Parker:
> On 6/16/2011 7:59 PM, Daniel Gibson wrote:
>> Am 16.06.2011 13:01, schrieb Kagamin:
>>> c_str
>>> c_wstr
>>>
>>> similarly to c_long
>>
>> So c_long converts a long to a c-long?
>> (Is this a D function/type? I couldn't find it on the homepage)
> 
> It's not a conversion function, but an alias. It's declared, along with
> c_ulong, in core.stdc.config.

So it has nothing to do with toStringz and similar names would be confusing.

Re: Rename std.string.toStringz?

[Mike Parker]

On 6/16/2011 7:59 PM, Daniel Gibson wrote:

Am 16.06.2011 13:01, schrieb Kagamin:

c_str
c_wstr

similarly to c_long


So c_long converts a long to a c-long?
(Is this a D function/type? I couldn't find it on the homepage)


It's not a conversion function, but an alias. It's declared, along with 
c_ulong, in core.stdc.config.

Re: Rename std.string.toStringz?

[Mike Parker]

On 6/16/2011 3:30 PM, Jonathan M Davis wrote:



1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz
to be some sort of word unique to the D community or just admit that we're not
going to camelcase it because it would break too much code to do so.



My vote goes for this one.

Re: Implementing Pure Functions

[Kagamin]

Jimmy Cao Wrote:

> > pure int square(int x)
> > {
> >auto fp = cast(fp_t)&square_debug;
> >return (*fp)(x); // dereference???
> > }
> >
> 
> Yes, that's correct.

You mean, implementation-defined?

Re: Rename std.string.toStringz?

[Timon Gehr]

Daniel Gibson wrote:
> Am 16.06.2011 08:30, schrieb Jonathan M Davis:
>
>>
>> 3. Rename it to toCString (probably renaming toUTF16z to something like
>> toWCString), so it's then more recognizable to newbies
>
> This + keep around aliases for the old names until D3.
>
> Cheers,
> - Daniel

+1. But make it 'toCWString'. :o)

Timon

Re: Help around D2 (for make a rpm package)

[David Nadlinger]

Reminds me that we really need a good »ldmd2« so that the DMD test 
suite, druntime and Phobos can be seamlessly built with LDC 2 – this 
would also make development quite a bit easier.


Implementing it should be pretty straightforward (besides -lib, which 
requires implementing a tiny driver), but I don't have time to deal with 
it right now – anyone? ;)


David


On 6/16/11 1:33 PM, Moritz Warning wrote:

On Thu, 16 Jun 2011 09:56:53 +0100, Dejan Lekic wrote:


We talked about this yesterday on IRC. I successfully built everything
on my Fedora 15 workstation. Follow the instruction on Wiki and it will
be OK.


I think these instructions were meant:
http://dsource.org/projects/ldc/wiki/BuildInstructionsPhobosDruntimeTrunk
They are somewhat hacked together right now
and not good enough to create a package.

Re: Help around D2 (for make a rpm package)

[Moritz Warning]

On Thu, 16 Jun 2011 09:56:53 +0100, Dejan Lekic wrote:

> We talked about this yesterday on IRC. I successfully built everything
> on my Fedora 15 workstation. Follow the instruction on Wiki and it will
> be OK.

I think these instructions were meant:
http://dsource.org/projects/ldc/wiki/BuildInstructionsPhobosDruntimeTrunk
They are somewhat hacked together right now
and not good enough to create a package.

Re: Implementing Pure Functions

[Jimmy Cao]

On Thu, Jun 16, 2011 at 6:07 AM, Kagamin  wrote:

> Walter Bright Wrote:
>
> > http://drdobbs.com/blogs/tools/230700070
>
> import std.stdio;
>
> int square_debug(int x)
> {
>writefln("square(%d)", x);
>return x * x;
> }
>
> pure alias int function(int) fp_t;
>
> pure int square(int x)
> {
>auto fp = cast(fp_t)&square_debug;
>return (*fp)(x); // dereference???
> }
>

Yes, that's correct.

Re: Implementing Pure Functions

[bearophile]

Walter:

>Thanks to Andrei Alexandrescu, Brad Roberts, David Held, and Bartosz Milewski 
>for their helpful comments and corrections on this post.<

*pulls Walter's ears* You have forgotten who has found this problem :-)

Bye,
bearophile

Re: Implementing Pure Functions

[Kagamin]

Walter Bright Wrote:

> http://drdobbs.com/blogs/tools/230700070

import std.stdio;

int square_debug(int x)
{
writefln("square(%d)", x);
return x * x;
}

pure alias int function(int) fp_t;

pure int square(int x)
{
auto fp = cast(fp_t)&square_debug;
return (*fp)(x); // dereference???
}

Re: Rename std.string.toStringz?

[Daniel Gibson]

Am 16.06.2011 13:01, schrieb Kagamin:
> c_str
> c_wstr
> 
> similarly to c_long

So c_long converts a long to a c-long?
(Is this a D function/type? I couldn't find it on the homepage)

Re: Rename std.string.toStringz?

[Kagamin]

c_str
c_wstr

similarly to c_long

Re: Implementing Pure Functions

[Byakkun]

On Thu, 16 Jun 2011 12:27:30 +0300, Walter Bright  
 wrote:



http://drdobbs.com/blogs/tools/230700070

Someone want to post this on reddit?


Done
http://www.reddit.com/r/programming/comments/i13qp/implementing_pure_functions_in_d_programming/

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Help around D2 (for make a rpm package)

[Jens Mueller]

Dejan Lekic wrote:
> We talked about this yesterday on IRC. I successfully built
> everything on my Fedora 15 workstation. Follow the instruction on
> Wiki and it will be OK.

Which wiki?
I found this
http://www.dsource.org/projects/ldc/wiki/BuildInstructions

But I see no instruction on building RPMs for ldc2.

Jens

Implementing Pure Functions

[Walter Bright]

http://drdobbs.com/blogs/tools/230700070

Someone want to post this on reddit?

Re: Rename std.string.toStringz?

[Alix Pexton]

On 16/06/2011 07:30, Jonathan M Davis wrote:


1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz
to be some sort of word unique to the D community or just admit that we're not
going to camelcase it because it would break too much code to do so.


I vote for no change, I like stringz as it is ^^

A...

Re: Help around D2 (for make a rpm package)

[Dejan Lekic]

We talked about this yesterday on IRC. I successfully built everything 
on my Fedora 15 workstation. Follow the instruction on Wiki and it will 
be OK.

Re: Rename std.string.toStringz?

[Dejan Lekic]

I am against the change for ... social reasons.

Simply put, the D community is used to toStringz . I might be wrong, but 
I think we are all familiar with this function and use it on a daily 
basis. :)


However, if you really, really want to stick to the coding convention, 
and decide to rename it anyway, I would go for toCString ...


Kind regards

Dejan Lekic

Re: safe

[sclytrack]

Can't we have safety as in a restricted API or subset of a language
that can only do a limited amount of things that any user feels
confident executing, like only import from std.client and nothing
else is allowed. Memory safe D is already a restricted D.

--

import std.client;


extern (C) routineIamNotSupposedToUse();   //eek


void handleButton1Click(   )
{
  downloadCompileAndExecute("http;//blabla.com/internetclientapplication.d");
  //Let's say D internet client application (DICA) consist of one .d file for
  //the sake of simplicity and speed.
}


void handleButton2Click(   )
{
  routineIamNotSupposedToUse(); //eek
  downloadCompileAndExecute("http://blabla.com/addressbook/page3.d";);
}







== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> On 2011-06-13 09:57, bearophile wrote:
> > sclytrack:
> > > How safe is "safe D" to run on your computer as if it is a client
> > > application.
> >
> > Walter (I think) has decided to call it "Safe D", but a better name is
> > "memory safe D" because it describes better that it gives only a
> > specialized kind of safety.
> _All_ safety is "only" a specialized kind of safety. It would be impossible to
> use the word safe in all of its contexts in a computer language. For instance,
> you could write a virus in D, and _that_ could certainly be considered unsafe.
> - Jonathan M Davis

Re: Rename std.string.toStringz?

[Daniel Gibson]

Am 16.06.2011 08:30, schrieb Jonathan M Davis:

> 
> 3. Rename it to toCString (probably renaming toUTF16z to something like 
> toWCString), so it's then more recognizable to newbies

This + keep around aliases for the old names until D3.

Cheers,
- Daniel

Re: Rename std.string.toStringz?

[Peter Alexander]

On 16/06/11 7:30 AM, Jonathan M Davis wrote:

Thoughts? Opinions?

- Jonathan M Davis


My preference is on a change to toCString. I've never liked toStringz, 
and it seems that a common question among newbies is "how do I pass this 
string to C libraries?". I think changing it to toCString will make it 
more obvious.