date:20110215

"Michel Fortin"  wrote in message 
news:ijfhkt$1fte$1...@digitalmars.com...
> On 2011-02-15 22:41:32 -0500, "Nick Sabalausky"  said:
>
>> I like "nint".
>
> But is it unsigned or signed? Do we need 'unint' too?
>

*shrug* Beats me. I can't even remember if size_t is signed or not.

> I think 'word' & 'uword' would be a better choice.

The only problem I have with that is that "word" seems like something you 
might want to use as a variable name in certain cases. However, I'd still 
prefer "word" over "size_t"

> I can't say I'm too displeased with 'size_t', but it's true that the 
> 'size_t' feels out of place in D code because of its name.
>

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Michel Fortin


On 2011-02-15 22:41:32 -0500, "Nick Sabalausky"  said:


I like "nint".


But is it unsigned or signed? Do we need 'unint' too?

I think 'word' & 'uword' would be a better choice. I can't say I'm too 
displeased with 'size_t', but it's true that the 'size_t' feels out of 
place in D code because of its name.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Integer conversions too pedantic in 64-bit

"gölgeliyele"  wrote in message 
news:ijfc4m$16p6$1...@digitalmars.com...
> On 2/15/11 12:24 PM, foobar wrote:
>> I disagree that the discussion is pointless.
>> On the contrary, the OP pointed out some valid points:
>>
>> 1.  that size_t is inconsistent with D's style guide. the "_t" suffix is 
>> a C++ convention and not a D one. While it makes sense for [former?] C++ 
>> programmers it will confuse newcomers to D from other languages that 
>> would expect the language to follow its own style guide.
>> 2. the proposed change is backwards compatible - the OP asked for an 
>> *additional* alias.
>> 3. generic concepts should belong to the standard library and not user 
>> code which is also where size_t is already defined.
>>
>> IMO, we already have a byte type, it's plain common sense to extend this 
>> with a "native word" type.
>
> Look at the basic data types:
>
> bool, byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, 
> float, double, real, ifloat, idouble, ireal, cfloat, cdouble, creal, char, 
> wchar, dchar
> While size_t is just an alias, it will be used in a similar way to the 
> above. One can  see that it does not fit among these, stylistically 
> speaking. There seems to be a common pattern here, a prefixing character 
> is consistently used to differentiate basic types, such as u-short/short, 
> c-float/float, w-char/char, etc. I wonder if something similar can be done 
> for size_t. nint comes to mind, for native int, that is n-int. Sample 
> code:
>

I like "nint".

>   nint end = 0; // nintendo :)
>

Heh, I like that even more. It's "int eger;" for a new generation :)  And 
much less contrived, come to think of it.

Re: std.range.zip performance


Initial: 58 seconds.

Eliminated the switch in popFront: 53s.

Replaced emplace with assignment: 23s.

Specialized emplace for non-struct types, reinserted: 23s.

Eliminated the loop in empty (replaced with return ranges[0].empty;): 17s.

I'm sure there are ways to further improve this, but there are a few 
difficulties. Each pass through the loop the code must transport values 
from the two arrays into a specific format and then distribute them for 
further calculation. Then, upon each popFront two words must be touched 
because arrays hold pointer+length, not pointer+pointer (as probably 
would be better since ranges are around).



Nice analysis!

Andrei

On 2/15/11 6:24 PM, bearophile wrote:

While doing some benchmarks on the Clay language I've found something 
interesting.

I have timed a zip() done on two short arrays, and I have found this D version 
too much slow compared to normal array code. Higher order functions like zip, 
map, filter, etc are going to stay, they aren't toys, so I think the D compiler 
has to digest them better.

(There is lot of of asm at the tail of this post, I don't know if some of t 
will get cut away.)

Bye,
bearophile


Timings, seconds, best of 3:
   #1:  1.95
   #2: 61.50
   #3:  2.25
   #4:  1.52

--

Binary sizes, bytes:
   #1:  33_016
   #2: 284_188
   #3: 103_964
   #4: 103_964

--

Compilers and command line used:

DMD 2.051
clay compiler (hg id dec41ba07d58 tip, llvm r122866, Jan  5 2011)

clay -inline test1.clay -o test1.exe
dmd -O -release -inline test2.d
dmd -O -release -inline test3.d

To produce asm code with Clay:
clay -inline -asm test1.clay -o test1.s

Output: -1149672960 for all versions.

--

Code used:


// program #1 (Clay)
main() {
 var a = 
Vector([18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28]);
 var b = 
Vector([9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25]);
 var tot = 0; // 32 bit signed int
 for (i in range(0, 50*1000*1000))
 for (x, y in zipped(a, b))
 tot += x + y;
 println(tot);
}

--

// program #2 (D2)
import std.c.stdio: printf;
import std.range: zip;
void main() {
 auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
 auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
 int tot = 0;
 foreach (i; 0 .. 50_000_000)
 foreach (xy; zip(a, b))
 tot += xy[0] + xy[1];
 printf("%d\n", tot);
}

--

// program #3 (D2)
import std.c.stdio: printf;
void main() {
 auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
 auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
 int tot = 0;
 foreach (i; 0 .. 50_000_000)
 foreach (j; 0 .. a.length)
 tot += a[j] + b[j];
 printf("%d\n", tot);
}

--

// program #4 (D2)
import std.c.stdio: printf;
void main() {
 auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
 auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
 int tot = 0;
 foreach (i; 0 .. 50_000_000)
 foreach (j; 0 .. 30)
 tot += a[j] + b[j];
 printf("%d\n", tot);
}

--

Just loops program #1:

 movl$5000, %eax # imm = 0x2FAF080
 .align16, 0x90
LBB2_4: # %bb.nph.i.i
 # =>This Loop Header: Depth=1
 # Child Loop BB2_5 Depth 2
 xorl%edx, %edx
 .align16, 0x90
LBB2_5: # %return410.i.i
 #   Parent Loop BB2_4 Depth=1
 # =>   This Inner Loop Header: Depth=2
 addl(%esi,%edx,4), %ecx
 addl(%edi,%edx,4), %ecx
 incl%edx
 cmpl$30, %edx
 jneLBB2_5
# BB#3: # %return272.loopexit.i.i
 #   in Loop: Header=BB2_4 Depth=1
 decl%eax
 jneLBB2_4

--

Just loops program #2:

LCE:pushdword ptr 018h[ESP]
 movESI,offset FLAT:_D3std5range14__T3ZipTAiTAiZ3Zip6__initZ
 pushdword ptr 018h[ESP]
 pushdword ptr 028h[ESP]
 pushdword ptr 028h[ESP]
 push0
 leaEDI,078h[ESP]
 movsd
 movsd
 movsd
 movsd
 movsd
 leaEAX,078h[ESP]
 callnear ptr 
_D3std5range14__T3ZipTAiTAiZ3Zip6__ctorMFNcAiAiE3std5range14StoppingPolicyZS3std5range14__T3ZipTAiTAiZ3Zip
 movESI,EAX
 leaEDI,044h[ESP]
 movsd
 movsd

Re: appendToFront semantics


On 2/15/11 5:21 PM, Torarin wrote:

2011/2/15 Andrei Alexandrescu:

On 2/15/11 12:10 PM, Adam Ruppe wrote:


One problem with "at least" is it might have to wait for two
packets to come off the network interface; could be fairly slow.


Another is that the stream may end... so there's no guarantee.

Andrei



If the stream ends it would return short. Anyway, my main point was to
allow it to read more than n elements. So if you give it the
definition "try to append n elements or more" it caters for the "don't
block and don't consume more memory than this" situation as well.

Torarin


I think that would work!

Andrei

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread gölgeliyele


On 2/15/11 12:24 PM, foobar wrote:

I disagree that the discussion is pointless.
On the contrary, the OP pointed out some valid points:

1.  that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ 
convention and not a D one. While it makes sense for [former?] C++ programmers it will 
confuse newcomers to D from other languages that would expect the language to follow its 
own style guide.
2. the proposed change is backwards compatible - the OP asked for an 
*additional* alias.
3. generic concepts should belong to the standard library and not user code 
which is also where size_t is already defined.

IMO, we already have a byte type, it's plain common sense to extend this with a 
"native word" type.


Look at the basic data types:

bool, byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, 
float, double, real, ifloat, idouble, ireal, cfloat, cdouble, creal, 
char, wchar, dchar 	


While size_t is just an alias, it will be used in a similar way to the 
above. One can  see that it does not fit among these, stylistically 
speaking. There seems to be a common pattern here, a prefixing character 
is consistently used to differentiate basic types, such as 
u-short/short, c-float/float, w-char/char, etc. I wonder if something 
similar can be done for size_t. nint comes to mind, for native int, that 
is n-int. Sample code:


  nint end = 0; // nintendo :)

Having too many aliases seems like a problem to me. Different developers 
will start using different names and reading code will become harder. 
One would need to learn two things that refer to the same.


My 2 cents: I suggest deprecating size_t and replacing it with a better 
alternative that fits with the D language.

Re: Integer conversions too pedantic in 64-bit

On Tuesday, February 15, 2011 15:13:33 spir wrote:
> On 02/15/2011 11:24 PM, Jonathan M Davis wrote:
> > Is there some low level reason why size_t should be signed or something
> > I'm completely missing?
> 
> My personal issue with unsigned ints in general as implemented in C-like
> languages is that the range of non-negative signed integers is half of the
> range of corresponding unsigned integers (for same size).
> * practically: known issues, and bugs if not checked by the language
> * conceptually: contradicts the "obvious" idea that unsigned (aka naturals)
> is a subset of signed (aka integers)

It's inevitable in any systems language. What are you going to do, throw away a 
bit for unsigned integers? That's not acceptable for a systems language. On 
some 
level, you must live with the fact that you're running code on a specific 
machine 
with a specific set of constraints. Trying to do otherwise will pretty much 
always harm efficiency. True, there are common bugs that might be better 
prevented, but part of it ultimately comes down to the programmer having some 
clue as to what they're doing. On some level, we want to prevent common bugs, 
but the programmer can't have their hand held all the time either.

- Jonathan M Davis

Re: shared libraries in D

2011-02-15 Thread Iain Buclaw

== Quote from Christian Kamm (kamm-incasoftw...@removethis.de)'s article
> Iain Buclaw wrote:
> > Will be making shared libraries default in GDC pretty soon now...
> Did you adjust the GC to check the shared libraries' data sections for
> references? When we looked at this for LDC that turned out to slow down GC
> runs significantly.
> I'm pretty sure bearophile benchmarked it at the time.
> As far as I remember the main problem was that we were scanning all data
> sections - even of plain C libraries.
> Regards,
> Christian

When adding more ranges in the GC to check, slowdowns are inevitable. So far in 
my
personal testing, the slowdowns seem pretty negligible in comparison (never more
than 0.300 seconds, though that could be a sign that I'm not pushing it in the
right way).

To prevent the GC from scanning C libraries, I've added an extra check to only 
add
ranges that have a D module inside them.

Think:
  ModuleReference *mr;
  for ( mr = _Dmodule_ref; mr; mr = mr.next )
  {
  if ( mr >= start && mr <= end )
  {
  addrange = 1;
  break;
  }
  }

This is viable for GDC, as all platforms share the same implementation. Note, 
this
also adds a variable overhead at startup, but I think the unskewed runtime
justifies it to remain.

Regards

Re: std.range.zip performance

I have done one more test, with a much simpler zip(). The code is now faster, 
but it seems there's no hope to have an acceptable performance. Maybe D needs a 
built-in zip as Clay.

Bye,
bearophile

---

Timings, seconds, best of 3:
  #1:  1.95
  #2: 61.50
  #3:  2.25
  #4:  1.52
  #5: 15.50

Note: removing the this() the program #5 gets about 2-3 seconds faster.

---

// program #5 (D2)
import std.c.stdio: printf;

struct zip {
int[] arr1, arr2;
size_t i;

static struct Element { int _0, _1; }

this(int[] a1, int[] a2)
in {
assert(a1.length == a2.length);
} body {
arr1 = a1;
arr2 = a2;
}

bool empty() {
return i >= arr1.length;
}

@property Element front() {
return Element(arr1[i], arr2[i]);
}

void popFront() {
i++;
}
}

void main() {
auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
int tot = 0;
foreach (i; 0 .. 50_000_000)
foreach (xy; zip(a, b))
tot += xy._0 + xy._1;
printf("%d\n", tot);
}

--

Just loops program #5:

LCE:mov 024h[ESP],EBX
lea EBX,054h[ESP]
xor EDX,EDX
mov [EBX],EDX
mov EAX,014h[ESP]
lea ESI,054h[ESP]
mov 4[EBX],EDX
lea EDI,034h[ESP]
mov 8[EBX],EDX
mov 0Ch[EBX],EDX
mov 010h[EBX],EDX
mov EDX,018h[ESP]
mov 058h[ESP],EDX
mov EDX,020h[ESP]
mov 054h[ESP],EAX
mov EAX,01Ch[ESP]
mov 05Ch[ESP],EAX
mov 060h[ESP],EDX
movsd
movsd
movsd
movsd
movsd
mov ECX,044h[ESP]
cmp ECX,034h[ESP]
jae L167
L11D:   mov EBX,044h[ESP]
mov EDX,038h[ESP]
mov ESI,[EBX*4][EDX]
mov EAX,034h[ESP]
mov EDX,040h[ESP]
mov ECX,[EBX*4][EDX]
mov 078h[ESP],ECX
mov EAX,03Ch[ESP]
mov EDX,078h[ESP]
mov 074h[ESP],ESI
mov EAX,074h[ESP]
mov EBX,074h[ESP]
mov 070h[ESP],EDX
add EBX,070h[ESP]
add EBP,EBX
inc dword ptr 044h[ESP]
mov ESI,044h[ESP]
mov 06Ch[ESP],EAX
cmp ESI,034h[ESP]
jb  L11D
L167:   mov EBX,024h[ESP]
inc EBX
cmp EBX,02FAF080h
jb  LCE

