This is a very easy to read article about the design of LLVM:
http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128
It explains what the IR is:
The most important aspect of its design is the LLVM Intermediate
Representation (IR), which is the form it uses to represent code
On Wednesday, 27 June 2012 at 10:15:37 UTC, Jacob Carlborg wrote:
On 2012-06-27 02:35, John Colvin wrote:
On Tuesday, 26 June 2012 at 18:31:34 UTC, John Colvin wrote:
On Monday, 25 June 2012 at 18:55:22 UTC, Jacob Carlborg wrote:
Are you using the latest sources of DMD?
Yes I am.
sorry, m
Paulo Pinto:
The huge amount of documentation made available at BUILD time,
plus Windows 8 to play with?
WinRT (aka Metro) is COM based.
Instead of me dumping a list of links, what you want to know
exactly?
OK. No need for a list.
Bye,
bearophile
On Jun 28, 2012, at 9:45 AM, Iain Buclaw wrote:
>
> Wouldn't it be useful if the compiler had diagnostics for all implicit
> allocations it makes (ie: closures, array literals)? Similar to that
> of the -vtls switch. These such things you may want to avoid in a
> freestanding environment (no link
On Thursday, 28 June 2012 at 13:39:54 UTC, bearophile wrote:
Paulo Pinto:
as Metro is also native code.
Are you sure? Do you have a reference on this?
Bye,
bearophile
The huge amount of documentation made available at BUILD time,
plus Windows 8 to play with?
WinRT (aka Metro) is COM bas
On Thursday, 28 June 2012 at 14:35:24 UTC, Andrei Alexandrescu
wrote:
On 6/28/12 10:07 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
I think just exposing them via .sig and .exp might be the way
to go?
sig is easy to confuse with sign
.mantissa and .exp
On 22 June 2012 07:35, Walter Bright wrote:
> On 6/21/2012 11:07 PM, Mehrdad wrote:
>>
>> On Thursday, 21 June 2012 at 19:44:40 UTC, Walter Bright wrote:
>>>
>>> On 6/21/2012 9:39 AM, Alex wrote:
is it possible to use D to write code to work without OS?
like i do it with gcc.
>>>
>>
On Thursday, 28 June 2012 at 15:28:10 UTC, Don Clugston wrote:
There's an oddity, though: the type of X.significand would be
dependent on the type of X […]
I don't think this is a problem at all – for example, the type
of T.init depends on T as well…
David
Don Clugston wrote:
> On 28/06/12 17:00, Jens Mueller wrote:
> >Andrei Alexandrescu wrote:
> >>On 6/28/12 10:07 AM, Roman D. Boiko wrote:
> >>>On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
> I think just exposing them via .sig and .exp might be the way to go?
> >>>
> >>>sig is easy
On Thursday, 28 June 2012 at 16:02:43 UTC, Jakob Bornecrantz
wrote:
On Thursday, 28 June 2012 at 07:38:19 UTC, Andrea Fontana wrote:
In production it's just a way to say "completed, not still in
pre-alpha/alpha/beta/testing phase". Usable. Working. Public :)
No difference between commercial, o
On Thursday, 28 June 2012 at 07:38:19 UTC, Andrea Fontana wrote:
In production it's just a way to say "completed, not still in
pre-alpha/alpha/beta/testing phase". Usable. Working. Public :)
No difference between commercial, open source, free, etc ...
Software is never completed only abandone
Don Clugston:
There's an oddity, though: the type of X.significand would be
dependent on the type of X (and for the non-existent quadruple
float, it would be non-existent ucent type!)
But ucents are in D specs and I think their name is already
somewhere in the compiler. While "quadruple" (or
My point (and the reason I somehow hijacked this thread) is that
such functionality would be useful for random access over narrow
strings. Currently random access is missing.
Also this approach fits nicely if random access is needed to
Unicode characters, not just code points.
I don't see mu
On 28/06/12 17:00, Jens Mueller wrote:
Andrei Alexandrescu wrote:
On 6/28/12 10:07 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
I think just exposing them via .sig and .exp might be the way to go?
sig is easy to confuse with sign
.mantissa and .exp
On Thursday, 28 June 2012 at 14:34:03 UTC, Andrei Alexandrescu
wrote:
Well of course I've exaggerated a bit. My point is that
mentioning "200 ns!!!" sounds to the uninformed ear as good as
"2000 ns" or "20 ns", i.e. "an amount of time so short by human
scale, it must mean fast". You need to com
Andrei Alexandrescu wrote:
> On 6/28/12 10:07 AM, Roman D. Boiko wrote:
> >On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
> >>I think just exposing them via .sig and .exp might be the way to go?
> >
> >sig is easy to confuse with sign
>
> .mantissa and .exp
Letting the compiler define
On 06/28/2012 04:35 PM, Andrei Alexandrescu wrote:
On 6/28/12 10:07 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
I think just exposing them via .sig and .exp might be the way to go?
sig is easy to confuse with sign
.mantissa and .exp
Andrei
Imho, it
On 6/28/12 10:07 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
I think just exposing them via .sig and .exp might be the way to go?
sig is easy to confuse with sign
.mantissa and .exp
Andrei
On 6/28/12 8:57 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 12:29:14 UTC, Andrei Alexandrescu wrote:
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, sheer timings say nothing without the
appropriate baselines.
Andrei
I used results of benchmarks for two such algori
On Thursday, 28 June 2012 at 14:04:37 UTC, Mehrdad wrote:
I think just exposing them via .sig and .exp might be the way
to go?
sig is easy to confuse with sign
On Thursday, 28 June 2012 at 14:02:37 UTC, Jens Mueller wrote:
Good luck! I'm looking forward to your solution.
Jens
I think just exposing them via .sig and .exp might be the way to
go?
Don Clugston wrote:
> On 28/06/12 15:31, Jens Mueller wrote:
> >Andrei Alexandrescu wrote:
> >>On 6/22/12 7:41 AM, Don Clugston wrote:
> >>>I think the main thing that's still done in C is the floating point
> >>>formatting.
> >>
> >>Would be great if a contributor could translate FP parsing and
>
On 28/06/12 15:31, Jens Mueller wrote:
Andrei Alexandrescu wrote:
On 6/22/12 7:41 AM, Don Clugston wrote:
I think the main thing that's still done in C is the floating point
formatting.
Would be great if a contributor could translate FP parsing and
formatting code into D. Then we can use it i
Timon Gehr , dans le message (digitalmars.D:170884), a écrit :
>> An I would say I am also entitle to say strings are not normal
>> ranges, since they define length, but have isLength as true,
>
> hasLength as false.
Of course, my mistake.
> They define length, but it is not part of the range int
Paulo Pinto:
as Metro is also native code.
Are you sure? Do you have a reference on this?
Bye,
bearophile
Andrei Alexandrescu wrote:
> On 6/22/12 7:41 AM, Don Clugston wrote:
> >I think the main thing that's still done in C is the floating point
> >formatting.
>
> Would be great if a contributor could translate FP parsing and
> formatting code into D. Then we can use it in CTFE. I need it badly
> for
Timings should not be very different from random access in any
UTF-32 string implementation, because of design of these
algorithms:
* only operations on 64-bit aligned words are performed
(addition, multiplication, bitwise and shift operations)
* there is no branching except at the very top
On 06/28/2012 11:28 AM, Christophe Travert wrote:
Jonathan M Davis , dans le message (digitalmars.D:170872), a écrit :
On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
"Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
completely consistent with regards to how
On Thursday, 28 June 2012 at 12:29:14 UTC, Andrei Alexandrescu
wrote:
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, sheer timings say nothing without the
appropriate baselines.
Andrei
I used results of benchmarks for two such algorithms, which I
like most, taken from here
On 6/28/12 5:28 AM, Christophe Travert wrote:
As a more general comment, I think having a consistent langage is a very
important goal to achieve when designing a langage. It makes everything
simpler, from langage design to user through compiler and library
development. It may not be too late for
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with about
50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up to tens of megabytes. For
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up t
"David Nadlinger" , dans le message (digitalmars.D:170875), a écrit :
> On Thursday, 28 June 2012 at 09:49:19 UTC, Jonathan M Davis wrote:
>>> char[] is not treated as an array by the library, and is not
>>> treated as a RandomAccessRange. That is a second
>>> inconsistency, and it would be avoid
On Thursday, 28 June 2012 at 10:02:59 UTC, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1)
time. Best-performing algorithms can do random
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up t
On Thursday, 28 June 2012 at 05:10:43 UTC, Jonathan M Davis wrote:
On Thursday, June 28, 2012 08:59:32 Gor Gyolchanyan wrote:
Currently strings below dstring are only applicable in
ForwardRange
and below, but not RandomAccessRange as they should be.
Except that they shouldn't be, because you
On Thursday, 28 June 2012 at 09:49:19 UTC, Jonathan M Davis wrote:
char[] is not treated as an array by the library, and is not
treated as a RandomAccessRange. That is a second
inconsistency, and it would be avoided is string were a struct.
So, it looked to me like you were saying that making
On Thursday, June 28, 2012 09:28:52 Christophe Travert wrote:
> I never said strings should support length and slicing. I even said
> they should not. foreach is inconsistent with the way strings are
> treated in phobos, but opIndex, opSlice and length, are inconsistent to.
> string[0] and string.f
Jonathan M Davis , dans le message (digitalmars.D:170872), a écrit :
> On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
>> "Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
>> > completely consistent with regards to how it treats strings. The _only_
>> > inconsinte
On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
> "Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
> > completely consistent with regards to how it treats strings. The _only_
> > inconsintencies are between the language and the library - namely how
> > foreach it
"Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
> completely consistent with regards to how it treats strings. The _only_
> inconsintencies are between the language and the library - namely how foreach
> iterates on code units by default and the fact that while the language
On Thursday, June 28, 2012 09:29:14 Alex Rønne Petersen wrote:
> On 27-06-2012 23:31, Jonathan M Davis wrote:
> > On Wednesday, June 27, 2012 23:00:58 nazriel wrote:
> >> On Wednesday, 27 June 2012 at 08:53:14 UTC, Andrea Fontana wrote:
> >>> I think it would be useful to add on dlang.org a section
In production it's just a way to say "completed, not still in
pre-alpha/alpha/beta/testing phase". Usable. Working. Public :)
No difference between commercial, open source, free, etc ...
On Wednesday, 27 June 2012 at 21:33:20 UTC, Jonathan M Davis
wrote:
On Wednesday, June 27, 2012 23:00:58 n
If you take a good project/library/service, on their homepage
(not wiki) there's
always a list of production projects (that means: "it's not
currently in development but it's public and completed") that use
it.
For example, mongodb. On its homepage there's a list of
production users and a li
On 27-06-2012 23:31, Jonathan M Davis wrote:
On Wednesday, June 27, 2012 23:00:58 nazriel wrote:
On Wednesday, 27 June 2012 at 08:53:14 UTC, Andrea Fontana wrote:
I think it would be useful to add on dlang.org a section to
show how d is used in production. I can't find any page about
it. It see
45 matches
Mail list logo
