On 29 October 2013 13:47, growler wrote:
> On Tuesday, 29 October 2013 at 00:45:59 UTC, Manu wrote:
>
>> On 29 October 2013 04:33, monarch_dodra wrote:
>>
>> On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
>>>
>>> I had a lot of informal conversations with Walter trying to get my head
My understanding of that is S is not affected by the alignment
of its fields.
To clarify, I mean the *alignment* of S is not affected by the
alignment of its fields.
On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:
On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
Any progress?
There is no way to do something best with llvm?
I don't really understand why for static and dynamic libraries
we need rely on OS implementation. llvm inte
On Tuesday, 29 October 2013 at 00:45:59 UTC, Manu wrote:
On 29 October 2013 04:33, monarch_dodra
wrote:
On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
I had a lot of informal conversations with Walter trying to
get my head
around the details here.
To my recollection, the intent wa
I am using the new std.process and am disappointed with it.
There is no convenient function to replace the running process with a
new one. There used to be the exec() family of functions, which
conveniently use string[] for arguments etc., but now the doc says:
These functions ar
27.10.2013 4:08, Timon Gehr пишет:
On 10/26/2013 05:42 PM, Andrei Alexandrescu wrote:
While messing with std.allocator I explored the type below. I ended up
not using it, but was surprised that implementing it was quite
nontrivial. Should we add it to stdlib?
Theory: http://en.wikipedia.org/wik
On 29 October 2013 04:33, monarch_dodra wrote:
> On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
>
>> I had a lot of informal conversations with Walter trying to get my head
>> around the details here.
>> To my recollection, the intent was that it should behave like C, and that
>> S.align
On 28/10/13 21:22, Joakim wrote:
Really? The claims that llvm has a cleaner codebase, is easier to use because
it's all properly split up into different libraries, and introduces new features
like better error reporting: that's all "PR?"
It's my understanding from Iain's talks that the GCC bac
On 28/10/13 22:07, David Nadlinger wrote:
Have you looked at the quality of error messages in Clang or its explicitly
designed tooling/IDE integration API?
Yea, the quality of error messages with Clang is spectacular. I still remember
the first time I tried using it -- just on a whim -- and w
On 28/10/13 20:02, Iain Buclaw wrote:
I don't see it that way. Up until now at least I haven't seen
anything they do that wasn't already do-able in GCC. They just do a
better job at PR (which is what you expect from Apple anyway).
Ah, that was the option I overlooked :-)
On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:
Any progress?
There is no way to do something best with llvm?
I don't really understand why for static and dynamic libraries we
need rely on OS implementation. llvm intermediate byte code
isn't fast enough translatable at runtime
On 28 October 2013 21:24, David Nadlinger wrote:
> On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:
>>
>> From what I've read and gathered from David over a period of some
>> conversations. Clang infrastructure-wise is much like gcc-3.3/gcc-4.0
>> was - they have a well defined AST
On Monday, 28 October 2013 at 20:44:11 UTC, Jacob Carlborg wrote:
That sounds a bit implausible. New language keyword or
something to load
a library or object file. My best guess is that extern(C)
dlopen() will
just work correctly, failing that I'd think we need an
equivalent Phobos
call.
It
On Monday, 28 October 2013 at 18:33:49 UTC, monarch_dodra wrote:
But is that really what it means though? From the above
conversation, it would instead appear to mean that:
struct S
{
int i;
align(128) int j;
}
in this case, the *padding* needed until we reach j is 128
bytes.
Like Man
On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote:
From what I've read and gathered from David over a period of
some
conversations. Clang infrastructure-wise is much like
gcc-3.3/gcc-4.0
was - they have a well defined AST that is capable of
representing
everything you'd expect in
On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
I don't see it that way. Up until now at least I haven't seen
anything they do that wasn't already do-able in GCC.
Have you looked at the quality of error messages in Clang or its
explicitly designed tooling/IDE integration API?
On 2013-10-28 20:02, Iain Buclaw wrote:
I don't see it that way. Up until now at least I haven't seen
anything they do that wasn't already do-able in GCC. They just do a
better job at PR (which is what you expect from Apple anyway).
I didn't say it wasn't doable. I can't say for sure since I
On 28 October 2013 20:22, Joakim wrote:
> On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote:
>>
>> On 28 October 2013 18:38, Joseph Rushton Wakeling
>> wrote:
>>>
>>> It certainly seems to be true that LLVM is moving faster innovation-wise.
>>> I
>>> don't know how much of that is dow
On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu
wrote:
Please destroy! I've literally sweat as I'm sending this :o).
Andrei
Going through the code today after reading the thread for the
past few days I was blown away by the depth of the concepts
involved. Now the informat
On 2013-10-28 19:33, Joseph Rushton Wakeling wrote:
On 28/10/13 18:33, Joakim wrote:
Do you have any evidence that they've exerted "proprietary control"
over llvm,
say by adding closed modules to their compiler?
I understand how you could interpret it that way, but my email didn't
actually sug
On 10/28/2013 11:50 AM, eles wrote:
Pull requests are welcome!
You pre-approve?
It'll be subject to review by the community.
On 2013-10-28 19:00, Steve Teale wrote:
On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:
On 2013-10-28 18:45, Steve Teale wrote:
Is there a description somewhere of how this will work? Is it language,
Phobos, linker, or what.
I guess it's compiler and runtime.
That sounds
On 2013-10-28 19:00, Steve Teale wrote:
That sounds a bit implausible. New language keyword or something to load
a library or object file. My best guess is that extern(C) dlopen() will
just work correctly, failing that I'd think we need an equivalent Phobos
call.
Sorry, I wasn't very clear. Th
On Monday, 28 October 2013 at 18:34:11 UTC, Joseph Rushton
Wakeling wrote:
On 28/10/13 18:33, Joakim wrote:
Do you have any evidence that they've exerted "proprietary
control" over llvm,
say by adding closed modules to their compiler?
I understand how you could interpret it that way, but my e
On 20.10.2013 05:51, Brad Anderson wrote:
Fifth and hopefully final version. Not much changed. I put this together
so it represented the final iteration of my changes that will be going
into pull requests.
I stopped it from downloading a modified dmd2beta.zip (because of the
licensing issue I'
On 28 October 2013 18:38, Joseph Rushton Wakeling
wrote:
> On 28/10/13 18:48, Jacob Carlborg wrote:
>>
>> From what I've heard and read (mostly from WWDC videos) Apple doesn't
>> feel they
>> can technically do what they want with a compiler with GCC.
>>
>> I guess they technically can but it's t
On Monday, 28 October 2013 at 16:06:48 UTC, Walter Bright wrote:
On 10/28/2013 2:33 AM, eles wrote:
That overlooks what happens if another thread changes the
memory in between the read and the write. Hence the issues of
memory barriers, lock prefixes, etc.
Synchronizing the access to the reso
On 28/10/13 18:48, Jacob Carlborg wrote:
From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they
can technically do what they want with a compiler with GCC.
I guess they technically can but it's too much work with the GCC code base.
It certainly seems to be true that L
On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
I had a lot of informal conversations with Walter trying to get
my head
around the details here.
To my recollection, the intent was that it should behave like
C, and that
S.alignof must certainly == 128 in that case. It can't work
otherwi
On Monday, 28 October 2013 at 18:01:14 UTC, Steve Teale wrote:
That sounds a bit implausible. New language keyword or
something to load a library or object file. My best guess is
that extern(C) dlopen() will just work correctly, failing that
I'd think we need an equivalent Phobos call.
1) it
On 28/10/13 18:33, Joakim wrote:
Do you have any evidence that they've exerted "proprietary control" over llvm,
say by adding closed modules to their compiler?
I understand how you could interpret it that way, but my email didn't actually
suggest that Apple had any plans to close-source the co
On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:
On 2013-10-28 18:45, Steve Teale wrote:
Is there a description somewhere of how this will work? Is it
language,
Phobos, linker, or what.
I guess it's compiler and runtime.
That sounds a bit implausible. New language keyword
On 2013-10-28 18:45, Steve Teale wrote:
Is there a description somewhere of how this will work? Is it language,
Phobos, linker, or what.
I guess it's compiler and runtime.
--
/Jacob Carlborg
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote:
Am 27.10.2013 09:08, schrieb Steve Teale:
Any progress?
Yes. The implementation of the linux part seems to be done and
will be included in 2.064. On windows it will take some time
because "export" has to be fixed first.
Kind
On 2013-10-28 18:33, Joakim wrote:
I actually talked to the head llvm guy at Apple about this possibility a
couple years back and he was adamantly against anyone outside closing up
parts of the compiler. Of course, he may not get to make that decision
at Apple and we can't know the truth unless
On 2013-10-28 16:49, Joseph Rushton Wakeling wrote:
Surely, but we should have sympathy for Apple's desire to be able to
exert proprietary control over their products because ... ? :-)
Don't get me wrong, LLVM itself is a fantastic project, and as long as
people contribute great code to great f
On Monday, 28 October 2013 at 15:49:41 UTC, Joseph Rushton
Wakeling wrote:
On 28/10/13 14:22, evilrat wrote:
sure, but i would prefer LLVM license over GCC if i were in
Apple dev team(and
that what they did). also LLVM is quite young, so who knows
what people
contribute to it in near future...
On 10/28/2013 12:49 AM, Russel Winder wrote:
On Sun, 2013-10-27 at 02:12 -0700, Walter Bright wrote:
[…]
Bitfield code generation for C compilers has generally been rather crappy. If
you wanted performant code, you always had to do the masking yourself.
Endianism and packing have always been t
On 10/28/2013 2:33 AM, eles wrote:
(For example, what really happens with a+=1 ? Should it generate an INC, or an
ADD, or a MOV/ADD/MOV triple for MMIO? Where do the barriers go? Do you even
need barriers? Should a LOCK prefix be emitted? How is the compiler supposed
to know just how the MMIO wor
On 28/10/13 14:22, evilrat wrote:
sure, but i would prefer LLVM license over GCC if i were in Apple dev team(and
that what they did). also LLVM is quite young, so who knows what people
contribute to it in near future...
Surely, but we should have sympathy for Apple's desire to be able to exert
On 10/28/13 8:15 AM, Andrei Alexandrescu wrote:
On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote:
On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote:
Just implemented AlignedMallocator and pushed.
http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
U
On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote:
On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote:
Just implemented AlignedMallocator and pushed.
http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
Untested on Windows.
It seems inconsistent that a
On Monday, 28 October 2013 at 12:39:53 UTC, Joseph Rushton
Wakeling wrote:
On 28/10/13 00:52, Timothee Cour wrote:
genuine question: is there any advantage of gcc over llvm ?
For Apple, probably not. But GCC supports a much, much wider
set of architectures than LLVM.
sure, but i would pref
On Monday, 28 October 2013 at 13:06:43 UTC, Craig Dillabaugh
wrote:
On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote:
Walter Bright:
http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
I have found one of the several voices that reminds us of the
On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote:
Walter Bright:
http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
I have found one of the several voices that reminds us of the
advantages of dynamic typing:
http://www.srl.inf.ethz.ch/workshop2
On 28/10/13 00:52, Timothee Cour wrote:
genuine question: is there any advantage of gcc over llvm ?
For Apple, probably not. But GCC supports a much, much wider set of
architectures than LLVM.
I find that have repeated myself a lot in each section/reply below, I am
not sure whether you'd prefer I just reply with those points once, or
inline, I chose inline so as it make it clear I was not ignoring your
points, and to make it clear which of my arguments apply to which point...
:)
On Friday, 25 October 2013 at 16:31:54 UTC, Max Samukha wrote:
If you define the string type to include "null", then "null"
should be either identical to "empty" in *all cases* or
distinct from that in all cases.
AFAIK, that's how equality operator works, use it and you will
get the desired s
Hi all,
Does anybody know what's the current story with 64-bit Linux
backtraces? I've seen a couple of posts here and on stackoverflow
(like this
http://stackoverflow.com/questions/10527901/d2-not-getting-any-backtrace-info),
couldn't find any definitive answers for the 64-bit case.
./test(
On Monday, 28 October 2013 at 08:42:12 UTC, Walter Bright wrote:
On 10/28/2013 1:13 AM, Russel Winder wrote:
Ask any two people, even ones in this thread, what "volatile"
means, and you'll get two different answers. Note that the
issues of reordering, caching, cycles, and memory barriers are
s
On 2013-10-28 09:40, David Nadlinger wrote:
They are trying to phase out GCC altogether, as they are stuck with an
ancient version due to licensing issues (GPLv3).
The Clang driver was specifically engineered to be a drop-in replacement
for GCC, so given that many Makefiles are hard-coded to us
Walter Bright:
http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8
I have found one of the several voices that reminds us of the
advantages of dynamic typing:
http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf
(I was away for few days.)
Bye,
bearophile
On 10/28/2013 1:13 AM, Russel Winder wrote:
My experience, admittedly late 1970s, early 1980s then early 2000s
concurs with yours that only a small amount of code requires this read
and write behaviour, but where it is needed it is crucial and in areas
where every picosecond matters (*). I disagr
On Monday, 28 October 2013 at 08:02:45 UTC, Jacob Carlborg wrote:
No, I don't see any advantage. Although I don't like that Apple
silently changes what gcc/g++ is.
They are trying to phase out GCC altogether, as they are stuck
with an ancient version due to licensing issues (GPLv3).
The Clan
On Mon, Oct 28, 2013 at 12:08 AM, Iain Buclaw wrote:
> On 27 October 2013 23:43, Timothee Cour wrote:
> > ideal syntax would be something along those lines:
> >
> > try{...}
> > catch(SomeThrowableType e, &callback_before_unwinding){...}
> > with callback_before_unwinding of type 'void function(
On Fri, 2013-10-25 at 13:04 -0700, Walter Bright wrote:
[…]
> I've written device drivers and embedded systems. The quantity of code that
> deals with memory-mapped I/O is a very, very small part of those programs.
> The
> subset of that code that needs to exactly control the read and write cycl
On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu
wrote:
Just implemented AlignedMallocator and pushed.
http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator
Untested on Windows.
It seems inconsistent that allocate() forwards to
alignedAllocate(), while re
On 2013-10-28 00:52, Timothee Cour wrote:
genuine question: is there any advantage of gcc over llvm ?
Betting over clang/llvm/lldb seems to make more sense.
No, I don't see any advantage. Although I don't like that Apple silently
changes what gcc/g++ is.
--
/Jacob Carlborg
On Sun, 2013-10-27 at 02:12 -0700, Walter Bright wrote:
[…]
> Bitfield code generation for C compilers has generally been rather crappy. If
> you wanted performant code, you always had to do the masking yourself.
Endianism and packing have always been the bête noir of bitfields due to
it not bein
On 10/27/2013 11:59 PM, Ali Çehreli wrote:
Could others chime in and reopen this bug please. It has just been closed as
WORKSFORWALTER. ;)
http://d.puremagic.com/issues/show_bug.cgi?id=11362
Correction: it worksforme in the 2.064 beta. The commit that broke it occurs
only in the 2.065 mast
On 10/28/2013 12:31 AM, Walter Bright wrote:
On 10/27/2013 11:59 PM, Ali Çehreli wrote:
Could others chime in and reopen this bug please. It has just been
closed as
WORKSFORWALTER. ;)
http://d.puremagic.com/issues/show_bug.cgi?id=11362
Correction: it worksforme in the 2.064 beta. The commi
On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu
wrote:
Hello,
I know it's been a long wait. Hopefully it was worth it. The
alpha release of untyped allocators is ready for tire-kicking
and a test drive.
About time! ;) But it was definitely worth waiting for. I don't
have
On 27 October 2013 23:43, Timothee Cour wrote:
> ideal syntax would be something along those lines:
>
> try{...}
> catch(SomeThrowableType e, &callback_before_unwinding){...}
> with callback_before_unwinding of type 'void function(Throwable t)'
>
> The semantics of which is:
> if 'e' is about to b
On 10/26/2013 12:12 AM, Kapps wrote:
With git master using OSX Mavericks I'm noticing that I'm no longer
seeing any assertion failure messages from inside unittest blocks.
For example with:
import std.stdio;
unittest {
writeln("Reached unittest.");
assert(0);
writeln("After faile
64 matches
Mail list logo