--

Re: Integer conversions too pedantic in 64-bit

"spir"  wrote in message 
news:mailman.1709.1297810216.4748.digitalmar...@puremagic.com...
> On 02/15/2011 10:45 PM, Nick Sabalausky wrote:
>> "Adam Ruppe"  wrote in message
>> news:ije0gi$18vo$1...@digitalmars.com...
>>> Sometimes I think we should troll the users a little and make
>>> a release with names like so:
>>>
>>> alias size_t
>>> TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;
>>>
>>> alias ptrdiff_t
>>> TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;
>>>
>>> alias iota lazyRangeThatGoesFromStartToFinishByTheGivenStepAmount;
>>>
>>>
>>> Cash money says everyone would be demanding an emergency release with
>>> shorter names. We'd argue for months about it... and probably settle
>>> back where we started.
>>
>> A small software company I once worked for, Main Sequence Technologies, 
>> had
>> their heads so far up their asses it was trivial for me to get posted on
>> TheDailyWTF's Code Snippet of the Day (This company had a
>> rather...interesting...way of creating their "else" clauses).
>>
>> One of the many "Programming 101, Chapter 1" things they had a habit of
>> screwing up was "Use meaningful variable names!". Throughout the codebase
>> (VB6 - yea, that tells you a lot about their level of competence), there
>> were variables like "aaa", "staaa", "bbb", "stbbb", "ccc", etc. Those are
>> actual names they used. (I even found a file-loading function named 
>> "save".)
>>
>> Needless to say, trying to understand the twisted codebase enough to
>> actually do anything with it was...well, you can imagine. So I would try 
>> to
>> clean things up when I could, in large part just so I could actually keep 
>> it
>> all straight in my own mind.
>>
>> Anyway, to bring this all back around to what you said above, there were
>> times when I understood enough about a variable to know it wasn't 
>> relevant
>> to whatever my main task was, and therefore didn't strictly need to go
>> wasting even *more* time trying to figure out what the hell the variable
>> actually did. So I ended up in the habit of just renaming those variables 
>> to
>> things like:
>>
>> bbb
>> ->
>> thisVariableNeedsAMuchMoreMeaningfulNameThan_bbb
>
> Did you actually type this yourself, Nick, or do you have a secret 
> prototype of camel-case automaton, based on an English language lexing 
> DFA?
>

With all the coding I do, holding 'shift' between words is almost as natural 
to me as hitting 'space' between words.

An automated english -> camel-case tool wouldn't need anything fancy though. 
Just toUpper() the first character after each space and then remove the 
spaces.

I may be missing what you meant, though.

Re: Integer conversions too pedantic in 64-bit

Adam Ruppe:

> Daniel Gibson wrote:
> > Probably it would be helpful if size_t was a proper type that can't
> > be mixed with other types in dangerous ways without explicit casting.
> 
> Bad idea: once you insert an explicit cast, you now have a *hidden*
> bug on the new platform instead of a compile error.

I'll keep this in mind.

Bye,
bearophile

std.range.zip performance

While doing some benchmarks on the Clay language I've found something 
interesting.

I have timed a zip() done on two short arrays, and I have found this D version 
too much slow compared to normal array code. Higher order functions like zip, 
map, filter, etc are going to stay, they aren't toys, so I think the D compiler 
has to digest them better.

(There is lot of of asm at the tail of this post, I don't know if some of t 
will get cut away.)

Bye,
bearophile


Timings, seconds, best of 3:
  #1:  1.95
  #2: 61.50
  #3:  2.25
  #4:  1.52

--

Binary sizes, bytes:
  #1:  33_016
  #2: 284_188
  #3: 103_964
  #4: 103_964

--

Compilers and command line used:

DMD 2.051
clay compiler (hg id dec41ba07d58 tip, llvm r122866, Jan  5 2011)

clay -inline test1.clay -o test1.exe
dmd -O -release -inline test2.d
dmd -O -release -inline test3.d

To produce asm code with Clay:
clay -inline -asm test1.clay -o test1.s

Output: -1149672960 for all versions.

--

Code used:


// program #1 (Clay)
main() {
var a = 
Vector([18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28]);
var b = 
Vector([9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25]);
var tot = 0; // 32 bit signed int
for (i in range(0, 50*1000*1000))
for (x, y in zipped(a, b))
tot += x + y;
println(tot);
}

--

// program #2 (D2)
import std.c.stdio: printf;
import std.range: zip;
void main() {
auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
int tot = 0;
foreach (i; 0 .. 50_000_000)
foreach (xy; zip(a, b))
tot += xy[0] + xy[1];
printf("%d\n", tot);
}

--

// program #3 (D2)
import std.c.stdio: printf;
void main() {
auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
int tot = 0;
foreach (i; 0 .. 50_000_000)
foreach (j; 0 .. a.length)
tot += a[j] + b[j];
printf("%d\n", tot);
}

--

// program #4 (D2)
import std.c.stdio: printf;
void main() {
auto a = 
[18,10,17,14,19,23,11,0,6,0,17,25,5,4,19,21,17,13,5,7,11,22,23,17,24,7,11,11,1,28];
auto b = 
[9,12,1,4,1,18,11,6,5,18,24,15,26,14,24,8,17,26,23,17,3,28,27,0,9,27,0,19,13,25];
int tot = 0;
foreach (i; 0 .. 50_000_000)
foreach (j; 0 .. 30)
tot += a[j] + b[j];
printf("%d\n", tot);
}

--

Just loops program #1:

movl$5000, %eax # imm = 0x2FAF080
.align16, 0x90
LBB2_4: # %bb.nph.i.i
# =>This Loop Header: Depth=1
# Child Loop BB2_5 Depth 2
xorl%edx, %edx
.align16, 0x90
LBB2_5: # %return410.i.i
#   Parent Loop BB2_4 Depth=1
# =>  This Inner Loop Header: Depth=2
addl(%esi,%edx,4), %ecx
addl(%edi,%edx,4), %ecx
incl%edx
cmpl$30, %edx
jneLBB2_5
# BB#3: # %return272.loopexit.i.i
#   in Loop: Header=BB2_4 Depth=1
decl%eax
jneLBB2_4

--

Just loops program #2:

LCE:pushdword ptr 018h[ESP]
movESI,offset FLAT:_D3std5range14__T3ZipTAiTAiZ3Zip6__initZ
pushdword ptr 018h[ESP]
pushdword ptr 028h[ESP]
pushdword ptr 028h[ESP]
push0
leaEDI,078h[ESP]
movsd
movsd
movsd
movsd
movsd
leaEAX,078h[ESP]
callnear ptr 
_D3std5range14__T3ZipTAiTAiZ3Zip6__ctorMFNcAiAiE3std5range14StoppingPolicyZS3std5range14__T3ZipTAiTAiZ3Zip
movESI,EAX
leaEDI,044h[ESP]
movsd
movsd
movsd
movsd
movsd
leaESI,044h[ESP]
leaEDI,024h[ESP]
movsd
movsd
movsd
movsd
movsd
leaEAX,024h[ESP]
callnear ptr _D3std5range14__T3ZipTAiTAiZ3Zip5emptyMFZb
xorAL,1
jeL153
L11C:leaEAX,024h[ESP]
callnear ptr 
_D3std5range14__T3ZipTAiTAiZ3Zip5frontMFNdZS3std8typecons14__T5TupleTiTiZ5Tuple
mov07Ch[ESP],EAX
movECX,07Ch[ESP]
leaEAX,024h[ESP]
mov080h[ESP],EDX
addECX,080h[ESP]
addEBX,ECX
callnear ptr _D3std5range14__T3ZipTAiTAiZ3Zip8popFrontMFZv
leaEAX,024h[ESP]
callnear ptr _D3std5range14__T3ZipTAiTAiZ3Zip5emptyMFZb

Re: Partially qualified module name lookup

2011-02-15 Thread Andrej Mitrovic

If modules B and C belong to the A package, then there are no "B" and
"C" modules, there are "A.B" and "A.C" modules. You can refer to a foo
function by either:
foo()
or
A.b.foo()

Of course, in this case the two functions will conflict if you don't
fully qualify the names. A workaround is to use named imports:

import B = A.B;
import C = A.C;

void main()
{
B.foo();
C.foo();
}

Partially qualified module name lookup


If I have two functions within nested modules:

A.B.foo()
A.C.foo()

Why can't I refer to them using

B.foo();
C.foo();

??

DMD just complains about undefined identifiers B and C.

The only way to refer to those is to fully qualify them:

A.B.foo();
A.C.foo();

Is this a bug?

Re: Integer conversions too pedantic in 64-bit

Am 16.02.2011 00:03, schrieb spir:
> On 02/15/2011 10:40 PM, Daniel Gibson wrote:
>> In general I think that you just have to define how you serialize data to
>> disk/net/whatever (what endianess, what exact types) and you won't have
>> problems. Just dumping the data to disk isn't portable anyway.
> 
> How do you, in general, cope with the issue that, when using machine-size 
> types,
> programs or (program+data) combinations will work on some machines and not on
> others? This disturbs me a lot. I prefere having a constant field of
> applicability, even if artificially reduced for some set of machines.
> Similar reflexion about "infinite"-size numbers.
> 

I'm not sure I understand your question correctly..
1. You can't always deal with it, there may always be platforms (e.g. 16bit
platforms) that just can't execute your code and can't handle your types.
2. When handling data that is exchanged between programs (that may run on
different platforms) you just have to agree on a format for that data. You could
for example serialize it to XML or JSON or use a binary protocol that defines
exactly what types (what size, what endianess, what encoding) are used and how.
You can then decide for your applications data things like "this array will
*never* exceed 65k elements, so I can store it's size as ushort" and so on.
You should enforce these constraints on all platforms, of course (e.g.
assert(arr.length <= ushort.max); )
This also means that you can decide that you'll never have any arrays longer
than uint.max so they can be read and written on any platform - you just need to
make sure that, when reading it from disk/net/..., you read the length in the
right format (analog for writing).

Or would you prefer D to behave like a 32bit language on any platforms?
That means arrays *never* have more than uint.max elements etc?
Such constraints are not acceptable for a system programming language.
(The alternative - using ulong for array indexes on 32bit platforms - is
unacceptable as well because it'd slow thing down to much).

> Note this is different from using machine-size (unsigned) integers on the
> implementation side, for implementation reasons. This could be done, I guess,
> without having language-side issues. Meaning int, for instance, could be on 
> the
> implementation side the same thing as long on 64-bit machine, but still be
> semantically limited to 32-bit; so that the code works the same way on all
> machines.
> 
> Denis

Cheers,
- Daniel

Re: Integer conversions too pedantic in 64-bit

"Daniel Gibson"  wrote in message 
news:ijett7$1ie$5...@digitalmars.com...
> Am 15.02.2011 23:00, schrieb Nick Sabalausky:
>> "so"  wrote in message news:op.vqyk3emumpw3zg@so-pc...
>>>
>>> Funny thing is the most important argument against size_t got the least
>>> attention.
>>> I will leave it as an exercise for the reader.
>>
>> That variables of type "size_t" are frequently used to store indicies 
>> rather
>> than the actual *size* of anything?
>>
>> That it does nothing to help with 32/64-bit portability until you 
>> actually
>> compile your code both ways?
>
> I don't understand that point.
>

If you're writing something in 32-bit and you use size_t, it may compile 
perfectly fine for 32-bit, but the compiler won't tell you about any 
problems that will appear when you compile the same code for 64-bit (such as 
"can't implicitly convert"). Presumably the same would apply to writing 
something on 64-bit and then suddenly compiling for 32-bit.

I'm not actually asserting that this is a big issue. Maybe it is, maybe it 
isn't, I don't know. Just making guesses at what "so" sees as "the most 
important argument against size_t [that] got the least attention".

Re: Integer conversions too pedantic in 64-bit

On Tuesday, February 15, 2011 14:00:12 Nick Sabalausky wrote:
> "so"  wrote in message news:op.vqyk3emumpw3zg@so-pc...
> 
> >> I disagree that the discussion is pointless.
> >> On the contrary, the OP pointed out some valid points:
> >> 
> >> 1.  that size_t is inconsistent with D's style guide. the "_t" suffix is
> >> a C++ convention and not a D one. While it makes sense for [former?] C++
> >> programmers it will confuse newcomers to D from other languages that
> >> would expect the language to follow its own style guide.
> >> 2. the proposed change is backwards compatible - the OP asked for an
> >> *additional* alias.
> >> 3. generic concepts should belong to the standard library and not user
> >> code which is also where size_t is already defined.
> >> 
> >> IMO, we already have a byte type, it's plain common sense to extend this
> >> with a "native word" type.
> > 
> > Funny thing is the most important argument against size_t got the least
> > attention.
> > I will leave it as an exercise for the reader.
> 
> That variables of type "size_t" are frequently used to store indicies
> rather than the actual *size* of anything?
> 
> That it does nothing to help with 32/64-bit portability until you actually
> compile your code both ways?

What _does_ have to do with 32/64-bit portability until you compile both ways? 
Regardless of what the name is, it's still going to be the word size of the 
machine and vary between 32-bit and 64-bit anyway.

- Jonathan M Davis

Re: Integer conversions too pedantic in 64-bit

"Walter Bright"  wrote in message 
news:ijerk4$2u3a$1...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright"  wrote in message 
>> news:ijeil4$2aso$3...@digitalmars.com...
>>> spir wrote:
 Having to constantly explain that "_t" means type, that "size" does not 
 mean size, what this type is supposed to mean instead, what it is used 
 for in core and stdlib functionality, and what programmers are supposed 
 to use it for... isn't this a waste of our time? This, only because the 
 name is mindless?
>>> No, because there is a vast body of work that uses size_t and a vast 
>>> body of programmers who know what it is and are totally used to it.
>>>
>>
>> And there's a vast body who don't.
>>
>> And there's a vast body who are used to C++, so let's just abandon D and 
>> make it an implementation of C++ instead.
>
> I would agree that D is a complete waste of time if all it consisted of 
> was renaming things.

And since D *does* force C++ users to learn far bigger differences, learning 
a different name for something is trivial.

Re: appendToFront semantics

2011-02-15 Thread Torarin

2011/2/15 Andrei Alexandrescu :
> On 2/15/11 12:10 PM, Adam Ruppe wrote:
>>
>> One problem with "at least" is it might have to wait for two
>> packets to come off the network interface; could be fairly slow.
>
> Another is that the stream may end... so there's no guarantee.
>
> Andrei
>

If the stream ends it would return short. Anyway, my main point was to
allow it to read more than n elements. So if you give it the
definition "try to append n elements or more" it caters for the "don't
block and don't consume more memory than this" situation as well.

Torarin

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Rainer Schuetze



Steven Schveighoffer wrote:


In addition size_t isn't actually defined by the compiler.  So the 
library controls the size of size_t, not the compiler.  This should make 
it extremely portable.




I do not consider the language and the runtime as completely seperate 
when it comes to writing code. BTW, though defined in object.di, size_t 
is tied to some compiler internals:


alias typeof(int.sizeof) size_t;

and the compiler will make assumptions about this when creating array 
literals.


Consider saving an array to disk, trying to read it on another 
platform. How many bits should be written for the size of that array?


It depends on the protocol or file format definition.  It should be 
irrelevant what platform/architecture you are on.  Any format or 
protocol worth its salt will define what size integers you should store.


Agreed, the example probably was not the best one.

I don't have a perfect solution, but maybe builtin arrays could be 
limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless 
signed/unsigned conversions), so the normal type to be used is still 
"int". Ranges should adopt the type sizes of the underlying objects.


