On 01/18/2011 06:14 PM, Michel Fortin wrote:
On 2011-01-18 11:38:45 -0500, Andrei Alexandrescu
said:
I was thinking along the lines of:
struct Grapheme
{
private string support_;
...
}
struct ByGrapheme
{
private string iteratee_;
bool empty();
Grapheme front();
void popFront();
// Additiona
On 01/18/2011 06:33 PM, Jim wrote:
Adam Ruppe Wrote:
Maybe. 9/10 times they match anyway, but I'd be annoyed if
the package names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they
didn't match when I would go to look for something
On 01/18/2011 03:52 AM, Andrei Alexandrescu wrote:
On 1/17/11 5:13 PM, spir wrote:
On 01/17/2011 07:57 PM, Andrei Alexandrescu wrote:
* Line 130: representing a text as a dchar[][] has its advantages but
major efficiency issues. To be frank I think it's a disaster. I think a
represent
On 01/18/2011 07:11 AM, Andrei Alexandrescu wrote:
On 1/17/11 11:48 PM, Jonathan M Davis wrote:
On Monday 17 January 2011 15:13:42 spir wrote:
See range bug evoked above. opApply is the only workaround AFAIK.
Also, ranges cannot yet provide indexed iteration like
foreach(i, char ; text
On 01/18/2011 06:48 AM, Jonathan M Davis wrote:
On Monday 17 January 2011 15:13:42 spir wrote:
See range bug evoked above. opApply is the only workaround AFAIK.
Also, ranges cannot yet provide indexed iteration like
foreach(i, char ; text) {...}
While it would be nice at times to be
On 01/18/2011 04:48 AM, Michel Fortin wrote:
On 2011-01-17 17:54:04 -0500, Michel Fortin
said:
More seriously, you have four choice:
1. code unit
2. code point
3. grapheme
4. require the client to state explicitly which kind of 'character' he
wants; 'character' being an overloaded word, it's
On 01/18/2011 12:41 PM, Walter Bright wrote:
bearophile wrote:
Found through Reddit, similar things can be said about D2:
http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html
I think that article is bunk.
Large Java programs (as related to me by corporate Java progra
On 01/18/2011 01:10 PM, Aziz K. wrote:
I would prefer it to work like this:
repeat("abc", 3) -> "abcabcabc"
repeat(["abc"], 3) -> ["abc","abc","abc"]
repeat([1,2,3], 3) -> [1,2,3,1,2,3,1,2,3]
I find this consistent in that the operation keeps the nesting level
constant. But then we need a goo
On 01/17/2011 07:57 PM, Daniel Gibson wrote:
IMHO * (multiply) is not good because in theoretical computer science
multiply is used to concatenate two words and thus concatenating a word
with itself n times is word^n (pow(word, n) in mathematical terms).
Weird. Excuse my ignorance, but how can
On 01/17/2011 07:57 PM, Andrei Alexandrescu wrote:
On 1/17/11 12:23 PM, spir wrote:
Andrei, would you have a look at Text's current state, mainly
theinterface, when you have time for that (no hurry) at
https://bitbucket.org/denispir/denispir-d/src
It is actually a bit more than just a s
On 01/17/2011 09:15 PM, Jonathan M Davis wrote:
On Monday, January 17, 2011 10:59:16 spir wrote:
On 01/17/2011 07:53 PM, Adam Ruppe wrote:
It seems to me that you actually want two separate functions:
repeat("abc", 3) => ["abc", "abc", "abc"]
join
On 01/17/2011 07:53 PM, Adam Ruppe wrote:
It seems to me that you actually want two separate functions:
repeat("abc", 3) => ["abc", "abc", "abc"]
join(repeat("abc", 3)) => "abcabcabc"
Would rather see:
repeat("abc", 3) => ["abc", "abc", "abc"]
"abc" * 3=> "abcabcabc"
Denis
__
On 01/17/2011 07:10 PM, Andrei Alexandrescu wrote:
I want to generalize the functionality in string's repeat and move it
outside std.string. There is an obvious semantic clash here. If you say
repeat("abc", 3) did you mean one string "abcabcabc" or three strings
"abc", "abc", and "abc"?
So we ne
On 01/17/2011 04:00 PM, Andrei Alexandrescu wrote:
On 1/17/11 6:44 AM, Steven Schveighoffer wrote:
We need to get some real numbers together. I'll see what I can create
for a type, but someone else needs to supply the input :) I'm on short
supply of unicode data, and any attempts I've made to cr
On 01/17/2011 06:36 PM, Andrei Alexandrescu wrote:
On 1/17/11 10:55 AM, spir wrote:
On 01/15/2011 12:21 AM, Michel Fortin wrote:
Also, it'd really help this discussion to have some hard numbers about
the cost of decoding graphemes.
Text has a perf module that provides such number
On 01/17/2011 05:34 PM, Michel Fortin wrote:
As I said: all those people who are not validating the inputs to make
sure they don't contain combining code points. As far as I know, no one
is doing that, so that means everybody should use algorithms capable of
handling multi-code-point graphemes. I
On 01/17/2011 01:44 PM, Steven Schveighoffer wrote:
On Sun, 16 Jan 2011 13:06:16 -0500, Andrei Alexandrescu
wrote:
On 1/15/11 9:25 PM, Jonathan M Davis wrote:
Considering that strings are already dealt with specially in order to
have an
element of dchar, I wouldn't think that it would be all
On 01/15/2011 12:21 AM, Michel Fortin wrote:
Also, it'd really help this discussion to have some hard numbers about
the cost of decoding graphemes.
Text has a perf module that provides such numbers (on different stages
of Text object construction) (but the measured algos are not yet
stabilise
On 01/14/2011 04:50 PM, Michel Fortin wrote:
This might be a good time to see whether we need to address graphemes
systematically. Could you please post a few links that would educate
me and others in the mysteries of combining characters?
As usual, Wikipedia offers a good summary and a couple
On 01/15/2011 11:45 PM, Michel Fortin wrote:
That said, I'm sure if someone could redesign Unicode by breaking
backward-compatibility we'd have something simpler. You could probably
get rid of pre-combined characters and reduce the number of
normalization forms. But would you be able to get rid o
OT support e.g. Normalization.
As Spir already said, Unicode is something few understand and even it's own
official docs do not explain such issues properly. We should not confuse users
even further with incomplete support.
In a few days, D will have an external library able to deal wit
On 01/15/2011 08:51 PM, Steven Schveighoffer wrote:
More over, Even if you ignore Hebrew as a tiny insignificant minority
you cannot do the same for Arabic which has over one *billion* people
that use that language.
I hope that the medium type works 'good enough' for those languages,
with the h
On 01/14/2011 11:29 PM, foobar wrote:
So it's definitly possible in Hebrew to have more than one combining mark on
the same base letter. When comparing such letters the order of the combining
marks should not matter and I think there's a default normalized order in such
cases.
Unicode define
On 01/15/2011 05:59 PM, Steven Schveighoffer wrote:
I think this is a good alternative, but I'd rather not impose this on
people like myself who deal mostly with English. I think this should be
possible to do with wrapper types or intermediate ranges which have
graphemes as elements (per my sugg
On 01/14/2011 08:20 PM, Nick Sabalausky wrote:
"spir" wrote in message
news:mailman.619.1295012086.4748.digitalmar...@puremagic.com...
If anyone finds a pointer to such an explanation, bravo, and than you.
(You will certainly not find it in Unicode literature, for instanc
On 01/14/2011 07:26 AM, Nick Sabalausky wrote:
> > "Andrei Alexandrescu" wrote in message
> > news:igoj6s$17r6$1...@digitalmars.com...
>> >>
>> >> I'm not so sure about that. What do you base this assessment on?
Denis
>> >> wrote a library that according to him does grapheme-related stuff
nobod
On 01/14/2011 02:37 PM, Steven Schveighoffer wrote:
* I don't even know how to make a grapheme that is more than one
code-unit, let alone more than one code-point :) Every time I try, I
get 'invalid utf sequence'.
I feel significantly ignorant on this issue, and I'm slowly getting
enough knowl
m does grapheme-related stuff nobody
else does. So apparently graphemes is not what people care about
(although
it might be what they should care about).
It's what they want, they just don't know it.
Graphemes are what many people *think* code points are.
Agreed. Up until spir me
On 01/14/2011 07:44 AM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:igoqrm$1n5r$1...@digitalmars.com...
On 1/13/11 10:26 PM, Nick Sabalausky wrote:
[snip]
[ 'f', {u with the umlaut}, 'n', 'f' ]
Or:
[ 'f', 'u', {umlaut combining character}, 'n', 'f' ]
Those *both* get
On 01/14/2011 07:33 AM, Andrei Alexandrescu wrote:
Thanks. One further question is: in the above example with
u-with-umlaut, there is one code point that corresponds to the entire
combination. Are there combinations that do not have a unique code point?
See my previous follow-up to nick's expla
On 01/14/2011 07:26 AM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:igoj6s$17r6$1...@digitalmars.com...
I'm not so sure about that. What do you base this assessment on? Denis
wrote a library that according to him does grapheme-related stuff nobody
else does. So apparentl
On 01/14/2011 05:23 AM, Andrei Alexandrescu wrote:
That's forgetting that most of the time people care about graphemes
(user-perceived characters), not code points.
I'm not so sure about that. What do you base this assessment on? Denis
wrote a library that according to him does grapheme-relate
On 01/13/2011 11:00 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ignon1$2p4k$1...@digitalmars.com...
This may sometimes not be what the user expected; most of the time they'd
care about the code points.
I dunno, spir has succesfuly convinced me t
On 01/13/2011 02:47 PM, Michel Fortin wrote:
On 2011-01-13 06:48:46 -0500, spir said:
Note that D's stdlib currently provides no means to do this, not even
on the fly. You'd have to interface with eg ICU (a C/C++/Java Unicode
library) (good luck ;-). But even ICU, as well as suppos
On 01/13/2011 04:24 PM, Andrej Mitrovic wrote:
On 1/13/11, spir wrote:
May share my settings for D if anyone interested.
Well if you do, share them here:
http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/Geany so everyone can
find it.
Well, I don't mind sharing them, but geany setting
On 01/13/2011 01:10 PM, Jonathan M Davis wrote:
I wasn't saying that code points are guaranteed to be characters. I was saying
that in most cases they are, so if efficiency is an issue, then having properly
abstract characters could be too costly.
The problem is then: how does a library or appl
On 01/13/2011 11:15 AM, Don wrote:
Also I don't understand why http://www.digitalmars.com/d/2.0/
comparison.html only contains 1 column for D and no other languages so
you can directly see what they are all missing.
It used to contain several languages. It was removed due to intense
criticism.
On 01/13/2011 11:16 AM, Jonathan M Davis wrote:
On Thursday 13 January 2011 01:49:31 spir wrote:
On 01/13/2011 01:45 AM, Michel Fortin wrote:
On 2011-01-12 14:57:58 -0500, spir said:
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]&quo
On 01/13/2011 04:43 AM, Walter Bright wrote:
Andrej Mitrovic wrote:
On 1/12/11, Jean Crystof wrote:
Claiming that low end components have shorter lifespan is ridiculous.
You've never had computer equipment fail on you?
I've had a lot of computer equipment.
Failures I've had, ranked in ord
On 01/13/2011 01:51 AM, Michel Fortin wrote:
On 2011-01-12 19:45:36 -0500, Michel Fortin
said:
A funny exercise to make a fool of an algorithm working only with code
points would be to replace the word "fortune" in a text containing the
word "fortuné". If the last "é" is expressed as two code
On 01/13/2011 01:56 AM, Andrej Mitrovic wrote:
I don't want to make this Vim-specific, so I'm wondering what features are we
missing in today's D editors/IDE's that other languages already have in their
editors/IDE's?
For what it's worth, Geany works very nicely with D out of the box (it's
b
On 01/13/2011 01:45 AM, Michel Fortin wrote:
On 2011-01-12 14:57:58 -0500, spir said:
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I'd like to know when it happens that codepoint is the appropriate level
of abstraction.
* If pieces of text are
On 01/12/2011 07:22 AM, Jerry Quinn wrote:
Jerry Quinn Wrote:
Same comment for icmp(). Also, in the Unicode standard, case folding can
depend on the specific language.
That uses toUniLower. Not sure how that works.
And doesn't mention details about the Unicode standard version it impleme
On 01/12/2011 07:22 AM, Jerry Quinn wrote:
Jerry Quinn Wrote:
Same comment for icmp(). Also, in the Unicode standard, case folding can
depend on the specific language.
That uses toUniLower. Not sure how that works.
And doesn't mention details about the Unicode standard version it impleme
On 01/12/2011 02:22 AM, Andrei Alexandrescu wrote:
IIUC, for the case of text, VLERange helps abstracting from the annoying
fact that a codepoint is encoded as a variable number of code units.
What I meant is issues like:
auto text = "a\u0302"d;
writeln(text); // "â"
auto range = VLERange(text);
On 01/12/2011 02:17 AM, Daniel Gibson wrote:
Somewhere in this thread:
Am 11.01.2011 21:43, schrieb Walter Bright:
> Nick Sabalausky wrote:
>> I agree with this reasoning for having them. However, I don't think it
>> means we shouldn't D-ify or Phobos-ify them, at least as far as
>> capitali
On 01/12/2011 12:07 AM, Daniel Gibson wrote:
Am 12.01.2011 00:00, schrieb Andrei Alexandrescu:
On 1/11/11 11:21 AM, Ary Borenszweig wrote:
Why care where they come from? Why not make them intuitive? Say, like,
"Always
camel case"?
If there's enough support for this, I'll do it.
Andrei
Plea
On 01/11/2011 09:11 PM, Ary Borenszweig wrote:
"Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! Then you
will feel at home."
That phrase currently ends like this:
"You don't? Oh, sorry, you will have to learn that some names are all lowercase,
some not."
But it could end l
On 01/11/2011 08:09 PM, Andrei Alexandrescu wrote:
The main (and massively ignored) issue when manipulating unicode text is
rather that, unlike with legacy character sets, one codepoint does *not*
represent a character in the common sense. In character sets like
latin-1:
* each code represents a
On 01/11/2011 07:01 PM, Nick Sabalausky wrote:
The names are for compatibility with... other languages :o|.
>
Would that other language be Walterish or C?
If C, it's not like using the wrong case will suddendly change the semantics
of the function. And if the worry is other non-phobos functions
On 01/11/2011 07:14 PM, Nick Sabalausky wrote:
"Daniel Gibson" wrote in message
news:igi6n5$27p...@digitalmars.com...
Am 11.01.2011 19:07, schrieb Nick Sabalausky:
Thoust words are true.
Seriously though, I'm pretty sure a lot of native english speakers don't
know "sans" either, unless they'r
On 01/11/2011 02:30 PM, Steven Schveighoffer wrote:
On Mon, 10 Jan 2011 22:57:36 -0500, Andrei Alexandrescu
wrote:
I've been thinking on how to better deal with Unicode strings.
Currently strings are formally bidirectional ranges with a
surreptitious random access interface. The random access
On 01/11/2011 05:36 PM, Andrei Alexandrescu wrote:
On 1/11/11 4:41 AM, Michel Fortin wrote:
On 2011-01-10 22:57:36 -0500, Andrei Alexandrescu
said:
In addition to these (and connecting the two), a VLERange would offer
two additional primitives:
1. size_t stepSize(size_t offset) gives the leng
On 01/11/2011 04:11 PM, Max Samukha wrote:
Anyway, the necessity for super-cryptic abbreviated names doesn't exist
any more. Maybe, they are justified for very frequently used stuff but
stripl/stripr is not the case.
+++
Standard names should all be as obvious as possible. Then, everyone is
fr
On 01/11/2011 02:22 PM, Steven Schveighoffer wrote:
A tree is a kind of set, so instead of "insert()" I'd like a name like
"add()".
(But maybe this is not standard in D).
The function names must be consistent across containers, because the
point is that complexity and semantic requirements are
On Tue, 04 Jan 2011 07:34:15 -0500
bearophile wrote:
> An example of bug (more than 14 like this fixed in few years):
>
> - memset(pp, 0, sizeof(pp));
> + memset(pp, 0, sizeof(*pp));
>
> - memcpy((caddr_t)TstSchedTbl, (caddr_t)&vcIndex,sizeof(TstSchedTbl));
> + memcpy((c
On Tue, 4 Jan 2011 02:30:24 -0200
Guilherme Vieira wrote:
> At times like this I wish people would really break their code in smaller
> parts in a way you could really just pick what you want from it.
I guess this is a dream generations of programmers, language designers and
computer scientist
On Mon, 03 Jan 2011 23:27:22 -0600
Andrei Alexandrescu wrote:
> Nevertheless, I found two issues: one, ParameterTypeTuple doesn't work
> for overloaded functions, and associative arrays don't work for ubyte[4]
> keys... still a ways to go.
Could you or someone else expand on this?
Denis
-- --
On Mon, 3 Jan 2011 22:23:29 + (UTC)
Adam Ruppe wrote:
> Over the weekend, I attacked opDispatch again and found some old
> Variant bugs were killed. I talked about that in the Who uses D
> thread.
>
> Today, I couldn't resist revisiting a dynamic kind of object, and
> made some decent progre
On Mon, 3 Jan 2011 22:11:34 +0100
Andrej Mitrovic wrote:
> Offtopic (sry): On the other hand, D could do the same for the build
> process. Bringing RDMD's abilities to DMD would simplify the build
> process for many people.
+++
Newcomers (like myself) can meet rdmd quite late, just by chance. I
On Mon, 03 Jan 2011 12:27:33 -0800
Walter Bright wrote:
> On the other hand, the built-in D unit test ability has been a huge success.
>
> A unit test facility that is not used is worthless, no matter how capable it
> is.
> The advantage of it being simple and built-in is it gets used, and I t
On Mon, 03 Jan 2011 10:27:17 -0500
"Steven Schveighoffer" wrote:
> On Mon, 03 Jan 2011 09:56:30 -0500, spir wrote:
>
> > On Mon, 03 Jan 2011 08:34:42 -0500
> > "Steven Schveighoffer" wrote:
> >
> >> Yes, just use a data member:
> &g
On Mon, 03 Jan 2011 08:34:42 -0500
"Steven Schveighoffer" wrote:
> Yes, just use a data member:
>
> struct MyRange {
> int front;
> bool empty;
> void popFront();
> }
>
> A property is actually supposed to work just like a field.
>
> There is no need for new syntax.
Hum, does not
On Mon, 03 Jan 2011 00:55:47 -0500
"Robert Jacques" wrote:
> On Sun, 02 Jan 2011 05:29:48 -0500, spir wrote:
> > Hello,
> >
> > Using properties allows travesting a method call into direct data
> > access. What if the underlying member actually is plai
On Sun, 02 Jan 2011 13:21:33 -0800
Walter Bright wrote:
> That's the interesting part, and why I suggested that studying recurring
> patterns of real life bugs is productive. What we think might be a problem vs
> what actually is a problem can be very different.
Thank you for pointing (& re-po
On Sun, 02 Jan 2011 20:56:48 +
Peter Alexander wrote:
> > This is great stuff, bearophile. Thanks for finding that. Please add
> > this as an enhancement request to bugzilla (disallowing (!x&y)
> > expressions).
>
> That really surprises me that it's a common bug. Isn't it obvious that !
On Sun, 2 Jan 2011 10:19:48 +0100
Gour wrote:
> Caligo> So why is D being advertised as a systems programming
> Caligo> language? By saying Linus would not find D appealing you are
> Caligo> basically saying kernel developers would not find it appealing.
>
> Do Linus & co. have to put label o
On Sun, 02 Jan 2011 04:58:28 -0500
bearophile wrote:
> - I like the idea of AST macros, they are powerful, but they add a
> significant amount of complexity to the language. So I am not pushing a lot
> for them, despite I almost hate string mixings and creating code with string
> snippets.
I
On Sun, 02 Jan 2011 01:46:46 -0500
bearophile wrote:
> > My fantasy: bearophile goes to the Nimrod forum and says "Hey, how about
> > this D language, seems interesting..." :o)
>
> That fantasy of yours means that I am interested in using my time to explain
> to Nimrod developers what's good
On Sat, 01 Jan 2011 18:36:17 -0500
bearophile wrote:
> spir:
>
> > (Even reproduced "elif"
>
> Python doesn't have the switch statement, so to write a switch you sometimes
> use a sequence of if statements, in this case "elif" helps keep
On Sun, 2 Jan 2011 06:27:41 +0100
Ulrik Mikaelsson wrote:
> Just discovering
> http://d-programming-language.org/ with much nicer presentation of the
> docs I've already seen, raised my motivation for D just as much as any
> random dozen solved bugs from bugzilla.
I am very much for helping and
Hello,
Using properties allows travesting a method call into direct data access. What
if the underlying member actually is plain data? Would it be possible to
provide a real data member where the language expects a property (for instance
as range empty & front properties)?
Is there any difficul
This language looks *very* interesting and sensibly designed. The author seems
to have taken, in addition to much input from C-like languages and Python, the
best of the Pascal line tradition. Also, he obviously "dared" getting rid of
some legacy garbage. Unfortunately, not all, and took dome m
On Sat, 01 Jan 2011 19:27:57 +0100
Don wrote:
> > AFAIK, using '$' for custom collection types is not yet possible: oDollar
> > is simply not implemented (correct?). But why do we need it? I do not
> > understand the logic requiring an opDollar special method to "desugarise"
> > the '$' operat
Hello,
[This is another currently unfixed point of D2 that prevents us implementing
our project the way we wish it.]
AFAIK, using '$' for custom collection types is not yet possible: oDollar is
simply not implemented (correct?). But why do we need it? I do not understand
the logic requiring a
On Sat, 1 Jan 2011 09:56:25 +0100
Philippe Sigaud wrote:
> As I said in the docs, I got stuck at comparison operators. a < b is
> automatically transformed by the compiler into a.opCmp(b) < 0.
> a.opCmp(b) becomes another lambda and the '< 0' part triggers another
> expansion, ad infinitum...
I
On Thu, 30 Dec 2010 14:34:45 -0600
Andrei Alexandrescu wrote:
> >> Then people probably need to use sqrt(2.0) or sqrt(cast(double)2).
> >
> > I've got a lot of sympathy for the first alternative (absolutely NONE
> > for the second!). But unfortunately, the language allows sqrt(2) to
> > compile
On Thu, 30 Dec 2010 21:13:05 +0100
Don wrote:
> Yes, but OCaML isn't a C-family language, inheriting C's broken
> treatment of literals.
Just for information (I really mean information, not starting a new
discussion): was it proposed to let down such legacy mess form C at the time
when D1-->D
On Thu, 30 Dec 2010 11:19:33 -0600
Andrei Alexandrescu wrote:
> On 12/30/10 6:41 AM, spir wrote:
> > Hello,
> >
> >
> > In the course of a project (1) 2 partner D programmers and myself are
> > currently implementing, we faced 2 issues which prevented us using
On Thu, 30 Dec 2010 15:15:32 + (UTC)
Adam Ruppe wrote:
> > My guess is programmers spend ~ half of their time thinking, a
> > quarter of their time controlling & another quarter fixing;
> > the rest, typing.
>
> I don't know about that! If my personal vices are any indication,
> it is more
On Thu, 30 Dec 2010 13:19:52 + (UTC)
Adam Ruppe wrote:
> === back to the main point ===
>
> Of course, I'm sure there's dozens of editors with a similar feature.
> There might also be an existing option or plugin in your current
> editor of choice. It's worth investigating.
Actually, do yo
On Thu, 30 Dec 2010 05:55:13 -0500
bearophile wrote:
> An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
> value assignment (function signature can't use := ).
> Here there is another idea from Go syntax: if the "then" clause of the "if"
> uses {} then the () around t
Hello,
In the course of a project (1) 2 partner D programmers and myself are currently
implementing, we faced 2 issues which prevented us using a range interface as
planned. We initially intended to do it for better compliance with D's coming
new style, and nice inter-relation with Phobos modu
On Thu, 30 Dec 2010 07:46:19 +0100
Don wrote:
> This problem has already hit Phobos. We inserted a hack so that sqrt(2)
> will work. But exp(1) doesn't work.
> Note that the problems really arise because we've inherited C's rather
> cavalier approach to implicit conversion.
I'm unsure of the p
On Wed, 29 Dec 2010 19:24:12 +0100
Andrej Mitrovic wrote:
> But I really don't see the benefit of changing the semantics of
> import. You won't get shot in the foot since D offers good protection
> from function hijacking.
Yes, I'm aware of this. But this (great) feature is not related to the
d
On Wed, 29 Dec 2010 14:40:31 + (UTC)
Adam Ruppe wrote:
> > (Name qualification in code, I mean at use place, is best used for
> > std or third-party lib, I guess.
>
> I don't see a difference between the two. If the source module
> matters, it matters if it is third party or not. If it doe
On Wed, 29 Dec 2010 11:02:23 -0500
"Steven Schveighoffer" wrote:
> stdout is currently implemented via C's FILE * to allow interleaving of C
> output and D output. However, FILE * has some limitations that may hinder
> performance. If you don't care about interleaving C and D I/O, you could
On Tue, 28 Dec 2010 18:37:37 +0100
Andrej Mitrovic wrote:
> On 12/28/10, Adam Ruppe wrote:
> > That's not the only bad part. It also means refactoring your modules
> > requires changes to the user code too. See my other post here:
>
> Actually, D is equipped to solve even that problem. If you r
On Tue, 28 Dec 2010 16:01:24 + (UTC)
"Adam D. Ruppe" wrote:
> > While you read a module code you don't know where the imported names it
> > uses come from.
> That's a feature.
> [...]
> I started off by writing it all in one module, the one where it
> was used. That was ok until I wanted
On Tue, 28 Dec 2010 14:38:56 +0300
Stanislav Blinov wrote:
> Taking an example from std.algorithm documentation:
>
> 1)
> int[] arr1 = [ 1, 2, 3, 4 ];
> int[] arr2 = [ 5, 6 ];
> auto squares = map!("a * a")(chain(arr1, arr2));
> assert(equal(squares, [ 1, 4, 9, 16, 25, 36 ]));
> // 146 character
Hello,
Out of curiosity, I did some timings of data & function member access on
structs & classes. Actually, to check whether (explicity) referenced structs
would ~ behave like classes in this respect, I added a struct element allocated
via
auto ps = cast(S*)(GC.malloc(S.sizeof));
*ps
On Mon, 27 Dec 2010 18:21:24 + (UTC)
Ary Borenszweig wrote:
> If the function is left as is I expect questions about "Why isn't this
> working?"
> for it to appear on D.learn about 1 time each month.
>
> Exactly like what happens with property += value and other things that lead to
> incorr
On Sun, 26 Dec 2010 12:53:29 -0500
Michel Fortin wrote:
> On 2010-12-26 12:13:41 -0500, Andrei Alexandrescu
> said:
>
> > On 12/26/10 10:12 AM, bearophile wrote:
> >> This is related to this (closed) issue, but this time I prefer to
> >> discuss the topic on the newsgroup:
> >> http://d.purem
On Sun, 26 Dec 2010 22:44:04 +0100
"Jérôme M. Berger" wrote:
> > 8. direct interface to C
> Cython gives it too: it is as easy to write a Cython interface
> module as to write a D interface file for a C library.
Hum, I do not agree at all. As I see it, D binds to C directly, Lua binds to C
ra
On Sun, 26 Dec 2010 12:06:04 -0800
Walter Bright wrote:
> 11. generative programming
Does someone have a pointer to any kind of doc about this? (in D)
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
On Sun, 26 Dec 2010 14:04:28 -0800
Jonathan M Davis wrote:
> On Sunday 26 December 2010 07:08:22 Andrei Alexandrescu wrote:
> > On 12/26/10 8:54 AM, spir wrote:
> > > On Sun, 26 Dec 2010 14:54:12 +0100
> > >
> > > Andrej Mitrovic wrote:
> > &g
On Sun, 26 Dec 2010 14:54:12 +0100
Andrej Mitrovic wrote:
> int i;// auto-initialized to int.init
> int i = void; // not initialized
Thanks. Actually this solves my "semantic" issue, did not even think at 'void'.
(I will use it often). By the way, I don't want to play the superhero with
un
Hello,
I have a problem with D's auto-init feature. When reading in someone else's code
int i;
there is no way, I guess, to know whether this means "i is initialised to 0" or
"i is left undefined". For this reason, in the former case I do explicitely
initialise. Thus,
int i = 0;
On Sun, 26 Dec 2010 00:36:26 + (UTC)
Tomek Sowiński wrote:
> >
> >
> > A random-access range is a bidirectional range OR an infinite forward
> > range that offers the primitive opIndex.
> >
> >
> >
> > I can't be sure whether the former should also provide the primitive
> > 'length'.
>
601 - 700 of 904 matches
Mail list logo
