"Daniel Keep" wrote in message
news:hkcsrv$2qi...@digitalmars.com...
>
>
> Nick Sabalausky wrote:
>> "Bane" wrote in message
>> news:hkbqtb$rl...@digitalmars.com...
>>> Nick Sabalausky Wrote:
>>>
"Justin Johansson" wrote in message
news:hka8ju$1as...@digitalmars.com...
> Though,
>
Ali Çehreli wrote:
Andrei Alexandrescu wrote:
> It's no secret that string et al. are not a magic recipe for writing
> correct Unicode code. However, things are pretty good and could be
> further improved by operating the following changes in std.array and
> std.range:
>
> - make front() an
Andrei Alexandrescu wrote:
> It's no secret that string et al. are not a magic recipe for writing
> correct Unicode code. However, things are pretty good and could be
> further improved by operating the following changes in std.array and
> std.range:
>
> - make front() and back() for UTF-8 and UTF
Walter Bright wrote:
Andrei Alexandrescu wrote:
Oh, one more thing: doing mixed-width searches would require decoding.
Or a conversion before the loop starts of the search term.
That triggers memory allocation plus the same cost. It's not likely to
work any better.
Andrei
On 2/3/2010 10:27 PM, Trip Volpe wrote:
Joel Anderson Wrote:
You could potentially use a mixin to do this. The resulting code would
look something like this.
void main()
{
int myFoo = 100;
mixin(expectEquals! ( "myFoo == 3" ));
}
Yeah, mixins could work, but they're
Joel Anderson wrote:
Just wanted to congratulate Walter and the community for keeping D going
strong for so long. Its nice to see some features such as pure and
ranges have actually become realities. D 2.0 feels like its no-longer a
sibling language of D 1.0.
And it's nice to see you back!
Andrei Alexandrescu wrote:
Oh, one more thing: doing mixed-width searches would require decoding.
Or a conversion before the loop starts of the search term.
On Thu, 04 Feb 2010 07:10:21 +0300, Joel Anderson wrote:
Hello,
Just wanted to congratulate Walter and the community for keeping D going
strong for so long. Its nice to see some features such as pure and
ranges have actually become realities. D 2.0 feels like its no-longer a
sibling la
ZY Zhou wrote:
Andrei Alexandrescu Wrote:
What can be done about that? I see a number of solutions:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use "length" under the assumption that it
really mean
Joel Anderson Wrote:
>
> You could potentially use a mixin to do this. The resulting code would
> look something like this.
>
> void main()
> {
>int myFoo = 100;
>mixin(expectEquals! ( "myFoo == 3" ));
> }
Yeah, mixins could work, but they're ugly. ;-)
Forcing the use
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Arrays of char and wchar are not quite generic - they are definitely UTF
strings.
A 'char' is a single utf-8 code unit. A 'char[]' is (or should be) a
generic array of utf-8 code units. Sometimes these code units line up
to form valid unicode co
On 2/3/2010 9:34 PM, Trip Volpe wrote:
I'm working on a set of handy unit testing accessories for my projects. What
I'd love to achieve is something like this:
expectEqual( myFoo, 3 );
Which, on failure, would result in something along the lines of this diagnostic:
somefile.d:37: Tes
Andrei Alexandrescu wrote:
> Arrays of char and wchar are not quite generic - they are definitely UTF
> strings.
A 'char' is a single utf-8 code unit. A 'char[]' is (or should be) a
generic array of utf-8 code units. Sometimes these code units line up
to form valid unicode code points, sometimes
Walter Bright wrote:
Justin Johansson wrote:
May I ask, what are the best solutions for C++ (my current
dilemma) and what steps will be taken in D2 to zap it.
Within a module, static initialization is done in lexical order.
Across modules, static initialization is performed so that imported
I'm working on a set of handy unit testing accessories for my projects. What
I'd love to achieve is something like this:
expectEqual( myFoo, 3 );
Which, on failure, would result in something along the lines of this diagnostic:
somefile.d:37: Test failure!
Expected: myFoo == 3
Don wrote:
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
As is std.numeric.dotProduct(x, y) without language _or_ library change
bearophile wrote:
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
x.dot(y) and dot(x,y) are already implementable without language change.
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
- make front() and back() for UTF-8 and UTF-16 automatically decode the
first and last Unicode character
- make popFront() and popBack() skip one entire Unicode character
(instead of just one code unit)
- alter isRandomAccessRange to return false
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code. However, things are pretty good and could be
further improved by operating the following changes in std.array and
Walter Bright wrote:
Andrei Alexandrescu wrote:
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code.
I'm concerned it would be slow. Most operations on strings do not need
to decode the unicode characters, for example, find, startsWith, etc.,
do not. Dec
Walter Bright wrote:
Andrei Alexandrescu wrote:
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code.
I'm concerned it would be slow. Most operations on strings do not need
to decode the unicode characters, for example, find, startsWith, etc.,
do not. Dec
Andrei Alexandrescu wrote:
> - make front() and back() for UTF-8 and UTF-16 automatically decode the
> first and last Unicode character
>
> - make popFront() and popBack() skip one entire Unicode character
> (instead of just one code unit)
>
> - alter isRandomAccessRange to return false for UTF-8
On 2010-02-03 21:00:21 -0500, Andrei Alexandrescu
said:
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code.
[...]
What would you do? Any ideas are welcome.
UTF-8 and UTF-16 encodings are interesting beasts. If you have a UTF-8
string and want to sea
Hello,
Just wanted to congratulate Walter and the community for keeping D going
strong for so long. Its nice to see some features such as pure and
ranges have actually become realities. D 2.0 feels like its no-longer a
sibling language of D 1.0.
I imagine a lot of people here don't remembe
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> It's no secret that string et al. are not a magic recipe for writing
> correct Unicode code. However, things are pretty good and could be
> further improved by operating the following changes in std.array and
> std.range:
Andrei Alexandrescu wrote:
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code.
I'm concerned it would be slow. Most operations on strings do not need
to decode the unicode characters, for example, find, startsWith, etc.,
do not. Decoding then doing find,
Andrei Alexandrescu wrote:
> ...
>
> I hear you. Actually, to either quench or add to the confusion, .length
> for wstring returns the length in 16-bit units, not bytes.
>
> Andrei
0.o
...
kay.
retard wrote:
Wed, 03 Feb 2010 12:37:56 -0500, bearophile wrote:
Later more things can be improved, but I think this is enough to fix
most of the situation.
Interesting. So a novice programmer can produce much faster code in Java
than a semi-pro in D in this case.
Ever since Java implemen
Andrei Alexandrescu wrote:
What can be done about that? I see a number of solutions:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use "length" under the assumption that it
really means "elements coun
bearophile wrote:
Walter Bright:
That's not safe because there are always opaque modules that are
binary only. They may derive from the class in the module - and the
optimizer cannot prove they don't.
This sounds like: Lasciate ogni speranza, voi ch'entrate.
Let's try again. I think there can
I'd like to propose a small project suggested by Walter. If anyone could
take this up, it would be great. The project is a small utility program
that could be a good complement to the likes of rdmd.
The program allows you to play with entire D projects as zip files. It
takes a zip file, extrac
Chad J wrote:
Andrei Alexandrescu wrote:
...
What can be done about that? I see a number of solutions:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use "length" under the assumption that it
really me
Andrei Alexandrescu wrote:
> ...
>
> What can be done about that? I see a number of solutions:
>
> (a) Do not operate the change at all.
>
> (b) Operate the change and mention that in range algorithms you should
> check hasLength and only then use "length" under the assumption that it
> really m
Andrei Alexandrescu Wrote:
> What can be done about that? I see a number of solutions:
>
> (a) Do not operate the change at all.
>
> (b) Operate the change and mention that in range algorithms you should
> check hasLength and only then use "length" under the assumption that it
> really means "e
Michiel Helvensteijn wrote:
> bearophile wrote:
>
>>> Indeed. The difficult question is, what would the syntax be?
>> What about the simper:
>> x.dot(y)
>
> I don't like symmetric operations with an asymmetric syntax.
>
> Better: dot(x, y)
> Even better: dot_product(x, y)
> Funner: sum
On Wed, 03 Feb 2010 21:00:21 -0500, Andrei Alexandrescu
wrote:
(a) Do not operate the change at all.
(b) Operate the change and mention that in range algorithms you should
check hasLength and only then use "length" under the assumption that it
really means "elements count".
(c) Deprecate
It's no secret that string et al. are not a magic recipe for writing
correct Unicode code. However, things are pretty good and could be
further improved by operating the following changes in std.array and
std.range:
- make front() and back() for UTF-8 and UTF-16 automatically decode the
first
Wed, 03 Feb 2010 12:37:56 -0500, bearophile wrote:
> Later more things can be improved, but I think this is enough to fix
> most of the situation.
Interesting. So a novice programmer can produce much faster code in Java
than a semi-pro in D in this case.
Walter Bright:
> That's not safe because there are always opaque modules that are binary
> only. They may derive from the class in the module - and the optimizer
> cannot prove they don't.
This sounds like:
Lasciate ogni speranza, voi ch'entrate.
Let's try again. I think there can be two types
Sorry, I had missed the Leaf node.
bearophile wrote:
With LDC you can use a level of optimization (LTO) that spans all the
modules you are compiling at once.
That's not safe because there are always opaque modules that are binary
only. They may derive from the class in the module - and the op
Walter Bright:
> The virtual function calls are the calls to
> Internal.walkSum() via an expression typed as Node.walkSum().
That expression typed as Node.walkSum() also calls Leaf.walkSum().
> The Java
> JIT has access to the entire program, so it can do whole program
> analysis and determi
Nick Sabalausky wrote:
> "Bane" wrote in message
> news:hkbqtb$rl...@digitalmars.com...
>> Nick Sabalausky Wrote:
>>
>>> "Justin Johansson" wrote in message
>>> news:hka8ju$1as...@digitalmars.com...
Though,
admittedly, these days I find it boring to always lose against
modern ch
Ellery Newcomer wrote:
> On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
>> On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
>> wrote:
>>
>>> bearophile wrote:
>>>
> Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
>>>
>>> I do
Andrei Alexandrescu:
> Before we solve the difficult problem of naming the thing could we first
> go through the trivial part of optimizing it under its current name.
In this case finding a good syntax before D2 is out of alpha stage is more
important than implementing that efficiently.
The user
bearophile wrote:
This post is about few simple experiments I've done in D about
virtual calls and how to improve their performance. So probably this
can't be useful before D2 is out of alpha state. For people working
at Sun this stuff is probably very old and very naive, but I think
currently no
Unicode operators are good for Fortress, but not for D.
x.dot(y) is good because it's short and easy to read&understand.
Another silly possibility:
x ^^^ y
:-)
Bye,
bearophile
On 03/02/10 21:27, Don wrote:
Robert Clipsham wrote:
On 03/02/10 20:52, Don wrote:
Trass3r wrote:
in the (new) dmd-internals newsgroup. Please join!
Can't find a new newsgroup.
lists.puremagic.com.
Has anyone put the dmd-internals mailing list on gmane yet? Is it
being processed or does i
BCS wrote:
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with
Hello Ellery,
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetri
Hello bearophile,
Don:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
How about: x.y;
It reads correctly.
OK, bad idea. :)
--
<
Robert Clipsham wrote:
On 03/02/10 20:52, Don wrote:
Trass3r wrote:
in the (new) dmd-internals newsgroup. Please join!
Can't find a new newsgroup.
lists.puremagic.com.
Has anyone put the dmd-internals mailing list on gmane yet? Is it being
processed or does it still need submitting?
It's
On 03/02/10 20:52, Don wrote:
Trass3r wrote:
in the (new) dmd-internals newsgroup. Please join!
Can't find a new newsgroup.
lists.puremagic.com.
Has anyone put the dmd-internals mailing list on gmane yet? Is it being
processed or does it still need submitting?
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Bette
"Bane" wrote in message
news:hkbqtb$rl...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> "Justin Johansson" wrote in message
>> news:hka8ju$1as...@digitalmars.com...
>> > Though,
>> > admittedly, these days I find it boring to always lose against
>> > modern chess programs.
>>
>> That's one of
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
wrote:
bearophile wrote:
Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x,
Trass3r wrote:
in the (new) dmd-internals newsgroup. Please join!
Can't find a new newsgroup.
lists.puremagic.com.
in the (new) dmd-internals newsgroup. Please join!
Can't find a new newsgroup.
bearophile wrote:
>> Indeed. The difficult question is, what would the syntax be?
>
> What about the simper:
> x.dot(y)
I don't like symmetric operations with an asymmetric syntax.
Better: dot(x, y)
Even better: dot_product(x, y)
Funner: sum(x .* y)
--
Michiel Helvensteijn
Don:
> Indeed. The difficult question is, what would the syntax be?
What about the simper:
x.dot(y)
Bye,
bearophile
Trass3r wrote:
I know about http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
but is there maybe an updated and more detailed version?
The short answer is unfortunately, no. But this question really belongs
in the (new) dmd-internals newsgroup. Please join!
bearophile wrote:
This post is about few simple experiments I've done in D about virtual calls
and how to improve their performance.
So probably this can't be useful before D2 is out of alpha state.
[snip]
This is an excellent piece of research. As you say, it's not top
priority right now,
Hello Don,
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
Make it an intrinsic?
--
<
Trass3r wrote:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Indeed. The difficult question is, what would the syntax be?
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it
since SSE 4.1.
Hello Nick,
But then many of those people get confused and start thinking that
means censorship isn't censorship unless it's specifically a
government doing it, which of course is a load of bull.
OK, then if you want to call other things censorship (and you may well be
right to do so) I wil
This post is long, I hope the web interface doesn't cut it down.
This post is about few simple experiments I've done in D about virtual calls
and how to improve their performance. So probably this can't be useful before
D2 is out of alpha state. For people working at Sun this stuff is probably v
Justin Johansson wrote:
May I ask, what are the best solutions for C++ (my current
dilemma) and what steps will be taken in D2 to zap it.
Within a module, static initialization is done in lexical order.
Across modules, static initialization is performed so that imported
modules are initialize
Walter Bright Wrote:
> Bane wrote:
> > So Walther chops wood while Odersky write docs...
>
> I'm not much of a writer. That's why Andrei is writing TDPL, not me.
This reminds me of popular joke here where I live - 'Why do cops go in pairs?'
'Because first one knows how to read, and second how t
Bane wrote:
So Walther chops wood while Odersky write docs...
I'm not much of a writer. That's why Andrei is writing TDPL, not me.
Andrei Alexandrescu Wrote:
> retard wrote:
> > I only now realized how disciplined and professional the Scala design
> > process is vs amateur languages like D. Just look how clearly they are
> > able to express the changes of a minor release update:
> >
> > http://www.scala-lang.org/node/4587
retard wrote:
I only now realized how disciplined and professional the Scala design
process is vs amateur languages like D. Just look how clearly they are
able to express the changes of a minor release update:
http://www.scala-lang.org/node/4587
They also have the concept of improvement docum
I know about http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
but is there maybe an updated and more detailed version?
Don wrote:
> Jesse Phillips wrote:
>> retard Wrote:
>>
Intel 64 is AMD64. Intel dropped their 64-bit implementation, EM64T,
after AMD won.
>>> That's bullshit, but I guess it doesn't matter, because most software
>>> uses the compatible subset of both versions.
>>>
>>> See:
>>> http://
retard, el 3 de febrero a las 08:40 me escribiste:
> I only now realized how disciplined and professional the Scala design
> process is vs amateur languages like D. Just look how clearly they are
> able to express the changes of a minor release update:
>
> http://www.scala-lang.org/node/4587
>
I'm sure many of you are across this problem.
Sorry if this post is about a topic that has been
dealt with conclusively before on this NG.
May I ask, what are the best solutions for C++ (my current
dilemma) and what steps will be taken in D2 to zap it.
Cheers
-- Justin Johansson
Walter Bright wrote:
retard wrote:
Just look how clearly they are able to express the changes of a minor
release update:
You're more than welcome to come help out with the documentation. The
stuff is all generated from templates. If you want to help improve the
look of the docs, or the conte
Bane wrote:
Nick Sabalausky Wrote:
"Justin Johansson" wrote in message
news:hka8ju$1as...@digitalmars.com...
Though,
admittedly, these days I find it boring to always lose against
modern chess programs.
That's one of the big reasons I lost interest in multiplayer FPSes. Getting
fragged every
On 03/02/2010 01:06, Walter Bright wrote:
Yigal Chripun wrote:
As I said before, you must be a much more tolerant person than I am :)
I have long experience with online flame wars. The only way to "win" at
them is to not play.
You are a webbudhist, Walter.
Nick Sabalausky Wrote:
> "Justin Johansson" wrote in message
> news:hka8ju$1as...@digitalmars.com...
> > Though,
> > admittedly, these days I find it boring to always lose against
> > modern chess programs.
>
> That's one of the big reasons I lost interest in multiplayer FPSes. Getting
> fragg
retard wrote:
Just look how clearly they are
able to express the changes of a minor release update:
You're more than welcome to come help out with the documentation. The
stuff is all generated from templates. If you want to help improve the
look of the docs, or the content, please join in.
"Mike Parker" wrote in message
news:hkbcjd$33...@digitalmars.com...
> dsimcha wrote:
>> == Quote from Jeff Nowakowski (j...@dilacero.org)'s article
>>> BCS wrote:
Group = citizens of china
controller = government of china
for the case in question (this NG)
group = pe
"Mike Parker" wrote in message
news:hkbc7f$2b...@digitalmars.com...
> Walter Bright wrote:
>> Yigal Chripun wrote:
I've thought about building such a system for these forums many times.
Registration would not be required to post, but registering would
enable
features like vot
I only now realized how disciplined and professional the Scala design
process is vs amateur languages like D. Just look how clearly they are
able to express the changes of a minor release update:
http://www.scala-lang.org/node/4587
They also have the concept of improvement documents (kind of li
dsimcha wrote:
== Quote from Jeff Nowakowski (j...@dilacero.org)'s article
BCS wrote:
Group = citizens of china
controller = government of china
for the case in question (this NG)
group = people posting on NG
controller = people in NG wanting someone banned.
I see a difference
The governmen
Jesse Phillips wrote:
retard Wrote:
Intel 64 is AMD64. Intel dropped their 64-bit implementation, EM64T,
after AMD won.
That's bullshit, but I guess it doesn't matter, because most software
uses the compatible subset of both versions.
See:
http://en.wikipedia.org/wiki/X86-64#Differences_betw
Walter Bright wrote:
Yigal Chripun wrote:
I've thought about building such a system for these forums many times.
Registration would not be required to post, but registering would enable
features like voting on posts, establishing a profile, preferences, etc.
That sounds awesome. Another useful
On 03/02/2010 09:19, Lutger wrote:
On 02/03/2010 02:42 AM, Walter Bright wrote:
Yigal Chripun wrote:
I've thought about building such a system for these forums many times.
Registration would not be required to post, but registering would
enable
features like voting on posts, establishing a prof
Walter Bright wrote:
Yigal Chripun wrote:
As I said before, you must be a much more tolerant person than I am :)
I have long experience with online flame wars. The only way to "win" at
them is to not play.
What bothered me the most about his language was not the fact the it
was insulting
88 matches
Mail list logo