No, this is too limiting.  If I have 64GB of memory (not out of the 
question), and I want to have a 5GB array, I think I should be allowed 
to.  This is one of the main reasons to go to 64-bit in the first place.


Yes, that's the imperfect part of the proposal. An array of ints could 
still use up to 16 GB, though.


What bothers me is that you have to deal with these "portability issues" 
from the very moment you store the length of an array elsewhere. Not a 
really big deal, and I don't think it will change, but still feels a bit 
awkward.

digitalmars-d@puremagic.com

Peter Alexander wrote:

> On 15/02/11 10:47 PM, Lutger Blijdestijn wrote:
>> For reference, here is a link to the thread discussing it:
>> http://www.mail- archive.com/digitalmars-d@puremagic.com/msg44075.html
>>
>> If I understood that discussion correctly, 'auto ref' is supposed to
>> solve the rvalue references problem but are not completely implemented
>> yet.
> 
> Thanks Lutger.
> 
>  From the thread, it seems like the correct annotation would be 'auto
> ref const T', would it not?

Yes, I think so.

digitalmars-d@puremagic.com


On 15/02/11 10:47 PM, Lutger Blijdestijn wrote:

For reference, here is a link to the thread discussing it: http://www.mail-
archive.com/digitalmars-d@puremagic.com/msg44075.html

If I understood that discussion correctly, 'auto ref' is supposed to solve
the rvalue references problem but are not completely implemented yet.


Thanks Lutger.

From the thread, it seems like the correct annotation would be 'auto 
ref const T', would it not?

Re: Integer conversions too pedantic in 64-bit

Nick Sabalausky wrote:

> "Nick Sabalausky"  wrote in message
> news:ijesem$brd$1...@digitalmars.com...
>> "Steven Schveighoffer"  wrote in message
>> news:op.vqx78nkceav7ka@steve-laptop...
>>>
>>> size_t works,  it has a precedent, it's already *there*, just use it, or
>>> alias it if you  don't like it.
>>>
>>
>> One could make much the same argument about the whole of C++. It works,
>> it has a precedent, it's already *there*, just use it.
>>
> 
> The whole reason I came to D was because, at the time, D was more
> interested in fixing C++'s idiocy than just merely aping C++ as the theme
> seems to be now.

I don't see any difference, D has always kept a strong link to it's C++ 
heritage. It's just a matter of what you define as idiocy.

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 11:24 PM, Jonathan M Davis wrote:

Is there some low level reason why size_t should be signed or something I'm
completely missing?


My personal issue with unsigned ints in general as implemented in C-like 
languages is that the range of non-negative signed integers is half of the 
range of corresponding unsigned integers (for same size).

* practically: known issues, and bugs if not checked by the language
* conceptually: contradicts the "obvious" idea that unsigned (aka naturals) is 
a subset of signed (aka integers)


denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 10:49 PM, Michel Fortin wrote:

On 2011-02-15 16:33:33 -0500, Walter Bright  said:


Nick Sabalausky wrote:

"Walter Bright"  wrote in message
news:ijeil4$2aso$3...@digitalmars.com...

spir wrote:

Having to constantly explain that "_t" means type, that "size" does not
mean size, what this type is supposed to mean instead, what it is used for
in core and stdlib functionality, and what programmers are supposed to use
it for... isn't this a waste of our time? This, only because the name is
mindless?

No, because there is a vast body of work that uses size_t and a vast body
of programmers who know what it is and are totally used to it.


And there's a vast body who don't.

And there's a vast body who are used to C++, so let's just abandon D and
make it an implementation of C++ instead.


I would agree that D is a complete waste of time if all it consisted of was
renaming things.


I'm just wondering whether 'size_t', because it is named after its C
counterpart, doesn't feel too alien in D, causing people to prefer 'uint' or
'ulong' instead even when they should not. We're seeing a lot of code failing
on 64-bit because authors used the fixed-size types which are more D-like in
naming. Wouldn't more D-like names that don't look like relics from C --
something like 'word' and 'uword' -- have helped prevent those bugs by making
the word-sized type look worth consideration?


Exactly :-)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: appendToFront semantics


On 2/15/11 12:10 PM, Adam Ruppe wrote:

One problem with "at least" is it might have to wait for two
packets to come off the network interface; could be fairly slow.


Another is that the stream may end... so there's no guarantee.

Andrei

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 10:40 PM, Daniel Gibson wrote:

Am 15.02.2011 20:15, schrieb Rainer Schuetze:


I think David has raised a good point here that seems to have been lost in the
discussion about naming.

Please note that the C name of the machine word integer was usually called
"int". The C standard only specifies a minimum bit-size for the different types
(see for example http://www.ericgiguere.com/articles/ansi-c-summary.html). Most
of current C++ implementations have identical "int" sizes, but now "long" is
different. This approach has failed and has caused many headaches when porting
software from one platform to another. D has recognized this and has explicitely
defined the bit-size of the various integer types. That's good!

Now, with size_t the distinction between platforms creeps back into the
language. It is everywhere across phobos, be it as length of ranges or size of
containers. This can get viral, as everything that gets in touch with these
values might have to stick to size_t. Is this really desired?

Consider saving an array to disk, trying to read it on another platform. How
many bits should be written for the size of that array?



This can indeed be a problem which actually is existent in Phobos: std.streams
Outputstream has a write(char[]) method - and similar methods for wchar and
dchar - that do exactly this: write a size_t first and then the data.. in many
places they used uint instead of size_t, but at the one method where this is a
bad idea they used size_t ;-) (see also
http://d.puremagic.com/issues/show_bug.cgi?id=5001 )

In general I think that you just have to define how you serialize data to
disk/net/whatever (what endianess, what exact types) and you won't have
problems. Just dumping the data to disk isn't portable anyway.


How do you, in general, cope with the issue that, when using machine-size 
types, programs or (program+data) combinations will work on some machines and 
not on others? This disturbs me a lot. I prefere having a constant field of 
applicability, even if artificially reduced for some set of machines.

Similar reflexion about "infinite"-size numbers.

Note this is different from using machine-size (unsigned) integers on the 
implementation side, for implementation reasons. This could be done, I guess, 
without having language-side issues. Meaning int, for instance, could be on the 
implementation side the same thing as long on 64-bit machine, but still be 
semantically limited to 32-bit; so that the code works the same way on all 
machines.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit

"so"  wrote in message news:op.vqyk3emumpw3zg@so-pc...
>> I disagree that the discussion is pointless.
>> On the contrary, the OP pointed out some valid points:
>>
>> 1.  that size_t is inconsistent with D's style guide. the "_t" suffix is 
>> a C++ convention and not a D one. While it makes sense for [former?] C++ 
>> programmers it will confuse newcomers to D from other languages that 
>> would expect the language to follow its own style guide.
>> 2. the proposed change is backwards compatible - the OP asked for an 
>> *additional* alias.
>> 3. generic concepts should belong to the standard library and not user 
>> code which is also where size_t is already defined.
>>
>> IMO, we already have a byte type, it's plain common sense to extend this 
>> with a "native word" type.
>
> Funny thing is the most important argument against size_t got the least 
> attention.
> I will leave it as an exercise for the reader.

That variables of type "size_t" are frequently used to store indicies rather 
than the actual *size* of anything?

That it does nothing to help with 32/64-bit portability until you actually 
compile your code both ways?

That Nick doesn't like it? ;)

digitalmars-d@puremagic.com

Jonathan M Davis wrote:

...
> 
> Personally, it wouldn't hurt my feelings any to have const ref take
> temporaries. I do not understand why it's a problem. But Andrei insists
> that it is. Presumably Walter agrees, but I don't know. They could very
> well be right and that it's overall better _not_ to have const ref take
> temporaries, but it _is_ annoying. Since I don't understand what the real
> problem with not knowing whether const ref is actually referring to an
> lvalue or rvalue is, I can't really judge whether they're right or wrong.
> However, Andrei is certain that it's on of C++'s biggest mistakes.
> 
> Regardless, the general push has been that structs be cheap to copy, and I
> would argue that if you're structs _aren't_ relatively cheap to copy, you
> should at least consider rethinking your design. Sometimes COW or ref
> semantics will probably be required though.
> 
> There may be a way to solve this problem reasonably and still have const
> ref require lvalues, but for the moment, we have to deal with it.
> 
> - Jonathan M Davis

For reference, here is a link to the thread discussing it: http://www.mail-
archive.com/digitalmars-d@puremagic.com/msg44075.html

If I understood that discussion correctly, 'auto ref' is supposed to solve 
the rvalue references problem but are not completely implemented yet.

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 23:43, schrieb Adam Ruppe:
> Daniel Gibson wrote:
>> Probably it would be helpful if size_t was a proper type that can't
>> be mixed with other types in dangerous ways without explicit casting.
> 
> Bad idea: once you insert an explicit cast, you now have a *hidden*
> bug on the new platform instead of a compile error.

You should only cast when you know what you're doing..
If you get a compiler error on the new platform and just shut it up by doing an
explicit cast then, it's just as bad.
But having to do an explicit cast either way forces you to think about what
you're doing, hopefully avoiding large pieces of code that need to be rewritten
because they only worked because size_t was uint or such.

Cheers,
- Daniel

Re: Removed?


spir wrote:
And this itself was made possible by the fact software /re/production 
costs are neglectable compared to production ones (human competence, 
time & motivation).
The same applies indeed, even more since the numeric revolution, to most 
of human knowledge and creation. Result of music composition has always 
been (potentially or concretely, depending to laws) freely available good.


I agree. Consider the explosion of knowledge and progress immediately after the 
printing press was invented. Printers were eager for materials to print, and 
compiled manuals on everything they could think of.


It's interesting how the Egyptian revolution is attributed to being enabled by 
the internet; similarly, I don't think the American revolution would have 
happened without the printing press.

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 10:45 PM, Nick Sabalausky wrote:

"Adam Ruppe"  wrote in message
news:ije0gi$18vo$1...@digitalmars.com...

Sometimes I think we should troll the users a little and make
a release with names like so:

alias size_t
TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;

alias ptrdiff_t
TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;

alias iota lazyRangeThatGoesFromStartToFinishByTheGivenStepAmount;


Cash money says everyone would be demanding an emergency release with
shorter names. We'd argue for months about it... and probably settle
back where we started.


A small software company I once worked for, Main Sequence Technologies, had
their heads so far up their asses it was trivial for me to get posted on
TheDailyWTF's Code Snippet of the Day (This company had a
rather...interesting...way of creating their "else" clauses).

One of the many "Programming 101, Chapter 1" things they had a habit of
screwing up was "Use meaningful variable names!". Throughout the codebase
(VB6 - yea, that tells you a lot about their level of competence), there
were variables like "aaa", "staaa", "bbb", "stbbb", "ccc", etc. Those are
actual names they used. (I even found a file-loading function named "save".)

Needless to say, trying to understand the twisted codebase enough to
actually do anything with it was...well, you can imagine. So I would try to
clean things up when I could, in large part just so I could actually keep it
all straight in my own mind.

