On 2011-08-14 21:20, Jonathan M Davis wrote:
On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:
On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis
wrote:
Personally, I'm
inclined to drop the Os enum along with the os and os_major and os_minor
variables, because I just don't think
On 2011-08-15 01:39, Jonathan M Davis wrote
That's just not going to work. If you use .di files, you lose CTFE and inlining
for anything which isn't in the .di files. As such, there's a definite advantage
for a library to _not_ use .di files. There have been some suggestions about
how to fix that
On 8/14/2011 7:20 AM, Andrei Alexandrescu wrote:
Walter and I have had a long discussion and we thought we'd bring an
idea for community review.
We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters.
... I hope you're joking.
(1) I thought the w
"Brad Roberts" wrote in message
news:mailman.2324.1313368907.14074.digitalmar...@puremagic.com...
>
> Quite frankly, it's too late to pretend that the web and the browser is
Judging by the rest of your post I assume you meant "isn't" not "is"...
> all there is for a large segment of the compute
"Peter Alexander" wrote:
Almost everyone in the games industry knows that C++ is a rubbish
language.
When I talk about D programming language to somebody, I prefer avoiding this
sort of argumentation entirely.
--
Jouko
Timon Gehr wrote:
> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
>>
>>> requiring lazy before lazy arguments basically destroys the reason for
>>> lazy being in the language:
>>>
>>> int foo(lazy 2*3);
>>>
>>> is not better than
>>>
hi,D:)When you have Herpes, HIV/AIDS, hpv,or any other STD, it can feel like
you are all alone in the world DatingHerpesSingles.com is a place where you
didn't have to worry about being rejected Just feel free to chat, share
stories, make friends in your local area.
On Sunday, August 14, 2011 17:39:29 Brad Roberts wrote:
> On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
> > On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
> >> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
> >>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
>
On Sunday, August 14, 2011 3:29:28 PM, Marco Leise wrote:
> Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley :
>
>> On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise wrote:
>>
>>> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :
>>>
>>> On Sat, Aug 13, 2011 at 5:10 AM, bearophile **
wrote:
>
On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
> On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
>> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
>>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> On Sun, 14
- Using 'pragma(lib, "someLib")' in an imported source has no effect,
as long as the imported module is not compiled.
I've added a workaround for that so that linking as depicted in the draft
will work.
martin
I see.
For binary distributions it would be simple to make pragma(lib,) work from
imported sources.
This would allow for something similar to what boost uses with Visual
Studio.
I will add that in the DIP11 tree.
IMHO binary distributions don't allow a simple package distribution,
because
On Monday, August 15, 2011 01:32:02 Martin Nowak wrote:
> On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis
>
> wrote:
> > On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
> >> I've implemented a prototype of the DIP11 draft.
> >> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/
On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis
wrote:
On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11
-- Restrictions --
On Monday, August 15, 2011 01:12:20 Martin Nowak wrote:
> I've implemented a prototype of the DIP11 draft.
> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> https://github.com/dawgfoto/dmd/tree/DIP11
>
> -- Restrictions --
> - It doesn't check for conflicting qualified imports (-
I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11
-- Restrictions --
- It doesn't check for conflicting qualified imports (-Iacme=/path1
-Iacme.a=/path2)
- pragma(importpath, "") must come
Am 14.08.2011, 21:08 Uhr, schrieb bearophile :
Like in Go, a small tool similar to the one that converts Python2 code
to Python3 code is getting useful in D too, to reduce the amount of work
of people (including Phobos dev) that have to update D code to follow
changed in D language.
Bye,
Am 14.08.2011, 22:00 Uhr, schrieb Andrew Wiley :
On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise wrote:
Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley
:
On Sat, Aug 13, 2011 at 5:10 AM, bearophile
**
wrote:
Found though Reddit. It seems Chrome is starting to warm up to the
Native
Cl
On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
> > On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
> >> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> >>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr
wrote:
> requiring laz
On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
requiring lazy before lazy arguments basically destroys the reason for
lazy being in th
On Sun, 14 Aug 2011 22:00:34 +0200, Vladimir Panteleev
wrote:
On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
requiring lazy before lazy arguments basically destroys the reason for
lazy being in the language:
int foo(lazy 2*3);
is not better than
int foo({return 2*3});
What ab
On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
> > On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
> >> requiring lazy before lazy arguments basically destroys the reason for
> >> lazy being in the language:
> >>
> >> int foo(lazy 2
On Sunday, August 14, 2011 16:05:03 Nick Sabalausky wrote:
> "Brad Roberts" wrote in message
> news:mailman.2309.1313347727.14074.digitalmar...@puremagic.com...
>
> > google --> git pre-commit hook
> >
> > Setup whatever sort of checks you want on your local repository and
> > it'll be correct b
On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
requiring lazy before lazy arguments basically destroys the reason for
lazy being in the language:
int foo(lazy 2*3);
is not better than
int foo({return 2*3});
What about requiring "laz
On Sunday, August 14, 2011 22:58:37 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 22:50:22 +0300, Jonathan M Davis
>
> wrote:
> > Brad's suggestion is the correct way to
> > do it, I believe.
>
> The advantage of a .gitattributes file is that you can add it to the
> repository (like .gitignore
On Sun, 14 Aug 2011 22:20:01 +0300, Jonathan M Davis
wrote:
But I do not think that putting that in std.system in an OS-independent
way makes sense.
OK, I agree with your points. No objections.
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
"Brad Roberts" wrote in message
news:mailman.2309.1313347727.14074.digitalmar...@puremagic.com...
>
> google --> git pre-commit hook
>
> Setup whatever sort of checks you want on your local repository and
> it'll be correct before pushing to github to even get into a pull
> request.
That's not r
On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr wrote:
requiring lazy before lazy arguments basically destroys the reason for
lazy being in the language:
int foo(lazy 2*3);
is not better than
int foo({return 2*3});
What about requiring "lazy" only for non-pure delegates?
--
Best regards,
On Sun, Aug 14, 2011 at 10:29 AM, Marco Leise wrote:
> Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :
>
> On Sat, Aug 13, 2011 at 5:10 AM, bearophile **
>> wrote:
>>
>> Found though Reddit. It seems Chrome is starting to warm up to the Native
>>> Client (NaCl) idea, the Chrome Beta now has a
On Sun, 14 Aug 2011 22:50:22 +0300, Jonathan M Davis
wrote:
Brad's suggestion is the correct way to
do it, I believe.
The advantage of a .gitattributes file is that you can add it to the
repository (like .gitignore). I don't think you can set up a pre-commit
hook so that it's copied whe
"dsimcha" wrote in message
news:j295at$1rki$1...@digitalmars.com...
> What's wrong with configuring your editor to convert tabs to spaces?
Because this is a per-project matter, not a universal one. On all of my
projects, I *want* tabs for indentation (why? because I said so ;) ) and so
that's
On Sunday, August 14, 2011 21:50:29 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 21:48:26 +0300, dsimcha wrote:
> > What's wrong with configuring your editor to convert tabs to spaces? I
> > know CodeBlocks, Vim and Notepad++ do this for you if you configure them
> > right (though I don't reme
On 08/14/2011 05:36 PM, Vladimir Panteleev wrote:
On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad wrote:
Consider this example:
// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}
// In module bar.d:
import foo;
bool someCondition() { return false; }
v
On Sunday, August 14, 2011 19:24:21 Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis
>
> wrote:
> > Personally, I'm
> > inclined to drop the Os enum along with the os and os_major and os_minor
> > variables, because I just don't think that we can get them to be cor
Andrei Alexandrescu:
> We found pernicious bugs in
> our code caused by escaping reference parameters, and we're looking into
> adding a rule in our lint program to statically disallow it. If that's
> worthwhile (and I have evidence it is), then it's all the better to put
> the check straight
On Sun, 14 Aug 2011 21:48:26 +0300, dsimcha wrote:
What's wrong with configuring your editor to convert tabs to spaces? I
know CodeBlocks, Vim and Notepad++ do this for you if you configure them
right (though I don't remember exactly how to configure Vim to do this).
Any other editor wo
On 2011-08-14 16:55:08 +, dsimcha said:
Right, but they can be proven safe if they pass locals by ref **to
@safe functions**. I don't think there's any disagreement that @safe
functions shouldn't be allowed to take the address of locals or
parameters.
Actually, no, that's not safe by i
On Sun, 14 Aug 2011 21:36:28 +0300, Nick Sabalausky wrote:
I don't know if this has already been looked into, but to any git/github
gurus here: Is there some way to set up the "D-Programming-Language"
projects (either in git or in github) so that users get warned when they
have tab indents and
What's wrong with configuring your editor to convert tabs to spaces? I
know CodeBlocks, Vim and Notepad++ do this for you if you configure them
right (though I don't remember exactly how to configure Vim to do this).
Any other editor worth its salt should, too. I use this for all my
code, no
On Sunday, August 14, 2011 11:36:28 AM, Nick Sabalausky wrote:
> Ok, I'm one of the "tab-indent" fans, and obviously there are others out
> there. So in contributing some pull requests to phobos/rdmd I've noticed how
> easy it is to forget to convert tabs->spaces before pushing. And others make
Ok, I'm one of the "tab-indent" fans, and obviously there are others out
there. So in contributing some pull requests to phobos/rdmd I've noticed how
easy it is to forget to convert tabs->spaces before pushing. And others make
the same mistake too. Aside from being an inconsistent syle issue, th
On 8/14/2011 1:05 PM, Andrei Alexandrescu wrote:
Pass-by-pointer is really, really ugly when used in high-level D-style
code, and exposes the implementation detail that the D wrapper is using
C code. By explicit cast, do you mean one in dWrapper() that's
encapsulated and invisible to the caller?
On 8/14/11 12:39 PM, dsimcha wrote:
On 8/14/2011 1:05 PM, Andrei Alexandrescu wrote:
Pass-by-pointer is really, really ugly when used in high-level D-style
code, and exposes the implementation detail that the D wrapper is using
C code. By explicit cast, do you mean one in dWrapper() that's
encap
On 8/14/11 12:12 PM, dsimcha wrote:
On 8/14/2011 1:06 PM, Andrei Alexandrescu wrote:
You are exploring an increasingly narrow niche. Is it worth keeping a
hole in the language for the sake of that?
Andrei
Yes!!! Such conservative and inflexible rules have no place in a systems
language, perio
Am 14.08.2011, 06:41 Uhr, schrieb Andrew Wiley :
On Sat, Aug 13, 2011 at 5:10 AM, bearophile
wrote:
Found though Reddit. It seems Chrome is starting to warm up to the
Native
Client (NaCl) idea, the Chrome Beta now has a working NaCl:
http://chrome.blogspot.com/2011/08/building-better-web-
Am 14.08.2011, 14:45 Uhr, schrieb Timon Gehr :
I'd argue that find should actually have been called dropUntil. It is
not evident at all what find does, given the name alone. If it is called
dropUntil, nobody ever needs to read the documentation, be it the guy
who writes the code or the guy
On 8/14/2011 1:06 PM, Andrei Alexandrescu wrote:
You are exploring an increasingly narrow niche. Is it worth keeping a
hole in the language for the sake of that?
Andrei
Yes!!! Such conservative and inflexible rules have no place in a
systems language, period.
On 8/14/11 12:02 PM, dsimcha wrote:
On 8/14/2011 12:54 PM, Andrei Alexandrescu wrote:
I have only little sympathy for this argument; it actually leaves me
more convinced we're on the right path. We're not talking about making
it impossible to do something that you want to do. We're discussing
ab
On 8/14/11 11:55 AM, dsimcha wrote:
Argh, accidentally hit send before I meant to on my last post. Please
ignore.
On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:
Consider the case
of designing a D wrapper for C functionality.
// C, we know it doesn't escape its parameters but the compiler do
On 8/14/2011 12:54 PM, Andrei Alexandrescu wrote:
I have only little sympathy for this argument; it actually leaves me
more convinced we're on the right path. We're not talking about making
it impossible to do something that you want to do. We're discussing
about a change that will make a lot of
Argh, accidentally hit send before I meant to on my last post. Please
ignore.
On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:
Consider the case
of designing a D wrapper for C functionality.
// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);
On 8/14/11 11:51 AM, dsimcha wrote:
On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:
On 8/14/11 10:28 AM, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.
I'm weary of absolute qualifications, particul
On 8/14/2011 12:45 PM, Andrei Alexandrescu wrote:
Exactly. Using scope has been part of the discussion, and our agreement
was that it would be a lot of burden to require manual scope annotations
for non-escaping parameters.
Andrei
Let's assume for the sake of argument that scope is part of the
On 8/14/11 11:50 AM, Jacob Carlborg wrote:
On 2011-08-14 18:45, Andrei Alexandrescu wrote:
On 8/14/11 10:33 AM, Jakob Ovrum wrote:
On 2011/08/15 0:28, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Con
On 8/14/11 10:41 AM, dsimcha wrote:
Another example of why this is a bad idea:
In std.parallelism, I have a function called TaskPool.put, which takes a
Task object by reference, takes its address and puts it on the task
queue. This is used for scoped tasks. However, it's safe because Task
has a
On 2011-08-14 18:45, Andrei Alexandrescu wrote:
On 8/14/11 10:33 AM, Jakob Ovrum wrote:
On 2011/08/15 0:28, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for
On 8/14/2011 12:44 PM, Andrei Alexandrescu wrote:
On 8/14/11 10:28 AM, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.
I'm weary of absolute qualifications, particularly after arguments have
been made i
On 8/14/11 10:33 AM, Jakob Ovrum wrote:
On 2011/08/15 0:28, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for C functionality.
// C, we know it doesn't escape
On 8/14/11 10:28 AM, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole.
I'm weary of absolute qualifications, particularly after arguments have
been made in favor of the idea that are not refuted.
Consi
For serious i18n work I'd use ICU. I believe Mango even has a wrapper for some
of it.
Sent from my iPhone
On Aug 14, 2011, at 8:50 AM, Johannes Pfau wrote:
> Jacob Carlborg wrote:
>> On 2011-08-12 23:02, bioinfornatics wrote:
>>> Dear,
>>> I would like to know how do a multilanguage applicati
On Sun, 14 Aug 2011 02:47:21 +0300, Jonathan M Davis
wrote:
Personally, I'm
inclined to drop the Os enum along with the os and os_major and os_minor
variables, because I just don't think that we can get them to be correct
enough of generally useful enough to be worth having. It's too
OS-spe
Jacob Carlborg wrote:
>On 2011-08-12 23:02, bioinfornatics wrote:
>> Dear,
>> I would like to know how do a multilanguage application. It seem it
>> is possible by using flag -J but they are no document for this
>> feature. link givent in this page
>> http://www.digitalmars.com/d/2.0/dmd-linux.html
On 2011-08-12 23:02, bioinfornatics wrote:
Dear,
I would like to know how do a multilanguage application. It seem it is possible
by using flag -J but they are no document for this feature.
link givent in this page http://www.digitalmars.com/d/2.0/dmd-linux.html seem
to be wrong
if you can do a
Another example of why this is a bad idea:
In std.parallelism, I have a function called TaskPool.put, which takes a
Task object by reference, takes its address and puts it on the task
queue. This is used for scoped tasks. However, it's safe because Task
has a destructor that waits for the ta
On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad wrote:
Consider this example:
// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}
// In module bar.d:
import foo;
bool someCondition() { return fals
On 2011-08-14 16:20, Andrei Alexandrescu wrote:
Walter and I have had a long discussion and we thought we'd bring an
idea for community review.
We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:
class C {
int * p;
this(ref int x) {
p =
On 2011/08/15 0:28, dsimcha wrote:
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the case
of designing a D wrapper for C functionality.
// C, we know it doesn't escape its parameters but the compiler doesn't.
I think this is an absolutely terrible idea, unless it has an "I know
what I'm doing, let me cast away the safety" loophole. Consider the
case of designing a D wrapper for C functionality.
// C, we know it doesn't escape its parameters but the compiler doesn't.
void cFun(int* a, int* b);
// D
Andrei Alexandrescu wrote:
> Walter and I have had a long discussion and we thought we'd bring an idea
> for community review.
>
> We believe it would be useful for safety purposes to disallow escaping
> addresses of ref parameters. Consider:
>
> class C {
> int * p;
> this(ref int x) {
>
On 2011-08-13 18:58, Jonathan M Davis wrote:
On Saturday, August 13, 2011 14:37:46 Jacob Carlborg wrote:
On 2011-08-13 12:51, Jonathan M Davis wrote:
#2 and #3 don't really make sense between OSes, and I'd argue that they
don't make much sense period. I don't know what they'd mean on Windows
in
On 08/14/2011 04:20 PM, Andrei Alexandrescu wrote:
Walter and I have had a long discussion and we thought we'd bring an
idea for community review.
We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:
class C {
int * p;
this(ref int x) {
p
On 2011/08/14 23:20, Andrei Alexandrescu wrote:
Walter and I have had a long discussion and we thought we'd bring an
idea for community review.
We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:
class C {
int * p;
this(ref int x) {
p =
Walter and I have had a long discussion and we thought we'd bring an
idea for community review.
We believe it would be useful for safety purposes to disallow escaping
addresses of ref parameters. Consider:
class C {
int * p;
this(ref int x) {
p = &x; // escapes the address of a ref pa
On 08/14/2011 01:34 PM, Mehrdad wrote:
Consider this example:
// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}
// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
while (!vals.empty)
baz(so
On 08/14/2011 01:29 PM, Jonathan M Davis wrote:
On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:
+1. Having take but not drop does not add to the beauty of the module.
I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
plus renaming std.algorithm.until to takeUntil. "u
Mehrdad wrote:
> Consider this example:
>
> // In module foo.d:
> void baz(bool condition, lazy int value)
> {
> if (condition)
> writeln(value);
> }
>
> // In module bar.d:
> import foo;
> bool someCondition() { return false; }
> voi
Consider this example:
// In module foo.d:
void baz(bool condition, lazy int value)
{
if (condition)
writeln(value);
}
// In module bar.d:
import foo;
bool someCondition() { return false; }
void main()
{
auto vals = [1, 2, 3, 4];
On Sunday, August 14, 2011 13:09:59 Timon Gehr wrote:
> +1. Having take but not drop does not add to the beauty of the module.
> I'm also strongly in favor of adding dropWhile, dropUntil and takeWhile,
> plus renaming std.algorithm.until to takeUntil. "until" is an
> undescriptive name and it has a
On 08/14/2011 08:02 AM, Jonathan M Davis wrote:
Okay. Right now, if you want to remove n elements from the front of a range,
you use popFrontN.
popFrontN(range, n);
This is obviously a highly useful function. However, it does not work very
well when chaining range-based functions. For instance,
when it comes to herpes,I hate how many people are using the word
"end".It's not the end,start your new life DatingHerpesSingles.com
80 matches
Mail list logo
