Am Fri, 28 Sep 2012 02:04:11 +0200
schrieb "Rob T" :
>
> So if I read this right, I can build phobos/druntime with -fPIC
> from the source code and it will work OK? If so, then why was
> this not done with the latest distrubution package, or is this
> only possible after a certain version numb
On 28 September 2012 12:14, Johannes Pfau wrote:
> Am Fri, 28 Sep 2012 02:04:11 +0200
> schrieb "Rob T" :
>
>>
>> So if I read this right, I can build phobos/druntime with -fPIC
>> from the source code and it will work OK? If so, then why was
>> this not done with the latest distrubution package,
It seems it's very inconsistent where D headers are installed across
various systems/distros. Some use $PREFIX/include/d/, some use
$PREFIX/include//, $PREFIX/include//d/, etc...
Can people who are familiar with how some particular system does it
weigh in here? I think that first of all, we ne
On Friday, 28 September 2012 at 00:17:43 UTC, bearophile wrote:
Most comparisons between Go and D on Reddit aren't good, but
this time there is an almost decent comparison between D and
Rust:
http://www.reddit.com/r/programming/comments/10k9ao/why_i_think_rust_is_the_language_of_the_future/
I
Le 28/09/2012 00:39, ixid a écrit :
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
This is incompatible with current language specs (or will ends up with
highly bizantine rules do define what to do, in a topic where it is
already com
int a, int b = 3, 3;
Considering how the syntax is defined, this will not do what
you expect, and it is not fixable easily without breaking other
constructs.
I thought we'd already covered that part, that was what I agreed
would break far too much code. That is not the heart of the
suggesti
I am trying out gdc 4.7 branch with -fPIC, but the info I'm
getting is that even with a successulf PIC build I will still not
be able to reliably execute D functions directly from C/C++ code.
Old patch, which shows what needs to be done:
https://bitbucket.org/goshawk/gdc/issue/166/add-shared-l
On 28 September 2012 17:43, Rob T wrote:
> I am trying out gdc 4.7 branch with -fPIC, but the info I'm getting is that
> even with a successulf PIC build I will still not be able to reliably
> execute D functions directly from C/C++ code.
>
>
>> Old patch, which shows what needs to be done:
>>
>>
Le 27/09/2012 00:38, bearophile a écrit :
Jonathan M Davis:
It sounds to me like the reason that structural typing is needed is
because
Tuple allows you to name its fields, which I've always thought was a
bad idea,
I have appreciated named fields of D tuples since the beginning, I have
found
Le 27/09/2012 08:17, Jacob Carlborg a écrit :
On 2012-09-27 00:38, bearophile wrote:
I have appreciated named fields of D tuples since the beginning, I have
found them quite handy. With them sometimes you don't need to unpack a
tuple, you can just access its fields with a nice name, avoiding to
On 9/28/12, Bernard Helyer wrote:
> By the time the compiler even has a concept of an 'if statement'
> or a 'block' the whitespace is long gone. Not to say you
> couldn't change the lexing model to detect such things,
> but it's not a simple as you make it sound.
I see, so it's an implementation
The Rust website says this:
Generic types yes, only simple, non-turing-complete substitution
After seeing that I just assumed the language was worthless and
ignored it.. is there something more to this?
On Friday, 28 September 2012 at 17:07:16 UTC, Iain Buclaw wrote:
Because the [bleeping] runtime does not support running from a
shared library.
I suppose the answer is very complicated, but why can't the
runtime execute as a shared lib? Is it a design limitation of the
runtime model? This s
On Fri, 28 Sep 2012 08:02:21 -0500, Alex Rønne Petersen
wrote:
It seems it's very inconsistent where D headers are installed across
various systems/distros. Some use $PREFIX/include/d/, some use
$PREFIX/include//, $PREFIX/include//d/, etc...
Can people who are familiar with how some part
On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:
The Rust website says this:
Generic types yes, only simple, non-turing-complete substitution
After seeing that I just assumed the language was worthless
and
ignored it.. is there something more to this?
As far as I underst
On Thursday, 27 September 2012 at 17:10:07 UTC, Jacob Carlborg
wrote:
Actually, I seriously doubt everything is working as expected.
I tried to check how TLS, EX, etc. (mostly exposed to dll issue)
are working and here is some kind of test:
https://github.com/mxfm/sharedtest. Unfortunately sc
On Friday, 28 September 2012 at 13:01:48 UTC, Alex Rønne
Petersen wrote:
It seems it's very inconsistent where D headers are installed
across various systems/distros. Some use $PREFIX/include/d/,
some use $PREFIX/include//, $PREFIX/include/triple>/d/, etc...
Can people who are familiar with ho
On 28 September 2012 18:54, Rob T wrote:
> On Friday, 28 September 2012 at 17:07:16 UTC, Iain Buclaw wrote:
>>
>>
>> Because the [bleeping] runtime does not support running from a shared
>> library.
>
>
> I suppose the answer is very complicated, but why can't the runtime execute
> as a shared lib
On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:
The Rust website says this:
Generic types yes, only simple, non-turing-complete substitution
After seeing that I just assumed the language was worthless
and
ignored it.. is there something more to this?
Relevant:
http://c
There are also some people that think that compile time
metaprogramming is the single best thing happened to programming
languages. And, hey, what language will I use if you tear it
apart from D? :P
On Friday, 28 September 2012 at 18:21:32 UTC, Paulo Pinto wrote:
On Friday, 28 September 2012
On Fri, 28 Sep 2012 23:54:10 +0200
"Peter Alexander" wrote:
> On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote:
> > The Rust website says this:
> >
> > Generic types yes, only simple, non-turing-complete
> > substitution
> >
> > After seeing that I just assumed the language
On Fri, Sep 28, 2012 at 3:21 PM, Nick Sabalausky <
seewebsitetocontac...@semitwist.com> wrote:
> (My apologies if the article's author is reading this, no offense was
> intended.)
Doubt it. I believe the author was Rob Pike.
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic type
inference does.
Examples:
-
enum MyDir
On 29-09-2012 03:55, Tommi wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you don't
need to explicitly specify the scope of the enum value. This would
reduce redundancy in typing, just like automatic type inference does.
On 29-09-2012 04:08, Andrej Mitrovic wrote:
I've noticed I'm having to do a lot of to!string calls when I want to
call the versatile writef() function. So I was thinking, why not
introduce a special zero-terminated string specifier which would both
alleviate the need to call to!string and would p
On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne
Petersen wrote:
While the idea is reasonable, the problem then becomes that if
you accidentally pass a non-zero terminated char* to %sz, all
hell breaks loose just like with printf.
That's the same risk with to!string(), yes? We aren't
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne
Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply throw a compile error about the ambigui
On 29-09-2012 04:31, Tommi wrote:
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply thro
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic
type inference does.
Examples:
-
enum MyDir
On Saturday, September 29, 2012 03:55:48 Tommi wrote:
> enum MyFruit { apple, orange, banana }
>
> MyFruit fruit;
>
> switch (fruit)
> {
> case apple: break; // Case expressions know what type to
> case orange: break; // expect based on the switch expression
> case banana: break;
On 9/29/12, David Piepgrass wrote:
> I like the spirit of this feature, but as Alex pointed out,
> ambiguity is possible (which could theoretically cause errors in
> existing code)
It could also cause subtle problems because enum values are implicitly
convertible to the enum's base type. Take thi
On 9/29/12, Jonathan M Davis wrote:
> you could simply use with to solve the problem:
>
> with(MyFruit)
> {
> switch(fruit)
> {
> case apple: break;
> case orange: break;
> case banana: break;
> }
> }
>
It's even simpler:
switch(fruit) with (MyFruit)
{
case
On Saturday, 29 September 2012 at 02:37:40 UTC, Alex Rønne
Petersen wrote:
Regardless of the conditions under which to throw an error, it
would be a breaking change.
I guess that's a bad thing. Hmmm... too bad.
Well... maybe we could make it so that variables of the requested
enum type are
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable. So there is a sort of decrease
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been
doing it thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to
places where named enum variables are expected, try t
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable.
I might also add, that once
On 29-09-2012 06:06, Tommi wrote:
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been doing it
thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to places
where named en
On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne
Petersen wrote:
It's an awful lot of magic (it's not as easy in the
implementation as it sounds like) for questionable gain when we
have the with statement IMO.
"it's not as easy in the implementation as it sounds like"
-
On Saturday, 29 September 2012 at 05:08:12 UTC, Tommi wrote:
then that's completely an unacceptable argument. The question
of how much work it is to implement, has nothing to do with
whether it's a good feature to have or not. And that's what
we're discussing.
Except a theoretical feature doe
On Fri, 28 Sep 2012 18:33:31 -0700
José Armando García Sancio wrote:
> On Fri, Sep 28, 2012 at 3:21 PM, Nick Sabalausky <
> seewebsitetocontac...@semitwist.com> wrote:
>
> > (My apologies if the article's author is reading this, no offense
> > was intended.)
>
>
> Doubt it. I believe the autho
40 matches
Mail list logo