Anyway, to bring this all back around to what you said above, there were
times when I understood enough about a variable to know it wasn't relevant
to whatever my main task was, and therefore didn't strictly need to go
wasting even *more* time trying to figure out what the hell the variable
actually did. So I ended up in the habit of just renaming those variables to
things like:

bbb
->
thisVariableNeedsAMuchMoreMeaningfulNameThan_bbb


Did you actually type this yourself, Nick, or do you have a secret prototype of 
camel-case automaton, based on an English language lexing DFA?


denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit

Daniel Gibson wrote:
> Probably it would be helpful if size_t was a proper type that can't
> be mixed with other types in dangerous ways without explicit casting.

Bad idea: once you insert an explicit cast, you now have a *hidden*
bug on the new platform instead of a compile error.

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 23:29, schrieb Nick Sabalausky:
> "Daniel Gibson"  wrote in message 
> news:ijett7$1ie$5...@digitalmars.com...
>> Am 15.02.2011 23:00, schrieb Nick Sabalausky:
>>> "so"  wrote in message news:op.vqyk3emumpw3zg@so-pc...

 Funny thing is the most important argument against size_t got the least
 attention.
 I will leave it as an exercise for the reader.
>>>
>>> That variables of type "size_t" are frequently used to store indicies 
>>> rather
>>> than the actual *size* of anything?
>>>
>>> That it does nothing to help with 32/64-bit portability until you 
>>> actually
>>> compile your code both ways?
>>
>> I don't understand that point.
>>
> 
> If you're writing something in 32-bit and you use size_t, it may compile 
> perfectly fine for 32-bit, but the compiler won't tell you about any 
> problems that will appear when you compile the same code for 64-bit (such as 
> "can't implicitly convert"). Presumably the same would apply to writing 
> something on 64-bit and then suddenly compiling for 32-bit.
> 
> I'm not actually asserting that this is a big issue. Maybe it is, maybe it 
> isn't, I don't know. Just making guesses at what "so" sees as "the most 
> important argument against size_t [that] got the least attention".
> 

Ok, that is right.
Probably it would be helpful if size_t was a proper type that can't be mixed
with other types in dangerous ways without explicit casting.

Cheers,
- Daniel

Re: Integer conversions too pedantic in 64-bit

On Monday, February 14, 2011 18:11:10 Don wrote:
> Nick Sabalausky wrote:
> > "Jonathan M Davis"  wrote in message
> > news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...
> > 
> >> On Monday, February 14, 2011 17:06:43 spir wrote:
> >>> Rename size-t, or rather introduce a meaningful standard alias? (would
> >>> vote
> >>> for Natural)
> >> 
> >> Why? size_t is what's used in C++. It's well known and what lots of
> >> programmers
> >> would expect What would you gain by renaming it?
> > 
> > Although I fully realize how much this sounds like making a big deal out
> > of nothing, to me, using "size_t" has always felt really clumsy and
> > awkward. I think it's partly because of using an underscore in such an
> > otherwise short identifier, and partly because I've been aware of size_t
> > for years and still don't have the slightest clue WTF that "t" means.
> > Something like "wordsize" would make a lot more sense and frankly feel
> > much nicer.
> > 
> > And, of course, there's a lot of well-known things in C++ that D
> > deliberately destroys. D is a different language, it may as well do
> > things better.
> 
> To my mind, a bigger problem is that size_t is WRONG. It should be an
> integer. NOT unsigned.

Why exactly should it be signed? You're not going to index an array with a 
negative value (bounds checking would blow up on that I would think, though 
IIRC 
you can do that in C/C++ - which is a fairly stupid thing to do IMHO). You lose 
half the possible length of arrays if you have a signed size_t (less of a 
problem in 64-bit land than 32-bit land). I don't see any benefit to it being 
signed other than you can have a for loop do something like this:

for(size_t i = a.length - 1; i >= 0; --i)

And while that can be annoying at times, it's not like it's all that hard to 
code around.

Is there some low level reason why size_t should be signed or something I'm 
completely missing?

- Jonathan M Davis

digitalmars-d@puremagic.com

On Tuesday, February 15, 2011 12:35:31 Peter Alexander wrote:
> On 15/02/11 7:55 PM, Jonathan M Davis wrote:
> > On Tuesday, February 15, 2011 11:48:25 Peter Alexander wrote:
> >> Do D const references work the same as C++'s?
> >> 
> >> i.e.
> >> - Can they bind to rvalues?
> >> - Do they extend the life of rvalues?
> >> 
> >> If they do, are there any differences from C++?
> >> 
> >> If they don't, how do I pass large structs into a function efficiently?
> > 
> > The only bind to lvalues. A ref is a reference to a variable, so normal
> > ref has to be passed a variable. In C++, it was decided that const&  was
> > special and could take a temporary. In D, it's no different from ref
> > except that it's const, so it can't be changed. There have been requests
> > to fix this, but Andrei is adamant that it was a huge mistake in C++ to
> > do it since it makes it so that you can't determine whether a const&  is
> > really a rvalue or an lvalue. I don't know enough to know how much that
> > really matters, but apparently it causes problems. The result is that D
> > doesn't do that, which can be rather annoying when trying to pass
> > temporaries to functions which take const ref, but that's the way it
> > goes.
> > 
> > If you want to pass a large struct to a function efficiently, and you
> > know that function isn't going to need to alter the struct, make it
> > const ref. That way, it's const, and it doesn't get copied. However,
> > that means that you can't pass temporaries to it. However, if you need
> > to pass a temporary, then you're going to have to actually assign it to
> > a variable first.
> > 
> > I _thought_ tht you could define a cost ref version and a non-const ref
> > version and it would call the const ref version on lvalues and the
> > non-const ref version on rvalues, but when I just tried it, it seems to
> > call the non-const ref version in both cases. I don't know if that's a
> > bug or not. But if you just have a const ref version, and you create a
> > variable where you'd normally use a temporary, you'll be fine.
> > 
> > - Jonathan M Davis
> 
> Surely this is a major usability issue? I have to create a new local
> variable just so that I can pass structs round efficiently (either that
> or change the struct to have COW or ref semantics, both of which are
> unacceptable).

Well, if it's made so that you can have const ref and non-const ref version and 
the const ref gets called for lvalues and the non-const ref gets called for 
rvalues, then that fixes most of the problem, though it's still annoying. e.g.

int func(const ref S s)
{
   //...
}

int func(S s)
{
return func(s);
}

At the moment, the const ref version only gets called if the struct you're 
passing in is actually const, so that idiom doesn't currently work. I'm not 
sure 
whether it's actually supposed to or not though. I would hope so, but I don't 
know.

Personally, it wouldn't hurt my feelings any to have const ref take 
temporaries. 
I do not understand why it's a problem. But Andrei insists that it is. 
Presumably Walter agrees, but I don't know. They could very well be right and 
that it's overall better _not_ to have const ref take temporaries, but it _is_ 
annoying. Since I don't understand what the real problem with not knowing 
whether const ref is actually referring to an lvalue or rvalue is, I can't 
really judge whether they're right or wrong. However, Andrei is certain that 
it's on of C++'s biggest mistakes.

Regardless, the general push has been that structs be cheap to copy, and I 
would 
argue that if you're structs _aren't_ relatively cheap to copy, you should at 
least consider rethinking your design. Sometimes COW or ref semantics will 
probably be required though.

There may be a way to solve this problem reasonably and still have const ref 
require lvalues, but for the moment, we have to deal with it.

- Jonathan M Davis

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 23:00, schrieb Nick Sabalausky:
> "so"  wrote in message news:op.vqyk3emumpw3zg@so-pc...
>>> I disagree that the discussion is pointless.
>>> On the contrary, the OP pointed out some valid points:
>>>
>>> 1.  that size_t is inconsistent with D's style guide. the "_t" suffix is 
>>> a C++ convention and not a D one. While it makes sense for [former?] C++ 
>>> programmers it will confuse newcomers to D from other languages that 
>>> would expect the language to follow its own style guide.
>>> 2. the proposed change is backwards compatible - the OP asked for an 
>>> *additional* alias.
>>> 3. generic concepts should belong to the standard library and not user 
>>> code which is also where size_t is already defined.
>>>
>>> IMO, we already have a byte type, it's plain common sense to extend this 
>>> with a "native word" type.
>>
>> Funny thing is the most important argument against size_t got the least 
>> attention.
>> I will leave it as an exercise for the reader.
> 
> That variables of type "size_t" are frequently used to store indicies rather 
> than the actual *size* of anything?
> 
> That it does nothing to help with 32/64-bit portability until you actually 
> compile your code both ways?

I don't understand that point.

> 
> That Nick doesn't like it? ;)
>

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Michel Fortin


On 2011-02-15 16:33:33 -0500, Walter Bright  said:


Nick Sabalausky wrote:
"Walter Bright"  wrote in message 
news:ijeil4$2aso$3...@digitalmars.com...

spir wrote:
Having to constantly explain that "_t" means type, that "size" does not 
mean size, what this type is supposed to mean instead, what it is used 
for in core and stdlib functionality, and what programmers are supposed 
to use it for... isn't this a waste of our time? This, only because the 
name is mindless?
No, because there is a vast body of work that uses size_t and a vast 
body of programmers who know what it is and are totally used to it.


And there's a vast body who don't.

And there's a vast body who are used to C++, so let's just abandon D 
and make it an implementation of C++ instead.


I would agree that D is a complete waste of time if all it consisted of 
was renaming things.


I'm just wondering whether 'size_t', because it is named after its C 
counterpart, doesn't feel too alien in D, causing people to prefer 
'uint' or 'ulong' instead even when they should not. We're seeing a lot 
of code failing on 64-bit because authors used the fixed-size types 
which are more D-like in naming. Wouldn't more D-like names that don't 
look like relics from C -- something like 'word' and 'uword' -- have 
helped prevent those bugs by making the word-sized type look worth 
consideration?


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 22:48, schrieb Nick Sabalausky:
> "Steven Schveighoffer"  wrote in message 
> news:op.vqx78nkceav7ka@steve-laptop...
>>
>> size_t works,  it has a precedent, it's already *there*, just use it, or 
>> alias it if you  don't like it.
>>
> 
> One could make much the same argument about the whole of C++. It works, it 
> has a precedent, it's already *there*, just use it.
> 

If your only problem with C++ is related to names.. you should probably do that.

Re: Integer conversions too pedantic in 64-bit

"Steven Schveighoffer"  wrote in message 
news:op.vqx78nkceav7ka@steve-laptop...
>
> size_t works,  it has a precedent, it's already *there*, just use it, or 
> alias it if you  don't like it.
>

One could make much the same argument about the whole of C++. It works, it 
has a precedent, it's already *there*, just use it.

Re: Integer conversions too pedantic in 64-bit

"Nick Sabalausky"  wrote in message 
news:ijesem$brd$1...@digitalmars.com...
> "Steven Schveighoffer"  wrote in message 
> news:op.vqx78nkceav7ka@steve-laptop...
>>
>> size_t works,  it has a precedent, it's already *there*, just use it, or 
>> alias it if you  don't like it.
>>
>
> One could make much the same argument about the whole of C++. It works, it 
> has a precedent, it's already *there*, just use it.
>

The whole reason I came to D was because, at the time, D was more interested 
in fixing C++'s idiocy than just merely aping C++ as the theme seems to be 
now.

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 20:15, schrieb Rainer Schuetze:
> 
> I think David has raised a good point here that seems to have been lost in the
> discussion about naming.
> 
> Please note that the C name of the machine word integer was usually called
> "int". The C standard only specifies a minimum bit-size for the different 
> types
> (see for example http://www.ericgiguere.com/articles/ansi-c-summary.html). 
> Most
> of current C++ implementations have identical "int" sizes, but now "long" is
> different. This approach has failed and has caused many headaches when porting
> software from one platform to another. D has recognized this and has 
> explicitely
> defined the bit-size of the various integer types. That's good!
> 
> Now, with size_t the distinction between platforms creeps back into the
> language. It is everywhere across phobos, be it as length of ranges or size of
> containers. This can get viral, as everything that gets in touch with these
> values might have to stick to size_t. Is this really desired?
> 
> Consider saving an array to disk, trying to read it on another platform. How
> many bits should be written for the size of that array?
> 

This can indeed be a problem which actually is existent in Phobos: std.streams
Outputstream has a write(char[]) method - and similar methods for wchar and
dchar - that do exactly this: write a size_t first and then the data.. in many
places they used uint instead of size_t, but at the one method where this is a
bad idea they used size_t ;-) (see also
http://d.puremagic.com/issues/show_bug.cgi?id=5001 )

In general I think that you just have to define how you serialize data to
disk/net/whatever (what endianess, what exact types) and you won't have
problems. Just dumping the data to disk isn't portable anyway.

> Consider a range that maps the contents of a file. The file can be larger than
> 4GB, though a lot of the ranges that wrap the file mapping range will truncate
> the length to 32 bit on 32-bit platforms.
> 
> I don't have a perfect solution, but maybe builtin arrays could be limited to
> 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless signed/unsigned
> conversions), so the normal type to be used is still "int". Ranges should 
> adopt
> the type sizes of the underlying objects.
> 
> Agreed, a type for the machine word integer must exist, and I don't care how 
> it
> is called, but I would like to see its usage restricted to rare cases.
> 
> Rainer
> 

Cheers,
- Daniel

Re: Integer conversions too pedantic in 64-bit

"Adam Ruppe"  wrote in message 
news:ije0gi$18vo$1...@digitalmars.com...
> Sometimes I think we should troll the users a little and make
> a release with names like so:
>
> alias size_t
> TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;
>
> alias ptrdiff_t
> TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;
>
> alias iota lazyRangeThatGoesFromStartToFinishByTheGivenStepAmount;
>
>
> Cash money says everyone would be demanding an emergency release with
> shorter names. We'd argue for months about it... and probably settle
> back where we started.

