I wrote some documentation on how to build a gdc cross-compiler:
http://gdcproject.org/wiki/Cross%20Compiler
For now there's only a tutorial describing how to use crosstool-NG with
gdc, but crosstool-NG already supports many different configurations:
On 2012-11-04 11:44, Johannes Pfau wrote:
Supported OS: linux, windows, bare-metal
No support for Mac OS X? The compilers on Mac OS X are cross-compilers
out of the box.
--
/Jacob Carlborg
Am Sun, 04 Nov 2012 11:48:08 +0100
schrieb Jacob Carlborg d...@me.com:
On 2012-11-04 11:44, Johannes Pfau wrote:
Supported OS: linux, windows, bare-metal
No support for Mac OS X? The compilers on Mac OS X are
cross-compilers out of the box.
AFAICS you can use crosstool-NG on OSX to
On 2012-11-04 12:02, Johannes Pfau wrote:
AFAICS you can use crosstool-NG on OSX to generate cross compilers
which run on OSX and compile for other OS, but you can't create a cross
compiler which runs on windows / linux and compiles for OSX.
Ok, I see. I was mostly thinking of compiling both
On Sunday, 4 November 2012 at 05:58:20 UTC, Jonathan M Davis
wrote:
I think that anything that the compiler can't absolutely
gurantee is @safe
must be @system. If that's annoying in some places, then that's
life, because
we can't compromise on SafeD just because a few things that we
use a lot
And all will see after Tuesday (save for Al Queda or other messing up your
plan of world domination).
middle class. Who/what is this middle class thing that Barrack Obama is
WRITING about? Isn't it a good thing to be a someone controlling the whole
world?
Rape is rape.
Who needs you Bill
He can't back down now. He doesn't need to. He has self-actualized.
Yes, Donald Trump, and if you want to stand for USA I don't care (shove
that up your pipe and smoke it),
Don't vote, sheeple.
It is obvious, (?) that I just hate the law. What law?! The fucking
model has bred.
(Oops, did I just suggest that Donald Trump had worth other than, that
whore?) Hmm?
Yes she was ... pretty (does that make me a loser by default? Shut up,
surely.). Wharten school of , and she married a magnate and had kids and
what?
She did the right thing.
Hang on a second, I was going to make a point?
As I feel right now, I probably could do so, but not to a fat old man,
Rape is rape. But rape rules (ref: see USA). rape is rape, I quote the
leader of the free world.
It doesn't count: he got his sperm in your face and I don't hate him at all
and he knows it can we talk? I.. Not! Donald Trump is an infadel and
aligned with all other monetary magnats of evil that are tryint to replace
mass evil.
Yeah, in my whole life (god forbid I escaped so), I have nothing better to
do than to say . say what? OK, you have a point, but you don't and you
don't kmow. I'm not Brad Pitt. (Cuz I got nothing better to do than to
punch him in the face of that movie... no offense meant, asshole...
On Sunday, 4 November 2012 at 07:23:51 UTC, Job wrote:
And all will see after Tuesday (save for Al Queda or other
messing up your plan of world domination).
Is it possible to have admins remove topics? Or better yet,
anyone can flag it and then the admin can confirm it and it goes
away? Or
On Sunday, 4 November 2012 at 09:02:40 UTC, Era Scarecrow wrote:
Is it possible to have admins remove topics? Or better yet,
anyone can flag it and then the admin can confirm it and it
goes away? Or the admins can Mark him as a spam bot?
Possible but AFAIK unfortunately nobody is doing this.
On Sunday, 4 November 2012 at 09:23:14 UTC, Maxim Fomin wrote:
Possible but AFAIK unfortunately nobody is doing this. I have
never encountered a crazy topic been deleted.
Mmm I've wondered too.. there's cases where new topics are made
by accident (reply via email, and other cases) where it
Era Scarecrow wrote:
On Sunday, 4 November 2012 at 09:23:14 UTC, Maxim Fomin wrote:
Possible but AFAIK unfortunately nobody is doing this. I have
never encountered a crazy topic been deleted.
Mmm I've wondered too.. there's cases where new topics are made
by accident (reply via email, and
rape is rape
I was just getting started, ... you wouldn't know music if ..nothing to
say, huh
I don't get online much, but when I do, I am very drunk.
I don't hate Donald, nor his sperm lotto ticket called what is her
name?
HE was easy pickins... he couldn't find a job if it bit him in the ass. His
daughter was hot but now bred . He has NOTHING.
But what is the point: you are donald stupid ass trump, and the bitch has
been tapped. I don't want her.
11/4/2012 3:15 AM, Mehrdad пишет:
On Saturday, 3 November 2012 at 21:24:29 UTC, Dmitry Olshansky wrote:
it explicitly reinterprets data as chunk of bytes
Sounds like a bad idea
It is a bad idea. In fact it was introduced not long ago.
I'm wondering if it was intentional at all.
--
Dmitry
Oh, OK, I wanna punch that asshole in the face. (3 times)
Can you shut up already and die? Your daughter has had dick in her and
bred: why are you stilll here Donald Trump? Hmm? Mr. Big man. Hmmm.. WTF?
She's not for me, she has bred... why are you still here? Donald Trump,
shouldn't you be dead?
Explain
Cuz I can't do it justice .. no I could!!! if I had just more internet
time. Donald Trump is the reason for all pain, and that goes without
saying: his lil dick daughter ... welll what? pussy is pussy? not! Donald
doesn't know shit... his daughter is teaching him...I should not talk
vote for what? she is tapped.. what is there left to vote for? Yeah, I
wanted to fuck the bitch... but now she has bred what? War?
well, that will cost you big after tax dollars.
what is the difference?
rape is rape
On 2012-11-04 00:12, H. S. Teoh wrote:
My point is, there may are a lot of people with that knowledge in
the community, and a little impulsion from the root should be
helpful, because modern support will make D shine even brighter.
We *have* had repeated requests for this stuff, and I'm sure
On 2012-11-03 17:08, H. S. Teoh wrote:
I find it strange that every so often people clamor for IDE support,
syntax highlighting, debugger support, etc., yet nobody seems to be
willing to contribute actual code. Don't like something about the
current state of D development tools? Well then do
On 11/3/12 7:21 PM, H. S. Teoh wrote:
On Fri, Nov 02, 2012 at 04:17:10PM -0400, Jonathan M Davis wrote:
On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote:
Ah, I see. That makes sense. So basically it's not the source (or
any intermediate step) that decides whether to use the optimization,
On 11/3/12 9:02 PM, Jonathan M Davis wrote:
Andrei seems to think that algorithms should consider input ranges' fronts to
be transient, and that forward ranges and greater shouldn't have transient
fronts. And I don't think that he's said much about it after that (probably
mostly because he was
On 11/4/12 1:31 AM, Jonathan M Davis wrote:
I just thought that I should bring greater attention to
http://d.puremagic.com/issues/show_bug.cgi?id=8838
As it stands, I think that the slicing static arrays being considered @safe is
a major hole in SafeD's safety, and I think that it's one that
On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg
wrote:
I think it would be worth to but in Phobos anyway.
I suppose it works as a temp solution until a real one is
finally implemented, or maybe the mixin behaviour is
Thanks to Jacob Carlborg's suggestion
(news://new.digitalmars.com:119/k6d9se$i46$1...@digitalmars.com), I decided
to create my own little installer for MAC OSX. Albeit a very naive
implementation, it does what I ask it to do... (D2 only). Along the way,
I picked up a little understanding about
On Sunday, November 04, 2012 08:59:10 Andrei Alexandrescu wrote:
Slicing of static arrays is unsafe only if they're stack-allocated and
the slice is subsequently escaped.
If we want to make it so that slicing a static array is @safe when the
compiler can determine for sure that the slice isn't
On Thursday, 1 November 2012 at 15:56:24 UTC, Tobias Pankrath
wrote:
On Thursday, 1 November 2012 at 15:20:11 UTC, Andrei
Alexandrescu wrote:
On 11/1/12 9:47 AM, Paulo Pinto wrote:
Hi everyone,
I just saw this online.
The German magazine c't kompakt has an article about
cool(exotic)
Le 02/11/2012 21:17, Jonathan M Davis a écrit :
On Friday, November 02, 2012 10:01:55 H. S. Teoh wrote:
Ah, I see. That makes sense. So basically it's not the source (or any
intermediate step) that decides whether to use the optimization, but the
final consumer.
Though now we have the issue
Le 04/11/2012 03:26, Jonathan M Davis a écrit :
3. Make it so that ranges which can be transient are non-transient by default
but provide a function to get at a transient version for speed (which was the
fastRange proposal in this thread). The main problem here is that when the
fast range gets
Le 04/11/2012 14:55, Andrei Alexandrescu a écrit :
On 11/3/12 9:02 PM, Jonathan M Davis wrote:
Andrei seems to think that algorithms should consider input ranges'
fronts to
be transient, and that forward ranges and greater shouldn't have
transient
fronts. And I don't think that he's said much
On 03/11/2012 21:29, bearophile wrote:
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not evil,
it's better to avoid module-level mutables. This makes the code more
testable, simpler to understand, less bug prone, and makes functions
more
On 03/11/2012 21:29, bearophile wrote:
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not evil,
it's better to avoid module-level mutables. This makes the code more
testable, simpler to understand, less bug prone, and makes functions
more
On 11/4/12 9:49 AM, deadalnix wrote:
You are explaining here that is reasonable to expect so, not that this
is the most obvious choice, the most simple, or whatever.
Agreed, it would be simpler to just create a new string for each line.
The conclusion exceed the argument here.
I'd also
On 11/4/12 9:36 AM, deadalnix wrote:
Let's put back relevant elements of the solution I propose :
1/ range preserve .front by default .
2/ Ranges that would get performance boost from invalidating .front can
propose a property (we called it .fast in the thread) that return a new
range that
I'm wondering if there is a way to know you are in deprecated
mode or not?
The deprecated attribute is great, because it gives a clear
compile error (as opposed to a static if, which just hides the
function completely).
But the attribute alone is not enough: I have a class with a
On Sunday, 4 November 2012 at 14:59:24 UTC, Faux Amis wrote:
I failed to mention that I am mostly talking about private
module scope variables. I don't see how private module scoped
vars make for less testable, readable or more bug prone code.
It's not like I feel that you should never use
On Sun, Nov 04, 2012 at 08:24:55AM -0500, Andrei Alexandrescu wrote:
On 11/3/12 7:21 PM, H. S. Teoh wrote:
[...]
I wish Andrei would give some input as to how we should proceed with
this. I do consider this a major issue with ranges, because for
efficiency reasons I often write ranges that
11/4/2012 7:16 PM, Andrei Alexandrescu пишет:
On 11/4/12 9:36 AM, deadalnix wrote:
Let's put back relevant elements of the solution I propose :
1/ range preserve .front by default .
2/ Ranges that would get performance boost from invalidating .front can
propose a property (we called it .fast in
Le 04/11/2012 16:16, Andrei Alexandrescu a écrit :
On 11/4/12 9:36 AM, deadalnix wrote:
Let's put back relevant elements of the solution I propose :
1/ range preserve .front by default .
2/ Ranges that would get performance boost from invalidating .front can
propose a property (we called it
This post is in response to Nick's suggestion in this post:
http://forum.dlang.org/thread/k524ke$gvt$1...@digitalmars.com#post-20121104000747.1f10:40unknown
to repost the question here. (please note I have read the
link Nick provided, but as noted in my last post to the c++
list, that link,
On Sunday, 4 November 2012 at 15:48:28 UTC, monarch_dodra wrote:
We've currently implemented version(assert) and
version(debug). Do you think we should request having a
version(deprecated)? I think it would be very helpful.
Thoughts?
We also have version(unittest). version(deprecated) seems
On 11/4/12 11:40 AM, deadalnix wrote:
Le 04/11/2012 16:16, Andrei Alexandrescu a écrit :
On 11/4/12 9:36 AM, deadalnix wrote:
Let's put back relevant elements of the solution I propose :
1/ range preserve .front by default .
2/ Ranges that would get performance boost from invalidating .front
On 11/4/12 11:36 AM, Dmitry Olshansky wrote:
The fact that algorithm doesn't save iteration state != it counts on
transient .front.
I didn't claim that. My strongest claim was:
input-range-having-front-with-mutable-indirection IMPLIES
no-transience-guarantee.
Note the IMPLIES (not
Le 04/11/2012 17:57, Andrei Alexandrescu a écrit :
Indeed I'd misunderstood. So I went back and my current understanding is
that it's all about defining this:
auto transient(R r) if (isInputRange!R)
{
return r;
}
Then certain ranges would implement a property .transient if there's an
On 04-11-2012 16:48, monarch_dodra wrote:
I'm wondering if there is a way to know you are in deprecated mode or not?
The deprecated attribute is great, because it gives a clear compile
error (as opposed to a static if, which just hides the function
completely).
But the attribute alone is not
On 11/4/12 12:26 PM, deadalnix wrote:
I think it fit nicely D's phylosophy, in the sense it does provide a
safe, easy to use interface while providing a backdoor when this isn't
enough.
It doesn't fit the (admittedly difficult to fulfill) desideratum that
the obvious code is safe and fast.
I have a fundamental language design talking point for you. It's
not specific to D. I claim that, most of the time, a programmer
cannot, and shouldn't have to, make the decision of whether to
allocate on stack or heap. For example:
void func(T)()
{
auto t = allocate T from heap or stack?
On 11/4/12 12:35 PM, Tommi wrote:
I have a fundamental language design talking point for you. It's not
specific to D. I claim that, most of the time, a programmer cannot, and
shouldn't have to, make the decision of whether to allocate on stack or
heap.
I don't think that claim is valid. As a
On Sunday, 4 November 2012 at 17:35:09 UTC, Tommi wrote:
I wonder if it would be possible in D to let the compiler
allocate dynamic arrays on stack when it can statically
guarantee that it's safe to do so (no dangling references,
never increasing the size of the array, etc).
David Nadlinger
11/4/2012 9:02 PM, Andrei Alexandrescu пишет:
On 11/4/12 11:36 AM, Dmitry Olshansky wrote:
The fact that algorithm doesn't save iteration state != it counts on
transient .front.
I didn't claim that. My strongest claim was:
input-range-having-front-with-mutable-indirection IMPLIES
On Sunday, 4 November 2012 at 17:38:07 UTC, Andrei Alexandrescu
wrote:
Back to a simpler solution: what's wrong with adding
alternative APIs for certain input ranges? We have byLine,
byChunk, byChunkAsync. We may as well add eachLine, eachChunk,
eachChunkAsync and let the documentation explain
On 11/4/12 11:16 AM, H. S. Teoh wrote:
Fetching lines should be solved by using types; trafficking in
char[] does not offer guarantees about the preservation of the
content. In contrast, trafficking in string formalizes a binding
agreement between the range and its user that the content is
On Sunday, 4 November 2012 at 17:41:17 UTC, Andrei Alexandrescu
wrote:
I don't think that claim is valid. As a simple example,
polymorphism requires indirection (due to variations in size of
the dynamic type compared to the static type) and indirection
is strongly correlated with dynamic
11/4/2012 9:35 PM, Tommi пишет:
I have a fundamental language design talking point for you. It's not
specific to D. I claim that, most of the time, a programmer cannot, and
shouldn't have to, make the decision of whether to allocate on stack or
heap.
Actually it can and most definitely should.
It is mentioned that the D forums are written in D. I wasn't aware of
that. May I ask how? Is vibe being used? Or from scratch, is there any
source code available?
Thanks!
Best regards,
Robert
On Sat, 2012-11-03 at 19:49 +0100, David Nadlinger wrote:
On Saturday, 3 November 2012 at 18:18:50
Am 04.11.2012 18:41, schrieb Andrei Alexandrescu:
On 11/4/12 12:35 PM, Tommi wrote:
I have a fundamental language design talking point for you. It's not
specific to D. I claim that, most of the time, a programmer cannot, and
shouldn't have to, make the decision of whether to allocate on stack
It's written by Vladimir Panteleev using his ae library:
https://github.com/CyberShadow/DFeed
Similar to vibe.d it uses asynchronous I/O and a built-in HTTP server to
get that high level of performance.
I have used it also in modified form for the vibe.d forums before
building a web front end
On 11/4/2012 6:30 AM, stonemaster wrote:
Anyway I think the article has been written some years ago and was just warmed
up to be included in the special edition of c't. I'll try to contact the author
to point out the things mentioned above.
Thanks for following up on this.
On Sunday, 4 November 2012 at 18:14:36 UTC, Dmitry Olshansky
wrote:
extern(C):
int blah(void* ptr);
void func(T)()
{
auto t = allocate T from heap or stack?
blah(t); //now what?
...
}
If blah doesn't store pointer somewhere inside you are fine
with stack. If it does then
On Sunday, 4 November 2012 at 16:44:30 UTC, evansl wrote:
that instantiating a template is inherently expensive
Just a guess, but perhaps pattern-matching templates is
NP-complete?
The whole problem seems to me to be caused by one simple problem
in D:
value vs. reference semantics
If it was clear that the output of a range has value semantics,
then clearly, its copy would not be transient.
And if it was clear that the output has reference semantics, then
clearly, its
On Sunday, 4 November 2012 at 19:42:29 UTC, Tommi wrote:
void func(T)(int n)
{
if (n = 0)
return;
auto t = create variable t of type T
...
func!(T)(n - 1);
}
If func is called with a runtime argument n, then the
programmer cannot determine the most sensible way to
On Sunday, 4 November 2012 at 17:41:19 UTC, Jakob Ovrum wrote:
On Sunday, 4 November 2012 at 17:35:09 UTC, Tommi wrote:
I wonder if it would be possible in D to let the compiler
allocate dynamic arrays on stack when it can statically
guarantee that it's safe to do so (no dangling references,
On 11/04/2012 08:47 PM, Mehrdad wrote:
On Sunday, 4 November 2012 at 16:44:30 UTC, evansl wrote:
that instantiating a template is inherently expensive
Just a guess, but perhaps pattern-matching templates is NP-complete?
That does not say anything about evaluation speed.
On Thursday, 18 October 2012 at 03:07:56 UTC, Malte Skarupke
wrote:
Hello,
I realize that this has been discussed before, but so far there
is no solution and this really needs to be a high priority:
We need a way for a function to declare that it doesn't want
it's argument to be copied, but
On 11/4/2012 9:35 AM, Tommi wrote:
The question of whether variable t should lay in heap or stack, depends not only
on the sizeof(T), but also on the context in which func is called at. If func is
called at a context in which allocating T on stack would cause a stack overflow,
then t should be
On 11/4/2012 1:27 PM, Walter Bright wrote:
Such escape analysis is entirely possible with D without changing any
semantics.
The compiler already does a fairly primitive form of this analysis when deciding
to allocate a closure on the stack or the heap.
On Sunday, 4 November 2012 at 19:59:55 UTC, Mehrdad wrote:
The whole problem seems to me to be caused by one simple
problem in D:
value vs. reference semantics
If it was clear that the output of a range has value semantics,
then clearly, its copy would not be transient.
And if it was clear
On Sunday, 4 November 2012 at 13:57:07 UTC, Damian wrote:
On Saturday, 3 November 2012 at 17:04:31 UTC, Rob T wrote:
On Saturday, 3 November 2012 at 11:09:48 UTC, Jacob Carlborg
wrote:
I think it would be worth to but in Phobos anyway.
I suppose it works as a temp solution until a real one
On 4 November 2012 17:27, Alex Rønne Petersen a...@lycus.org wrote:
On 04-11-2012 16:48, monarch_dodra wrote:
I'm wondering if there is a way to know you are in deprecated mode or not?
The deprecated attribute is great, because it gives a clear compile
error (as opposed to a static if, which
On Sunday, 4 November 2012 at 21:30:39 UTC, monarch_dodra wrote:
Not sure this is specific to D. Just because you pass something
by value doesn't mean somebody else can't modify what's
underneath.
By D I didn't mean the language, I meant the current practices
in Phobos and other libraries,
On Sun, Nov 04, 2012 at 12:38:06PM -0500, Andrei Alexandrescu wrote:
On 11/4/12 12:26 PM, deadalnix wrote:
I think it fit nicely D's phylosophy, in the sense it does provide a
safe, easy to use interface while providing a backdoor when this
isn't enough.
It doesn't fit the (admittedly
On 11/04/2012 10:52 PM, Mehrdad wrote:
By D I didn't mean the language, ...
That is what D is. If you stick to this terminology you will be understood.
On Sunday, November 04, 2012 16:48:26 monarch_dodra wrote:
I'm wondering if there is a way to know you are in deprecated
mode or not?
The deprecated attribute is great, because it gives a clear
compile error (as opposed to a static if, which just hides the
function completely).
But the
http://dlang.org/phobos/std_variant.html
says:
This module implements a discriminated union type (a.k.a. tagged union,
algebraic type).
Yet, the wiki page:
http://en.wikipedia.org/wiki/Tagged_union
says:
a tag field explicitly indicates which one is in use.
and I don't see any
On 05-11-2012 00:31, evansl wrote:
http://dlang.org/phobos/std_variant.html
says:
This module implements a discriminated union type (a.k.a. tagged union,
algebraic type).
Yet, the wiki page:
http://en.wikipedia.org/wiki/Tagged_union
says:
a tag field explicitly indicates which
Congratulations for these new seven chapters translated into English!
http://ddili.org/ders/d.en/index.html
Many thanks for the well done work!
--
Jordi Sayol
On Sunday, 4 November 2012 at 21:27:36 UTC, Walter Bright wrote:
You can't determine this, even at runtime, because you don't
know what subsequent calls will use enough stack to overflow it.
Right, I didn't take into account that heap allocations use some
stack anyway to store the pointers.
On 11/3/2012 8:54 AM, H. S. Teoh wrote:
It's another one of those overhyped bandwagons of questionable lasting
value, that people are jumping on left right and center just because
it's a buzzword.
I'm so glad I never hear Web 2.0 anymore.
On Sunday, 4 November 2012 at 23:23:10 UTC, Walter Bright wrote:
I'm so glad I never hear Web 2.0 anymore.
Because Web 3.0 and Semantic Web is in.
Sorry.
On 04/11/2012 17:05, Chris Cain wrote:
On Sunday, 4 November 2012 at 14:59:24 UTC, Faux Amis wrote:
I failed to mention that I am mostly talking about private module
scope variables. I don't see how private module scoped vars make for
less testable, readable or more bug prone code.
It's not
On 11/4/2012 3:20 PM, Tommi wrote:
It's great that optimizations could be used to eliminate unnecessary heap
allocations. But it could be interesting to imagine a language where it was
impossible for the programmer to explicitly specify the allocation method.
Things would go to heap if it was
Faux Amis:
I think there is nothing wrong with a module scope private var
as in D a module is the first encapsulation and adding a
wrapper only adds noise.
Generally it's better to minimize the scope of variables. So if
you wrap a variable inside a struct you have often reduced its
scope,
Le 04/11/2012 18:41, Andrei Alexandrescu a écrit :
On 11/4/12 12:35 PM, Tommi wrote:
I have a fundamental language design talking point for you. It's not
specific to D. I claim that, most of the time, a programmer cannot, and
shouldn't have to, make the decision of whether to allocate on stack
On 05/11/2012 00:58, bearophile wrote:
Faux Amis:
I think there is nothing wrong with a module scope private var as in D
a module is the first encapsulation and adding a wrapper only adds noise.
Generally it's better to minimize the scope of variables. So if you wrap
a variable inside a
On Sunday, 4 November 2012 at 23:51:15 UTC, Faux Amis wrote:
In your last paragraph you are getting to my point in my other
post:
I think there is nothing wrong with a module scope private var
as in D a module is the first encapsulation and adding a
wrapper only adds noise.
These are
1 - 100 of 144 matches
Mail list logo