A small software company I once worked for, Main Sequence Technologies, had 
their heads so far up their asses it was trivial for me to get posted on 
TheDailyWTF's Code Snippet of the Day (This company had a 
rather...interesting...way of creating their "else" clauses).

One of the many "Programming 101, Chapter 1" things they had a habit of 
screwing up was "Use meaningful variable names!". Throughout the codebase 
(VB6 - yea, that tells you a lot about their level of competence), there 
were variables like "aaa", "staaa", "bbb", "stbbb", "ccc", etc. Those are 
actual names they used. (I even found a file-loading function named "save".)

Needless to say, trying to understand the twisted codebase enough to 
actually do anything with it was...well, you can imagine. So I would try to 
clean things up when I could, in large part just so I could actually keep it 
all straight in my own mind.

Anyway, to bring this all back around to what you said above, there were 
times when I understood enough about a variable to know it wasn't relevant 
to whatever my main task was, and therefore didn't strictly need to go 
wasting even *more* time trying to figure out what the hell the variable 
actually did. So I ended up in the habit of just renaming those variables to 
things like:

bbb
->
thisVariableNeedsAMuchMoreMeaningfulNameThan_bbb

That was satisfying ;)

Call it "self-documenting code".

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 22:20, schrieb Nick Sabalausky:
> "Walter Bright"  wrote in message 
> news:ijeil4$2aso$3...@digitalmars.com...
>> spir wrote:
>>> Having to constantly explain that "_t" means type, that "size" does not 
>>> mean size, what this type is supposed to mean instead, what it is used 
>>> for in core and stdlib functionality, and what programmers are supposed 
>>> to use it for... isn't this a waste of our time? This, only because the 
>>> name is mindless?
>>
>> No, because there is a vast body of work that uses size_t and a vast body 
>> of programmers who know what it is and are totally used to it.
>>
> 
> And there's a vast body who don't.
> 

They've got to learn some name for it anyway, so why not size_t?
This also makes using C functions that use size_t easier/more clear.

> And there's a vast body who are used to C++, so let's just abandon D and 
> make it an implementation of C++ instead.
>

Re: Integer conversions too pedantic in 64-bit


Nick Sabalausky wrote:
"Walter Bright"  wrote in message 
news:ijeil4$2aso$3...@digitalmars.com...

spir wrote:
Having to constantly explain that "_t" means type, that "size" does not 
mean size, what this type is supposed to mean instead, what it is used 
for in core and stdlib functionality, and what programmers are supposed 
to use it for... isn't this a waste of our time? This, only because the 
name is mindless?
No, because there is a vast body of work that uses size_t and a vast body 
of programmers who know what it is and are totally used to it.




And there's a vast body who don't.

And there's a vast body who are used to C++, so let's just abandon D and 
make it an implementation of C++ instead.


I would agree that D is a complete waste of time if all it consisted of was 
renaming things.

Re: Integer conversions too pedantic in 64-bit

Am 15.02.2011 19:10, schrieb bearophile:
> Daniel Gibson:
> 
>> void main() {
>>size_t x;
>>writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and 
>> the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's 
>> ulong).
> 
> I think both typeof() and stringof are compile-time things.
> 
> And regarding lost alias information I suggest to do as Clang does:
> http://d.puremagic.com/issues/show_bug.cgi?id=5004
> 
> Bye,
> bearophile

Hmm yeah, you're probably right. After sending my reply I thought about that 
myself.
However: At the time typeof() is handled by the compiler the aliases are already
resolved.

I agree that "aka" for alias information in error-messages would be helpful in
general, but this wouldn't help here.

Re: Removed?


On 02/15/2011 07:44 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

As an aside, it's quite remarkable that such a movement and others similar
originated in the Capitalist world. History will tell, but I see it as
possible for the spirit to stay put.



It's the internet that has made large scale collaboration and cooperation
possible. On a smaller scale, it's existed before. There are many volunteer
fire departments, and many parks that get created and maintained by armies of
volunteers.

RMS clarified free software, but there was useful free software before his
movement. DECUS, for example, distributed the best of free software for DEC
machines back in the 70's. It was a feather in one's cap to have one's software
picked up by DECUS.


And this itself was made possible by the fact software /re/production costs are 
neglectable compared to production ones (human competence, time & motivation).
The same applies indeed, even more since the numeric revolution, to most of 
human knowledge and creation. Result of music composition has always been 
(potentially or concretely, depending to laws) freely available good.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit

"Jens Mueller"  wrote in message 
news:mailman.1694.1297781518.4748.digitalmar...@puremagic.com...
>
> I read that the compiler is free to return whatever name of an alias,
> i.e. either the name of the alias or the name of the thing it was
> aliased to (which can be again an alias). I do not understand the rule
> for stringof (reading
> http://www.digitalmars.com/d/2.0/property.html#stringof) but I never had
> a problem.
>

DMD itself has never really understood stringof.

Re: Integer conversions too pedantic in 64-bit

"Walter Bright"  wrote in message 
news:ijeil4$2aso$3...@digitalmars.com...
> spir wrote:
>> Having to constantly explain that "_t" means type, that "size" does not 
>> mean size, what this type is supposed to mean instead, what it is used 
>> for in core and stdlib functionality, and what programmers are supposed 
>> to use it for... isn't this a waste of our time? This, only because the 
>> name is mindless?
>
> No, because there is a vast body of work that uses size_t and a vast body 
> of programmers who know what it is and are totally used to it.
>

And there's a vast body who don't.

And there's a vast body who are used to C++, so let's just abandon D and 
make it an implementation of C++ instead.

Re: Integer conversions too pedantic in 64-bit

"bearophile"  wrote in message 
news:ijefj9$25sm$1...@digitalmars.com...
> Daniel Gibson:
>
>> void main() {
>>size_t x;
>>writefln(typeof(x).stringof);
>> }
>> try this, too ;-)
>>
>> Because it's an alias the information about size_t gone at runtime and
>> the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's
>> ulong).
>
> I think both typeof() and stringof are compile-time things.
>
> And regarding lost alias information I suggest to do as Clang does:
> http://d.puremagic.com/issues/show_bug.cgi?id=5004
>

That would *really* be nice. In my Goldie parsing lib, I make heavy use of 
templated aliases to provide maximally-reader-friendly types for 
strongly-typed tokens (ie, if the programmer desires, each symbol and each 
production rule has its own type, to ensure maximum compile-time safety). 
These aliases wrap much less readable internal types. Expecting the user to 
understand the internal type for any error message is not nice.

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 03:25 PM, Daniel Gibson wrote:

Am 15.02.2011 15:18, schrieb spir:

On 02/15/2011 02:01 PM, Daniel Gibson wrote:

Am 15.02.2011 12:50, schrieb spir:

On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:

spir wrote:

Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)


Maybe ptrint and ptruint?


If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while "size" may suggest it, .length
does not return a size_t but an uint.

Denis


.length of what? An array?
I'm pretty sure it returns size_t.


unittest {
int[] ints; auto l = ints.length;
writeln(typeof(l).stringof);
}
press play ;-)

denis


void main() {
size_t x;
writefln(typeof(x).stringof);
}
try this, too ;-)

Because it's an alias the information about size_t gone at runtime and the
"real" type is shown. uint in your case. (Here - gdc on amd64 - it's ulong).


Oops, you're right! had not realised yet names are de-aliased on output.

denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Steven Schveighoffer

On Tue, 15 Feb 2011 14:15:06 -0500, Rainer Schuetze   
wrote:




I think David has raised a good point here that seems to have been lost  
in the discussion about naming.


Please note that the C name of the machine word integer was usually  
called "int". The C standard only specifies a minimum bit-size for the  
different types (see for example  
http://www.ericgiguere.com/articles/ansi-c-summary.html). Most of  
current C++ implementations have identical "int" sizes, but now "long"  
is different. This approach has failed and has caused many headaches  
when porting software from one platform to another. D has recognized  
this and has explicitely defined the bit-size of the various integer  
types. That's good!


Now, with size_t the distinction between platforms creeps back into the  
language. It is everywhere across phobos, be it as length of ranges or  
size of containers. This can get viral, as everything that gets in touch  
with these values might have to stick to size_t. Is this really desired?


Do you really want portable code?  The thing is, size_t is specifically  
defined to be *the word size* whereas C defines int as a fuzzy size  
"should be at least 16 bits, and recommended to be equivalent to the  
natural size of the machine".  size_t is *guaranteed* to be the same size  
on the same platform, even among different compilers.


In addition size_t isn't actually defined by the compiler.  So the library  
controls the size of size_t, not the compiler.  This should make it  
extremely portable.


Consider saving an array to disk, trying to read it on another platform.  
How many bits should be written for the size of that array?


It depends on the protocol or file format definition.  It should be  
irrelevant what platform/architecture you are on.  Any format or protocol  
worth its salt will define what size integers you should store.


Then you need a protocol implementation that converts between the native  
size and the stored size.


This is just like network endianness vs. host endianness.  You always use  
htonl and ntohl even if your platform has the same endianness as the  
network, because you want your code to be portable.  Not using them is a  
no-no even if it works fine on your big-endian system.


I don't have a perfect solution, but maybe builtin arrays could be  
limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless  
signed/unsigned conversions), so the normal type to be used is still  
"int". Ranges should adopt the type sizes of the underlying objects.


No, this is too limiting.  If I have 64GB of memory (not out of the  
question), and I want to have a 5GB array, I think I should be allowed  
to.  This is one of the main reasons to go to 64-bit in the first place.


-Steve

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 08:05 PM, Walter Bright wrote:

foobar wrote:

1. that size_t is inconsistent with D's style guide. the "_t" suffix is a C++
convention and not a D one. While it makes sense for [former?] C++
programmers it will confuse newcomers to D from other languages that would
expect the language to follow its own style guide.


It's a C convention.


2. the proposed change is backwards compatible - the OP asked for an
*additional* alias.


I do not believe that value is added by adding more and more aliases for the
same thing. It makes the library large and complex but with no depth.


If we asked for various aliases for numerous builtin terms of the language, 
your point would be fully valid. But here is only asked for a single standard 
alias for what may well be the most used type in the language; which presently 
has a obscure alias name.

Cost: one line of code in object.d:
alias typeof(int.sizeof)size_t;
alias typeof(int.sizeof)Abcdef; // add this

As an aside, the opportunity may be taken to use machine-word-size signed 
values as a standard for indices/positions and sizes/counts/lengths (and 
offsets?), everywhere in the language, for the coming 64-bit version. Don, 
IIRC, and Bearophile, referred to issues due to unsigned values.
This would also give an obvious name for the alias, "Integer", that probably 
few would contest (hope so).


Denis
--
_
vita es estrany
spir.wikidot.com

digitalmars-d@puremagic.com


On 15/02/11 7:55 PM, Jonathan M Davis wrote:

On Tuesday, February 15, 2011 11:48:25 Peter Alexander wrote:

Do D const references work the same as C++'s?

i.e.
- Can they bind to rvalues?
- Do they extend the life of rvalues?

If they do, are there any differences from C++?

If they don't, how do I pass large structs into a function efficiently?


The only bind to lvalues. A ref is a reference to a variable, so normal ref has
to be passed a variable. In C++, it was decided that const&  was special and
could take a temporary. In D, it's no different from ref except that it's const,
so it can't be changed. There have been requests to fix this, but Andrei is
adamant that it was a huge mistake in C++ to do it since it makes it so that you
can't determine whether a const&  is really a rvalue or an lvalue. I don't know
enough to know how much that really matters, but apparently it causes problems.
The result is that D doesn't do that, which can be rather annoying when trying
to pass temporaries to functions which take const ref, but that's the way it
goes.

If you want to pass a large struct to a function efficiently, and you know that
function isn't going to need to alter the struct, make it const ref. That way,
it's const, and it doesn't get copied. However, that means that you can't pass
temporaries to it. However, if you need to pass a temporary, then you're going
to have to actually assign it to a variable first.

I _thought_ tht you could define a cost ref version and a non-const ref version
and it would call the const ref version on lvalues and the non-const ref version
on rvalues, but when I just tried it, it seems to call the non-const ref version
in both cases. I don't know if that's a bug or not. But if you just have a const
ref version, and you create a variable where you'd normally use a temporary,
you'll be fine.

- Jonathan M Davis


Surely this is a major usability issue? I have to create a new local 
variable just so that I can pass structs round efficiently (either that 
or change the struct to have COW or ref semantics, both of which are 
unacceptable).

digitalmars-d@puremagic.com

On Tuesday, February 15, 2011 11:48:25 Peter Alexander wrote:
> Do D const references work the same as C++'s?
> 
> i.e.
> - Can they bind to rvalues?
> - Do they extend the life of rvalues?
> 
> If they do, are there any differences from C++?
> 
> If they don't, how do I pass large structs into a function efficiently?

The only bind to lvalues. A ref is a reference to a variable, so normal ref has 
to be passed a variable. In C++, it was decided that const& was special and 
could take a temporary. In D, it's no different from ref except that it's 
const, 
so it can't be changed. There have been requests to fix this, but Andrei is 
adamant that it was a huge mistake in C++ to do it since it makes it so that 
you 
can't determine whether a const& is really a rvalue or an lvalue. I don't know 
enough to know how much that really matters, but apparently it causes problems. 
The result is that D doesn't do that, which can be rather annoying when trying 
to pass temporaries to functions which take const ref, but that's the way it 
goes.

If you want to pass a large struct to a function efficiently, and you know that 
function isn't going to need to alter the struct, make it const ref. That way, 
it's const, and it doesn't get copied. However, that means that you can't pass 
temporaries to it. However, if you need to pass a temporary, then you're going 
to have to actually assign it to a variable first.

I _thought_ tht you could define a cost ref version and a non-const ref version 
and it would call the const ref version on lvalues and the non-const ref 
version 
on rvalues, but when I just tried it, it seems to call the non-const ref 
version 
in both cases. I don't know if that's a bug or not. But if you just have a 
const 
ref version, and you create a variable where you'd normally use a temporary, 
you'll be fine.

- Jonathan M Davis

Re: tooling quality and some random rant


Don wrote:

Walter Bright wrote:

Don wrote:
In hand-coded asm, instruction scheduling still gives more than half 
of the same benefit that it used to do. But, it's become ten times 
more difficult. You have to use Agner Fog's manuals, not Intel/AMD.


For example:
(1) a common bottleneck on all Intel processors, is that you can only 
read from three registers per cycle, but you can also read from any 
register which has been modified in the last three cycles.

(2) it's important to break dependency chains.

On the BigInt code, instruction scheduling gave a speedup of ~40%.


Wow. I didn't know that. Do any compilers currently schedule this stuff?


Intel probably does. I don't think any others do a very good job. Agner 
told me that he had had no success in getting compiler vendors to be 
interested in his work.


Well, this one is. In fact, could we get Agner to actively help us out with 
this?


Any chance you want to take a look at cgsched.c? I had great success 
using the same algorithm for the quite different Pentium and P6 
scheduling minutia.


That would really be fun.
BTW, the current Intel processors are basically the same as Pentium Pro, 
with a few improvements. The strange thing is, because of all of the 
reordering that happens, swapping the order of two (non-dependent) 
instructions makes no difference at all. So you always need to look at 
every instruction in the a loop, before you can do any scheduling.


I was looking at Agner's document, and it looks like ordering the instructions 
in the 4-1-1 or 4-1-1-1 for optimal decoding could work. This would fit right in 
with the way the scheduler works.


I had thought that with the CPU automatically reordering instructions, that 
scheduling them was obsolete.

Re: tooling quality and some random rant

retard wrote:

> Mon, 14 Feb 2011 20:10:47 +0100, Lutger Blijdestijn wrote:
> 
>> retard wrote:
>> 
>>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote:
>>> 
> Unfortunately DMC is always out of the question because the
> performance is 10-20 (years) behind competition, fast compilation
> won't help it.
 
 Can you please give a few links on this?
>>> 
>>> What kind of proof you need then? Just take some existing piece of code
>>> with high performance requirements and compile it with dmc. You lose.
>>> 
>>> http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html
>>> http://permalink.gmane.org/gmane.comp.lang.c++.perfometer/37
>>> http://lists.boost.org/boost-testing/2005/06/1520.php
>>> http://www.digitalmars.com/d/archives/c++/chat/66.html
>>> http://www.drdobbs.com/cpp/184405450
>>> 
>>> 
>> That is ridiculous, have you even bothered to read your own links? In
>> some of them dmc wins, others the differences are minimal and for all of
>> them dmc is king in compilation times.
> 
> DMC doesn't clearly win in any of the tests and these are merely some
> naive examples I found by doing 5 minutes of googling. Seriously, take a
> closer look - the gcc version is over 5 years old. Nobody even bothers
> doing dmc benchmarks anymore, dmc is so out of the league. I repeat, this
> was about performance of the generated binaries, not compile times.
> 
> Like I said: take some existing piece of code with high performance
> requirements and compile it with dmc. You lose. I honestly don't get what
> I need to prove here. Since you have no clue, presumably you aren't even
> using dmc and won't be considering it.

You go on ranting about dmc as if it is dwarfed by other compilers (which it 
might very well be), then provide 'proof' that doesn't prove this at all and 
now I must be convinced that it's because the other compilers are so old? 
You lose. You don't have to prove anything, but when you do, don't do it 
with dubious and inconclusive benchmarks. That's all.

Re: appendToFront semantics

Torarin:
> But isn't the reason you're supplying a value to appendToFront that
> you do want a specific amount?

I figured it was just to give precision control over memory usage...

digitalmars-d@puremagic.com


Do D const references work the same as C++'s?

i.e.
- Can they bind to rvalues?
- Do they extend the life of rvalues?

If they do, are there any differences from C++?

If they don't, how do I pass large structs into a function efficiently?

Thanks

Re: shared libraries in D

2011-02-15 Thread Jacob Carlborg


On 2011-02-15 16:02, Johannes Pfau wrote:

Iain Buclaw wrote:

Came across this obscure documentation in the tldp.

"Libraries should export initialization and cleanup routines using the
gcc __attribute__((constructor)) and __attribute__((destructor))
function attributes."

This is what gdc was doing anyway.


"Constructor routines are executed before dlopen returns (or before
main() is started if the library is loaded at load time). Destructor
routines are executed before dlclose returns (or after exit() or
completion of main() if the library is loaded at load time)."

This is what should have been happening, but wasn't earlier because:


"Shared libraries must not be compiled with the gcc arguments
`-nostartfiles' or `-nostdlib'. If those arguments are used, the
constructor/destructor routines will not be executed (unless special
measures are taken)."

Whoops! Fixed and it now works. :~)

Will be making shared libraries default in GDC pretty soon now...


Great, now I've got 2 questions:

1.) Are shared libraries compiled with gdc abi compitible with dmd?
(if dmd did support shared libraries)


I'm not completely sure but the runtimes are different.


2.) Is it now possible to load a shared d library into a C program? Will
jut loading the library initialize the runtime or is it necessary to
call some runtime setup functions manually? If the C program loads 2 D
libraries, will those share the gc/runtime?


I don't know how Iain has implemented this but it should be easy to do. 
Just add, to the runtime, a C function with __attribute__((constructor)) 
that initializes the runtime.


--
/Jacob Carlborg

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread so


I disagree that the discussion is pointless.
On the contrary, the OP pointed out some valid points:

1.  that size_t is inconsistent with D's style guide. the "_t" suffix is  
a C++ convention and not a D one. While it makes sense for [former?] C++  
programmers it will confuse newcomers to D from other languages that  
would expect the language to follow its own style guide.
2. the proposed change is backwards compatible - the OP asked for an  
*additional* alias.
3. generic concepts should belong to the standard library and not user  
code which is also where size_t is already defined.


IMO, we already have a byte type, it's plain common sense to extend this  
with a "native word" type.


Funny thing is the most important argument against size_t got the least  
attention.

I will leave it as an exercise for the reader.

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Rainer Schuetze



I think David has raised a good point here that seems to have been lost 
in the discussion about naming.


Please note that the C name of the machine word integer was usually 
called "int". The C standard only specifies a minimum bit-size for the 
different types (see for example 
http://www.ericgiguere.com/articles/ansi-c-summary.html). Most of 
current C++ implementations have identical "int" sizes, but now "long" 
is different. This approach has failed and has caused many headaches 
when porting software from one platform to another. D has recognized 
this and has explicitely defined the bit-size of the various integer 
types. That's good!


Now, with size_t the distinction between platforms creeps back into the 
language. It is everywhere across phobos, be it as length of ranges or 
size of containers. This can get viral, as everything that gets in touch 
with these values might have to stick to size_t. Is this really desired?


Consider saving an array to disk, trying to read it on another platform. 
How many bits should be written for the size of that array?


Consider a range that maps the contents of a file. The file can be 
larger than 4GB, though a lot of the ranges that wrap the file mapping 
range will truncate the length to 32 bit on 32-bit platforms.


I don't have a perfect solution, but maybe builtin arrays could be 
limited to 2^^32-1 elements (or maybe 2^^31-1 to get rid of endless 
signed/unsigned conversions), so the normal type to be used is still 
"int". Ranges should adopt the type sizes of the underlying objects.


Agreed, a type for the machine word integer must exist, and I don't care 
how it is called, but I would like to see its usage restricted to rare 
cases.


Rainer


dsimcha wrote:

Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
of code to compile in 64 mode.  Frankly, the compiler is way too freakin'
pedantic when it comes to implicit conversions (or lack thereof) of
array.length.  99.999% of the time it's safe to assume an array is not going
to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the
time than deal with the pedantic errors the rest of the time, because I think
it would be less total time and effort invested.  To force me to either put
casts in my code everywhere or change my entire codebase to use wider integers
(with ripple effects just about everywhere) strikes me as purity winning out
over practicality.

Re: Integer conversions too pedantic in 64-bit


foobar wrote:
1.  that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ convention and not a D one. While it makes sense for [former?] C++ programmers it will confuse newcomers to D from other languages that would expect the language to follow its own style guide. 


It's a C convention.


2. the proposed change is backwards compatible - the OP asked for an 
*additional* alias.


I do not believe that value is added by adding more and more aliases for the 
same thing. It makes the library large and complex but with no depth.

Re: Integer conversions too pedantic in 64-bit


spir wrote:
Having to constantly explain that "_t" means type, that "size" does not 
mean size, what this type is supposed to mean instead, what it is used 
for in core and stdlib functionality, and what programmers are supposed 
to use it for... isn't this a waste of our time? This, only because the 
name is mindless?


No, because there is a vast body of work that uses size_t and a vast body of 
programmers who know what it is and are totally used to it.

Re: Removed? (Wikipedia deletionism)


Aaron Smith wrote:

although he's not widely considered a genius unlike the
authors of Factor and LuaJIT and Walter Bright.


Actually, I'm quite famous for being incompetent.

Re: Removed?


spir wrote:
That guy, if sincere, thought the content he asked for deletion was not 
useful, certainly, since it apparently did not get any mention from 
third-party sources. (actually, there lots of articles about some of 
those Pls, but no one had cared about linking to them, so that guy was 
right)


I think he was quite sincere, and thought he was doing a public service.

Re: Removed?


Andrei Alexandrescu wrote:
As an aside, it's quite remarkable that such a movement and others 
similar originated in the Capitalist world. History will tell, but I see 
it as possible for the spirit to stay put.



It's the internet that has made large scale collaboration and cooperation 
possible. On a smaller scale, it's existed before. There are many volunteer fire 
departments, and many parks that get created and maintained by armies of volunteers.


RMS clarified free software, but there was useful free software before his 
movement. DECUS, for example, distributed the best of free software for DEC 
machines back in the 70's. It was a feather in one's cap to have one's software 
picked up by DECUS.

Re: appendToFront semantics

2011-02-15 Thread Torarin

2011/2/15 Adam Ruppe :
> One problem with "at least" is it might have to wait for two
> packets to come off the network interface; could be fairly slow.
>
> The "at most" means it will take whatever is available without
> overflowing your buffer - it will never wait if there is any
> data available.
>

But isn't the reason you're supplying a value to appendToFront that
you do want a specific amount? If not, you can use appendToFront(0)
until you get what you want.

Torarin

Re: appendToFront semantics

One problem with "at least" is it might have to wait for two
packets to come off the network interface; could be fairly slow.

The "at most" means it will take whatever is available without
overflowing your buffer - it will never wait if there is any
data available.

Re: Integer conversions too pedantic in 64-bit

Daniel Gibson:

> void main() {
>size_t x;
>writefln(typeof(x).stringof);
> }
> try this, too ;-)
> 
> Because it's an alias the information about size_t gone at runtime and 
> the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's 
> ulong).

I think both typeof() and stringof are compile-time things.

And regarding lost alias information I suggest to do as Clang does:
http://d.puremagic.com/issues/show_bug.cgi?id=5004

Bye,
bearophile

appendToFront semantics

2011-02-15 Thread Torarin

I've been experimenting with Andrei's buffered input range and noticed
that appendToFront(size_t n) may benefit from a slightly different
definition.

Andrei describes it as appending at most n elements to the front. But
if you change that to "at least", the range can ask the underlying
stream to also fill any unused space in the buffer.

If unused space is available before doing the append, this can also be
achieved by doing appendToFront(0) until you reach the desired
front.length. But if that leads to a move of buffered data, it becomes
less efficient than it could be.

The change means you would lose the ability to limit the amount read
from the underlying stream, which could be useful for a e.g. a
protocol switch, but I'm inclined to think that's less important than
the efficiency of the common case.

Did I miss the reason why this doesn't work well?

Torarin

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread foobar

Steven Schveighoffer Wrote:

> On Tue, 15 Feb 2011 09:26:21 -0500, spir  wrote:
> 
> > On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:
> 
> >>
> >> Hey, bikeshedders, I found this cool easter-egg feature in D! It's  
> >> called
> >> alias! Don't like the name of something? Well you can change it!
> >>
> >> alias size_t wordsize;
> >>
> >> Now, you can use wordsize instead of size_t in your code, and the  
> >> compiler
> >> doesn't care! (in fact, that's all size_t is anyways *hint hint*)
> >
> > Sure, but it's not the point of this one bikeshedding thread. If you do  
> > that, then you're the only one who knows what "wordsize" means. Good,  
> > maybe, for app-specific semantic notions (alias Employee[] Staff;);  
> > certainly not for types at the highest degree of general purpose like  
> > size_t. We need a standard alias.
> 
> The standard alias is size_t.  If you don't like it, alias it to something  
> else.  Why should I have to use something that's unfamiliar to me because  
> you don't like size_t?
> 
> I guarantee whatever you came up with would not be liked by some people,  
> so they would have to alias it, you can't please everyone.  size_t works,  
> it has a precedent, it's already *there*, just use it, or alias it if you  
> don't like it.
> 
> No offense, but this discussion is among the most pointless I've seen.
> 
> -Steve

I disagree that the discussion is pointless. 
On the contrary, the OP pointed out some valid points:

1.  that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ 
convention and not a D one. While it makes sense for [former?] C++ programmers 
it will confuse newcomers to D from other languages that would expect the 
language to follow its own style guide. 
2. the proposed change is backwards compatible - the OP asked for an 
*additional* alias.
3. generic concepts should belong to the standard library and not user code 
which is also where size_t is already defined. 

IMO, we already have a byte type, it's plain common sense to extend this with a 
"native word" type.

Re: inlining or not inlining...

2011-02-15 Thread Stewart Gordon


On 11/02/2011 06:35, Walter Bright wrote:


I hate not being able to force functions to be inline. A consequence is that 
you can't
fully interface certain APIs without an extra .lib over what would be needed in 
C(++).


You cannot force inlining in C(++) either. The inline keyword is only a 
suggestion.


But is the inline keyword guaranteed to prevent a duplicate symbol error at link time when 
multiple modules contain this same function after preprocessing?



I'm not understanding your last comment that a .lib would be required. That's 
not correct,
as since you're supplying the full source anyway (needed for inlining), just 
compile in
that source from the command line. No lib step is needed.


OK, so a .lib isn't strictly necessary, a .obj will do.  But for an example of what I'm on 
about, consider the many #define macros in the C headers of the Windows API.  In D, these 
become functions, and you can't tell the compiler to inline them.  Therefore you have to 
compile the Windows API bindings as modules in their own right, and then link them in, 
whereas in C(++) you need only to compile and link your own source files (along with a few 
standard Windows .libs).


Consequently, all these functions might end up in the .exe even though they are never 
used, either because the application code never uses them or because the compiler has 
inlined them where they are used.


Stewart.

Re: tooling quality and some random rant

2011-02-15 Thread Don

bearophile wrote:

Walter:

Huh, I simply could never find a document about how to use those which gave me any
comfortable sense that the author knew what he was talking about.<

http://www.agner.org/optimize/

Don:

A problem with that, is that the prefetching instructions are vendor-specific.<

Right. Then I suggest some higher-level annotations (pragmas?) that the
programmer uses to better state the temporal semantics of memory accesses in a
performance-critical part of D code.

Also, it's quite difficult to use them correctly. If you put them in the wrong
place, or use them too much, they slow your code down.<

CPU caches have a simple purpose. Light speed is finite (how much distance does light travel in vacuum/doped silicon during a clock cycle of a 5 GHz POWER6 CPU? http://en.wikipedia.org/wiki/POWER6 ), and finding one thing among many things is slower than finding among few ones. So you speed up your memory accesses if you read information from a smaller group of data located closer to you. Most CPUs don't have a little faster memory that you manage yourself (http://en.wikipedia.org/wiki/Scratchpad_RAM ), the CPUs copy data from/to cache levels by themselves, so on such CPUs the illusion of a flat memory is at the hardware level, not just at C language level. Cache manage their memory in few different ways, often bigger CPUs offer ways to alter such ways a little, using special instructions.

The main difference is how they keep coherence across different core
caches and in what situations they store back data from the cache to RAM.

I think you may be confusing prefetch instructions with non-temporal stores.

The problem with prefetch instructions, is that they interfere with the
hardware prefetch mechanism. The hardware prefetch is actually very
good, and it's only under specific circumstances that a manual prefetch
can beat it. I think it's unlikely that you can use prefetching
beneficially, unless you've looked at the generated asm code.

In some cases in your program you want to read from an array, and store data inside it
again and another one too, but you never want to store far away data in the first one.
There are few other common patterns of memory usage. In theory a normal language like
Fortran is enough to specify what memory you want to read or write and when you want to
do it. In practice today compilers are not so good at inferring such semantics, so some
high level annotations probably help. In future maybe compilers will get better, so they
will ignore those annotations, just like they often ignore "register"
annotations. Being system-level programming languages practical things, adding
annotations is not bad, even if 5-10 years later those annotations become less useful.

Here you're definitely talking about non-temporal stores.
Yes, there is some chance that an annotation for non-temporal stores
could be beneficial.

Re: shared libraries in D

2011-02-15 Thread Johannes Pfau

Iain Buclaw wrote:
>Came across this obscure documentation in the tldp.
>
>"Libraries should export initialization and cleanup routines using the
>gcc __attribute__((constructor)) and __attribute__((destructor))
>function attributes."
>
>This is what gdc was doing anyway.
>
>
>"Constructor routines are executed before dlopen returns (or before
>main() is started if the library is loaded at load time). Destructor
>routines are executed before dlclose returns (or after exit() or
>completion of main() if the library is loaded at load time)."
>
>This is what should have been happening, but wasn't earlier because:
>
>
>"Shared libraries must not be compiled with the gcc arguments
>`-nostartfiles' or `-nostdlib'. If those arguments are used, the
>constructor/destructor routines will not be executed (unless special
>measures are taken)."
>
>Whoops! Fixed and it now works. :~)
>
>Will be making shared libraries default in GDC pretty soon now...

Great, now I've got 2 questions:

1.) Are shared libraries compiled with gdc abi compitible with dmd?
(if dmd did support shared libraries)

2.) Is it now possible to load a shared d library into a C program? Will
jut loading the library initialize the runtime or is it necessary to
call some runtime setup functions manually? If the C program loads 2 D
libraries, will those share the gc/runtime?

-- 
Johannes Pfau


signature.asc
Description: PGP signature

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Iain Buclaw

== Quote from dsimcha (dsim...@yahoo.com)'s article
> Now that DMD has a 64-bit beta available, I'm working on getting a whole bunch
> of code to compile in 64 mode.  Frankly, the compiler is way too freakin'
> pedantic when it comes to implicit conversions (or lack thereof) of
> array.length.  99.999% of the time it's safe to assume an array is not going
> to be over 4 billion elements long.  I'd rather have a bug the 0.001% of the
> time than deal with the pedantic errors the rest of the time, because I think
> it would be less total time and effort invested.  To force me to either put
> casts in my code everywhere or change my entire codebase to use wider integers
> (with ripple effects just about everywhere) strikes me as purity winning out
> over practicality.

I have a similar grudge about short's being implicitly converted to int's,
resulting in hundreds of unwanted casts thrown in everywhere cluttering up code.

ie:
   short a,b,c,;
   a = b + c;

Hidden implicit casts should die.

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Jens Mueller

spir wrote:
> On 02/15/2011 02:01 PM, Daniel Gibson wrote:
> >Am 15.02.2011 12:50, schrieb spir:
> >>On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:
> >>>spir wrote:
> Rename size-t, or rather introduce a meaningful standard alias? (would
> vote for Natural)
> >>>
> >>>Maybe ptrint and ptruint?
> >>
> >>If ptr means pointer, then it's wrong: size-t is used for more than
> >>that, I guess. Strangely enough, while "size" may suggest it, .length
> >>does not return a size_t but an uint.
> >>
> >>Denis
> >
> >.length of what? An array?
> >I'm pretty sure it returns size_t.
> 
> unittest {
> int[] ints; auto l = ints.length;
> writeln(typeof(l).stringof);
> }
> press play ;-)

I do not get it.
The above returns uint which is fine because my dmd v2.051 is 32-bit
only. I.e. size_t is an alias to uint (see src/druntime/src/object_.d
lin 52).
But somehow I think you are implying it does not return size_t.
This is right in the sense that it does not return the alias name size_t
but it returns the aliased type name, namely uint. What's the problem?
This
writeln(size_t.stringof);
also returns uint.
I read that the compiler is free to return whatever name of an alias,
i.e. either the name of the alias or the name of the thing it was
aliased to (which can be again an alias). I do not understand the rule
for stringof (reading
http://www.digitalmars.com/d/2.0/property.html#stringof) but I never had
a problem.

Jens

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Steven Schveighoffer


On Tue, 15 Feb 2011 09:26:21 -0500, spir  wrote:


On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:




Hey, bikeshedders, I found this cool easter-egg feature in D! It's  
called

alias! Don't like the name of something? Well you can change it!

alias size_t wordsize;

Now, you can use wordsize instead of size_t in your code, and the  
compiler

doesn't care! (in fact, that's all size_t is anyways *hint hint*)


Sure, but it's not the point of this one bikeshedding thread. If you do  
that, then you're the only one who knows what "wordsize" means. Good,  
maybe, for app-specific semantic notions (alias Employee[] Staff;);  
certainly not for types at the highest degree of general purpose like  
size_t. We need a standard alias.


The standard alias is size_t.  If you don't like it, alias it to something  
else.  Why should I have to use something that's unfamiliar to me because  
you don't like size_t?


I guarantee whatever you came up with would not be liked by some people,  
so they would have to alias it, you can't please everyone.  size_t works,  
it has a precedent, it's already *there*, just use it, or alias it if you  
don't like it.


No offense, but this discussion is among the most pointless I've seen.

-Steve

Re: Removed? (Wikipedia deletionism)


Am 15.02.2011 15:11, schrieb spir:

On 02/15/2011 01:36 PM, Aaron Smith wrote:

spir Wrote:


On 02/15/2011 02:25 AM, bearophile wrote:

D is much much more notable than Nemerle, Alice ML, Pure, Nosica,
Kiev, Einstein, Alma-0, Joy, Zonnon, Y, Cat, Fancy, Ambi, Ptolemy,
Mythryl, COMIT, Ioke, EASY, Aikido, A+, Adenine, Afnix, Bsisith,
ChinesePython, AngelScript, Algae, Agena, Taxi, Inger, Iota, Jot,
Agora, Falcon, Averest, Lava, Factor, Glagol. These all have been
deleted by the same editor.

Nemerle, Factor, and few others need to be put back in Wikipedia.


The issue is: who judges what needs to be put? If we agree the notoriety
criterion is not only not good enough, but simply bad, in numerous
domains (not
only PLs), then what can be used? What criterion can be used,
especially, to
/remove/ articles?
Possibly the most interesting& earth-shaking language of all ever
invented is
among these ones. It is obviously hard to find one criterion, in any
domain
involving design, creativity and/or research, don't you think?


If you're actively participating in language development, you should
at least know Factor, Nemerle, and Alice ML. The author of Cat also
has a strong online presence although he's not widely considered a
genius unlike the authors of Factor and LuaJIT and Walter Bright.
Slava Pestov is a real world hardcore badass developer and his Factor
is *The* stack language to rule them all.


I do agree (and have actually read docs by Slave Pestov); but how does
this /judgement/ of yours help and solving the issue? Or do you mean you
should be the one deciding? If we ask true language enthusiasts, they
would see no good reason in removing any language from the above list,
don't you think (aside lang wars)? The same applies to the hundreds of
articles about pokemons. And their fans are as right as us. And they can
more easily point to external references than us ;-)

Denis


Who cares. *If*, for some reason, you want information about one of the 
more unknown/esoteric languages or a specific pokemon it's handy to be 
able to look it up at wikipedia. They can add a "this article is about a 
potentially uninteresting topic and is not reviewed to be correct" tag 
if they want, but what's the point in deleting it.. it's better to have 
*some* information and links than nothing.
Imagine D being a totally new and unknown language. Not notable for 
their standards.. now you nevertheless hear about it and want to find 
out about it. What will you do? google it? Haha, have fun googling "D".. 
You'd be glad if there were a small Wikipedia article with a Hello World 
example and a link to the D homepage and possibly other ressources...


It's the same for other languages.. google "Factor" or "Alice ML" - it's 
quite probable that you won't find what you need.
(And if you do it is because these languages are not completely unknown 
anymore).

Re: Integer conversions too pedantic in 64-bit


Am 15.02.2011 15:18, schrieb spir:

On 02/15/2011 02:01 PM, Daniel Gibson wrote:

Am 15.02.2011 12:50, schrieb spir:

On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:

spir wrote:

Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)


Maybe ptrint and ptruint?


If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while "size" may suggest it, .length
does not return a size_t but an uint.

Denis


.length of what? An array?
I'm pretty sure it returns size_t.


unittest {
int[] ints; auto l = ints.length;
writeln(typeof(l).stringof);
}
press play ;-)

denis


void main() {
  size_t x;
  writefln(typeof(x).stringof);
}
try this, too ;-)

Because it's an alias the information about size_t gone at runtime and 
the "real" type is shown. uint in your case. (Here - gdc on amd64 - it's 
ulong).


Cheers,
- Daniel

Re: Integer conversions too pedantic in 64-bit

spir wrote:
> press play

Since size_t is an alias, you wouldn't see it's name anywhere
except the source code.

Re: Removed? (Wikipedia deletionism)


On 02/15/2011 01:36 PM, Aaron Smith wrote:

spir Wrote:


On 02/15/2011 02:25 AM, bearophile wrote:

D is much much more notable than Nemerle, Alice ML, Pure, Nosica, Kiev, 
Einstein, Alma-0, Joy, Zonnon, Y, Cat, Fancy, Ambi, Ptolemy, Mythryl, COMIT, 
Ioke, EASY, Aikido, A+, Adenine, Afnix, Bsisith, ChinesePython, AngelScript, 
Algae, Agena, Taxi, Inger, Iota, Jot, Agora, Falcon, Averest, Lava, Factor, 
Glagol. These all have been deleted by the same editor.

Nemerle, Factor, and few others need to be put back in Wikipedia.


The issue is: who judges what needs to be put? If we agree the notoriety
criterion is not only not good enough, but simply bad, in numerous domains (not
only PLs), then what can be used? What criterion can be used, especially, to
/remove/ articles?
Possibly the most interesting&  earth-shaking language of all ever invented is
among these ones. It is obviously hard to find one criterion, in any domain
involving design, creativity and/or research, don't you think?


If you're actively participating in language development, you should at least 
know Factor, Nemerle, and Alice ML. The author of Cat also has a strong online 
presence although he's not widely considered a genius unlike the authors of 
Factor and LuaJIT and Walter Bright. Slava Pestov is a real world hardcore 
badass developer and his Factor is *The* stack language to rule them all.


I do agree (and have actually read docs by Slave Pestov); but how does this 
/judgement/ of yours help and solving the issue? Or do you mean you should be 
the one deciding? If we ask true language enthusiasts, they would see no good 
reason in removing any language from the above list, don't you think (aside 
lang wars)? The same applies to the hundreds of articles about pokemons. And 
their fans are as right as us. And they can more easily point to external 
references than us ;-)


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 02:36 PM, Steven Schveighoffer wrote:

On Mon, 14 Feb 2011 20:58:17 -0500, Nick Sabalausky  wrote:


"Jonathan M Davis"  wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...

On Monday, February 14, 2011 17:06:43 spir wrote:


Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for Natural)


Why? size_t is what's used in C++. It's well known and what lots of
programmers
would expect What would you gain by renaming it?



Although I fully realize how much this sounds like making a big deal out of
nothing, to me, using "size_t" has always felt really clumsy and awkward. I
think it's partly because of using an underscore in such an otherwise short
identifier, and partly because I've been aware of size_t for years and still
don't have the slightest clue WTF that "t" means. Something like "wordsize"
would make a lot more sense and frankly feel much nicer.

And, of course, there's a lot of well-known things in C++ that D
deliberately destroys. D is a different language, it may as well do things
better.


Hey, bikeshedders, I found this cool easter-egg feature in D! It's called
alias! Don't like the name of something? Well you can change it!

alias size_t wordsize;

Now, you can use wordsize instead of size_t in your code, and the compiler
doesn't care! (in fact, that's all size_t is anyways *hint hint*)


Sure, but it's not the point of this one bikeshedding thread. If you do that, 
then you're the only one who knows what "wordsize" means. Good, maybe, for 
app-specific semantic notions (alias Employee[] Staff;); certainly not for 
types at the highest degree of general purpose like size_t. We need a standard 
alias.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: Integer conversions too pedantic in 64-bit


On 02/15/2011 02:01 PM, Daniel Gibson wrote:

Am 15.02.2011 12:50, schrieb spir:

On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:

spir wrote:

Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)


Maybe ptrint and ptruint?


If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while "size" may suggest it, .length
does not return a size_t but an uint.

Denis


.length of what? An array?
I'm pretty sure it returns size_t.


unittest {
int[] ints; auto l = ints.length;
writeln(typeof(l).stringof);
}
press play ;-)

denis
--
_
vita es estrany
spir.wikidot.com

Re: Removed? (Wikipedia deletionism)


On 02/15/2011 01:22 PM, Aaron Smith wrote:

Vladimir Panteleev Wrote:


On Tue, 15 Feb 2011 03:00:59 +0200, Aaron Smith  wrote:


Thank god we have TDPL, otherwise the D page would quickly lose this
battle. D is much much more notable than Nemerle, Alice ML, Pure,
Nosica, Kiev, Einstein, Alma-0, Joy, Zonnon, Y, Cat, Fancy, Ambi,
Ptolemy, Mythryl, COMIT, Ioke, EASY, Aikido, A+, Adenine, Afnix,
Bsisith, ChinesePython, AngelScript, Algae, Agena, Taxi, Inger, Iota,
Jot, Agora, Falcon, Averest, Lava, Factor, Glagol. These all have been
deleted by the same editor.


Not necessarily defending his actions, but speaking personally not one of
these languages rings a bell to me, while I've heard of D in contexts
otherwise unrelated to D several times.


I'm just saying you should have some sort of a track record of writing quality 
articles /and/ possibly real world competence before getting the permission to 
remove content, especially if you're hunting down over 35 articles on short 
notice.

The Wikipedia policy guidelines are more or less out of place. If they care 
about not wasting server space, they should avoid these votings and arguments 
as much as possible. In general article removals should be harder to perform, 
e.g. requiring a 3/4 or 5/6 or 9/10 consencus.

The meatpuppetry argument is especially awkward. Assume someone has personal 
issues with D and decides to nominate the 'D programming language' article for 
deletion (AfD). Next, some D user periodically updating the D article notices 
this, starts a new (emotionally colored) thread in reddit and posts the link to 
the article to the newsgroup. This is something that badly pisses off the 
Wikipedia deletionists and soon everyone defending the article become 
meatpuppets in their eyes. If you call people with offensive names, you lose 
your vote and might get a permaban. foreach(name in reddit.thread || 
d.newsgroup) might also get a permaban if the deletionists are in a bad mood. 
It takes a huge amount of effort to actually keep the articles. It would be 
much easier to just leave them there and let the maintainers fix the issues.

Back to the topic..  at least Alice ML was used for teaching functional 
programming in some universities. There are also boatloads of papers about it, 
web sites, active users, and maybe even some dedicated books. This was all 
dismissed in the deletionist process.


This was not dismissed, AFAIK, instead this material was not mentionned ot 
pointed to by any co-author of the article; even after the AfD process had 
started. Else, the article could not have been deleted, according to WP's own 
criteria (more concretely, it would have been trivial to defend it).
==> If you create a new article and want to be sure it remains, start with 
quotations, references, pointers... lol


Denis
--
_
vita es estrany
spir.wikidot.com

Re: How mature is std.socket?

2011-02-15 Thread lurker

Yes, 2.51:

Digital Mars D Compiler v2.051
Copyright (c) 1999-2010 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:
...

Re: Integer conversions too pedantic in 64-bit

Sometimes I think we should troll the users a little and make
a release with names like so:

alias size_t
TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;

alias ptrdiff_t
TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;

alias iota lazyRangeThatGoesFromStartToFinishByTheGivenStepAmount;


Cash money says everyone would be demanding an emergency release with
shorter names. We'd argue for months about it... and probably settle
back where we started.

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Steven Schveighoffer


On Mon, 14 Feb 2011 20:58:17 -0500, Nick Sabalausky  wrote:


"Jonathan M Davis"  wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...

On Monday, February 14, 2011 17:06:43 spir wrote:


Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for Natural)


Why? size_t is what's used in C++. It's well known and what lots of
programmers
would expect What would you gain by renaming it?



Although I fully realize how much this sounds like making a big deal out  
of
nothing, to me, using "size_t" has always felt really clumsy and  
awkward. I
think it's partly because of using an underscore in such an otherwise  
short
identifier, and partly because I've been aware of size_t for years and  
still
don't have the slightest clue WTF that "t" means. Something like  
"wordsize"

would make a lot more sense and frankly feel much nicer.

And, of course, there's a lot of well-known things in C++ that D
deliberately destroys. D is a different language, it may as well do  
things

better.


Hey, bikeshedders, I found this cool easter-egg feature in D!  It's called  
alias!  Don't like the name of something?  Well you can change it!


alias size_t wordsize;

Now, you can use wordsize instead of size_t in your code, and the compiler  
doesn't care! (in fact, that's all size_t is anyways *hint hint*)


;)

-Steve

Re: Integer conversions too pedantic in 64-bit

2011-02-15 Thread Piotr Szturmaj


spir wrote:

On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:

spir wrote:

Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)


Maybe ptrint and ptruint?


If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while "size" may suggest it, .length
does not return a size_t but an uint.


ptr prefix shows that int/uint depends on CPU word (32/64 bit), i.e. 
they have the same size as pointer. However, it may led to confusion, 
which type - signed or unsigned - is right for the job.

Re: Integer conversions too pedantic in 64-bit


Am 15.02.2011 11:30, schrieb spir:

On 02/15/2011 02:58 AM, Nick Sabalausky wrote:

"Jonathan M Davis" wrote in message
news:mailman.1650.1297733226.4748.digitalmar...@puremagic.com...

On Monday, February 14, 2011 17:06:43 spir wrote:


Rename size-t, or rather introduce a meaningful standard alias? (would
vote
for Natural)


Why? size_t is what's used in C++. It's well known and what lots of
programmers
would expect What would you gain by renaming it?



Although I fully realize how much this sounds like making a big deal
out of
nothing, to me, using "size_t" has always felt really clumsy and
awkward. I
think it's partly because of using an underscore in such an otherwise
short
identifier, and partly because I've been aware of size_t for years and
still
don't have the slightest clue WTF that "t" means. Something like
"wordsize"
would make a lot more sense and frankly feel much nicer.

And, of course, there's a lot of well-known things in C++ that D
deliberately destroys. D is a different language, it may as well do
things
better.


Agreed. While making something different...
About the suffix "-_t", I bet it means type, what do you think? (may
well be wrong, just because I have here and there seen custom types like
name_t or point_t or such) Anyone has a history of C/++ at hand?

Denis


I've seen _t in C code for typedef'ed types.

like
  struct foo_s { ... };
  typedef struct foo_s foo_t;

and then "foo_t myfoo; myfoo.x = 42;" etc
instead of "struct foo_s myfoo; myfoo.x = 42;" etc

and also stuff like
  typedef float vec_t;
  typedef vec_t vec3_t[3];


So it is used to indicate that the it's an aliased type.

I don't see the problem with size_t.
It's the type used for sizes. sizeof(foo) (or foo.sizeof in D) uses it.

Cheers,
- Daniel

Re: tooling quality and some random rant

2011-02-15 Thread Don


Walter Bright wrote:

Don wrote:
In hand-coded asm, instruction scheduling still gives more than half 
of the same benefit that it used to do. But, it's become ten times 
more difficult. You have to use Agner Fog's manuals, not Intel/AMD.


For example:
(1) a common bottleneck on all Intel processors, is that you can only 
read from three registers per cycle, but you can also read from any 
register which has been modified in the last three cycles.

(2) it's important to break dependency chains.

On the BigInt code, instruction scheduling gave a speedup of ~40%.


Wow. I didn't know that. Do any compilers currently schedule this stuff?


Intel probably does. I don't think any others do a very good job. Agner 
told me that he had had no success in getting compiler vendors to be 
interested in his work.


Any chance you want to take a look at cgsched.c? I had great success 
using the same algorithm for the quite different Pentium and P6 
scheduling minutia.


That would really be fun.
BTW, the current Intel processors are basically the same as Pentium Pro, 
with a few improvements. The strange thing is, because of all of the 
reordering that happens, swapping the order of two (non-dependent) 
instructions makes no difference at all. So you always need to look at 
every instruction in the a loop, before you can do any scheduling.

Re: Integer conversions too pedantic in 64-bit


Am 15.02.2011 12:50, schrieb spir:

On 02/15/2011 03:44 AM, Piotr Szturmaj wrote:

spir wrote:

Rename size-t, or rather introduce a meaningful standard alias? (would
vote for Natural)


Maybe ptrint and ptruint?


If ptr means pointer, then it's wrong: size-t is used for more than
that, I guess. Strangely enough, while "size" may suggest it, .length
does not return a size_t but an uint.

Denis


.length of what? An array?
I'm pretty sure it returns size_t.

Cheers,
- Daniel

Re: Removed? (Wikipedia deletionism)

2011-02-15 Thread Kagamin

Vladimir Panteleev Wrote:

> Wikipedia articles must prove that they are notable enough, and people  
> unfamiliar with the subject must be able to verify it. Otherwise, it  
> fosters self-promotion.
> 
> Wikipedia has rules which may seem unfair or unbalanced at times, but  
> they're mostly logical with regards to the project's integrity (and not  
> necessarily usefulness).

The wikipedia rules explicitly state that they should be taken with common 
sense and deletion of nemerle is obviously beyond it. Not even speaking that 
they were given a scholarly article.

ps I'm not a nemerle fan and hate functional languages.

Re: Removed? (Wikipedia deletionism)

2011-02-15 Thread Aaron Smith

spir Wrote:

> On 02/15/2011 02:25 AM, bearophile wrote:
> >> D is much much more notable than Nemerle, Alice ML, Pure, Nosica, Kiev, 
> >> Einstein, Alma-0, Joy, Zonnon, Y, Cat, Fancy, Ambi, Ptolemy, Mythryl, 
> >> COMIT, Ioke, EASY, Aikido, A+, Adenine, Afnix, Bsisith, ChinesePython, 
> >> AngelScript, Algae, Agena, Taxi, Inger, Iota, Jot, Agora, Falcon, Averest, 
> >> Lava, Factor, Glagol. These all have been deleted by the same editor.
> > Nemerle, Factor, and few others need to be put back in Wikipedia.
> 
> The issue is: who judges what needs to be put? If we agree the notoriety 
> criterion is not only not good enough, but simply bad, in numerous domains 
> (not 
> only PLs), then what can be used? What criterion can be used, especially, to 
> /remove/ articles?
> Possibly the most interesting & earth-shaking language of all ever invented 
> is 
> among these ones. It is obviously hard to find one criterion, in any domain 
> involving design, creativity and/or research, don't you think?

If you're actively participating in language development, you should at least 
know Factor, Nemerle, and Alice ML. The author of Cat also has a strong online 
presence although he's not widely considered a genius unlike the authors of 
Factor and LuaJIT and Walter Bright. Slava Pestov is a real world hardcore 
badass developer and his Factor is *The* stack language to rule them all.

Re: Removed?