On 12/21/14 1:59 AM, Russel Winder via Digitalmars-d wrote:
On Sat, 2014-12-20 at 15:16 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
On 12/6/14 7:26 AM, Russel Winder via Digitalmars-d wrote:
Primitive types are scheduled for removal, leaving only reference
types.
Wow, that's a biggie
On Tuesday, 23 December 2014 at 13:56:51 UTC, deadalnix wrote:
On Monday, 22 December 2014 at 21:05:22 UTC, Paulo Pinto wrote:
C and C++ are becoming a niche languages in distributed
computing systems.
That is quite a claim.
Even with new java feature, you'll certainly reduce java's
indire
On Monday, 22 December 2014 at 21:05:22 UTC, Paulo Pinto wrote:
C and C++ are becoming a niche languages in distributed
computing systems.
That is quite a claim.
Even with new java feature, you'll certainly reduce java's
indirection addiction to some extent, but that won't give you
control
On Mon, 22 Dec 2014 15:36:27 +
via Digitalmars-d wrote:
> Heh, btw, I just read on osnews.com that HP is going to create a
> new hardware platform The Machine and a new operating system for
> it based on resistor based non-volatile memory called memristors
> that is comparable to dram in s
On Monday, 22 December 2014 at 17:25:48 UTC, deadalnix wrote:
On Sunday, 21 December 2014 at 10:00:36 UTC, Russel Winder via
Digitalmars-d wrote:
Although the vast majority of Java is used in a basically I/O
bound
context, there is knowledge of and desire to improve Java in a
CPU-
bound context
On 2014-12-21 20:37, Adam D. Ruppe wrote:
1) versions don't match. Stuff like rvm and bundler can mitigate this,
I'm not exactly sure what you're meaning but using Rails without bundler
is just mad.
but they don't help searching the web. Find a technique and try it...
but it requires Rails
On Sunday, 21 December 2014 at 10:00:36 UTC, Russel Winder via
Digitalmars-d wrote:
Although the vast majority of Java is used in a basically I/O
bound
context, there is knowledge of and desire to improve Java in a
CPU-
bound context. The goal here is to always be as fast as C and
C++ for
all C
On Thursday, 18 December 2014 at 08:56:29 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 18 Dec 2014 08:09:08 +
via Digitalmars-d wrote:
On Thursday, 18 December 2014 at 01:16:38 UTC, H. S. Teoh via
Digitalmars-d wrote:
> On Thu, Dec 18, 2014 at 12:37:43AM +, via Digitalmars-d
> wrote:
I tried Ruby back in I think 2008 and had just an absolute beast
of a time getting it running on the servers. PHP, by contrast,
almost just worked.
RoR is a lot better now than it was at that point, though I'm
still not impressed with it. I do some work stuff with it and
often hit pretty rand
On 2014-12-21 19:31, Sean Kelly wrote:
I was following the original RoR book. I got bogged down in setting up
the DB and wiring everything together.
The default settings will use SQLite and if you're on a Mac that will
already be installed. That means you don't have to do anything. For
anyt
On Thursday, 18 December 2014 at 09:20:27 UTC, Jacob Carlborg
wrote:
On 2014-12-17 23:24, Sean Kelly wrote:
Hah. I tried RoR once. I couldn't get the environment set up
and running and eventually just gave up.
I don't know when you tried it last time, but today it's very
easy to install:
On Sat, 2014-12-20 at 15:16 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/6/14 7:26 AM, Russel Winder via Digitalmars-d wrote:
> > Primitive types are scheduled for removal, leaving only reference
> > types.
>
> Wow, that's a biggie. Link(s)? -- Andrei
Simon Ritter laid out the Op
On 12/6/14 7:26 AM, Russel Winder via Digitalmars-d wrote:
Primitive types are scheduled for removal, leaving only reference
types.
Wow, that's a biggie. Link(s)? -- Andrei
On Thu, 18 Dec 2014 09:37:35 +
via Digitalmars-d wrote:
> On Thursday, 18 December 2014 at 08:56:29 UTC, ketmar via
> Digitalmars-d wrote:
> > didn't i say that the whole "64-bit" hype sux? ;-) that's about
> > "memory as database".
>
> Did you? :-) Regular HDD is at 100 IOPS, so I think
On Thursday, 18 December 2014 at 08:56:29 UTC, ketmar via
Digitalmars-d wrote:
didn't i say that the whole "64-bit" hype sux? ;-) that's about
"memory as database".
Did you? :-) Regular HDD is at 100 IOPS, so I think reading 100K
random pages per second would work out fine. PCIe is going
mai
On 2014-12-17 23:24, Sean Kelly wrote:
Hah. I tried RoR once. I couldn't get the environment set up
and running and eventually just gave up.
I don't know when you tried it last time, but today it's very easy to
install:
1. Make sure Ruby is installed
2. $ gem install rails
3. $ rails new
On Thu, 18 Dec 2014 08:09:08 +
via Digitalmars-d wrote:
> On Thursday, 18 December 2014 at 01:16:38 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> > On Thu, Dec 18, 2014 at 12:37:43AM +, via Digitalmars-d
> > wrote:
> >> Regular HD I/O is quite slow, but with fast SSD on PCIe and a
> >>
On Thu, 18 Dec 2014 08:17:47 +
Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 17 December 2014 at 22:24:09 UTC, Sean Kelly wrote:
> > On Wednesday, 17 December 2014 at 17:09:34 UTC, Andrei
> > Alexandrescu wrote:
> >> On 12/4/14 6:39 PM, deadalnix wrote:
> >>> On Thursday, 4 December 2
On Wednesday, 17 December 2014 at 22:24:09 UTC, Sean Kelly wrote:
On Wednesday, 17 December 2014 at 17:09:34 UTC, Andrei
Alexandrescu wrote:
On 12/4/14 6:39 PM, deadalnix wrote:
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder
via
Digitalmars-d wrote:
It's an argument for Java over
On Thursday, 18 December 2014 at 01:16:38 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Dec 18, 2014 at 12:37:43AM +, via Digitalmars-d
wrote:
Regular HD I/O is quite slow, but with fast SSD on PCIe and a
good
database-like index locked to memory…
That's hardly a solution that will wor
On Thu, Dec 18, 2014 at 12:37:43AM +, via Digitalmars-d wrote:
> On Thursday, 18 December 2014 at 00:27:49 UTC, Walter Bright wrote:
> >You're welcome to try it. I've spent a great deal of time on it, and
> >it doesn't pay off.
>
> Regular HD I/O is quite slow, but with fast SSD on PCIe and a
On Wednesday, 17 December 2014 at 22:24:09 UTC, Sean Kelly wrote:
Hah. I tried RoR once. I couldn't get the environment set up
and running and eventually just gave up.
Getting RoR set up and working for me + 4 people in a Windows
environment was absolute hell. I'd never want to go through th
On Thursday, 18 December 2014 at 00:27:49 UTC, Walter Bright
wrote:
You're welcome to try it. I've spent a great deal of time on
it, and it doesn't pay off.
Regular HD I/O is quite slow, but with fast SSD on PCIe and a
good database-like index locked to memory…
On 12/17/2014 1:29 PM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 17 December 2014 at 20:48:39 UTC, Walter Bright wrote:
I know how to do binary formats - the Digital Mars C++ compiler does
precompiled headers using memory mapped files.
It isn't worth it.
Maybe not for headerfiles, but if y
On Wednesday, 17 December 2014 at 17:09:34 UTC, Andrei
Alexandrescu wrote:
On 12/4/14 6:39 PM, deadalnix wrote:
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more
general in reality. This stood
On Wednesday, 17 December 2014 at 20:48:39 UTC, Walter Bright
wrote:
I know how to do binary formats - the Digital Mars C++ compiler
does precompiled headers using memory mapped files.
It isn't worth it.
Maybe not for headerfiles, but if you have an indexed database
representing a compiled f
On 12/17/2014 12:03 PM, ketmar via Digitalmars-d wrote:
yes. but with good design the mmaped binary file can be used as data
structure. and we can avoid lookaheads that current textual parser do,
as we already got AST built for us. just drop the idea that binary file
must be small (in a sense of
On 12/17/2014 11:50 AM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 17 December 2014 at 19:48:00 UTC, Walter Bright wrote:
Yeah, you just need to write another parser for the binary format, rather than
reuse a canned D parser. :-)
A binary format for IR should just be mmap'ed and work without
On Wed, 17 Dec 2014 11:47:24 -0800
Walter Bright via Digitalmars-d wrote:
> >> Storing it as body IR accomplishes nothing practical over storing it as
> >> source
> >> file, i.e. .di files.
> > except that there's no need to parse source code over and over again,
> > which is good for other tool
On Wednesday, 17 December 2014 at 19:48:00 UTC, Walter Bright
wrote:
Yeah, you just need to write another parser for the binary
format, rather than reuse a canned D parser. :-)
A binary format for IR should just be mmap'ed and work without
any parsing.
On 12/11/2014 2:05 AM, Araq wrote:
On Wednesday, 10 December 2014 at 23:23:50 UTC, Walter Bright
wrote:
On 12/10/2014 4:15 AM, Paulo Pinto wrote:
I prefer the model used by the referred languages, where binary libraries and
metadata is used, instead of the C toolchain model.
For example, just
On 12/11/2014 12:05 AM, ketmar via Digitalmars-d wrote:
On Wed, 10 Dec 2014 17:17:11 -0800
Walter Bright via Digitalmars-d wrote:
On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
Yeah, the compiler cannot instantiate the template without access to the
full body. It *could*, though,
On Wed, 2014-12-17 at 09:09 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>
[…]
> Very interesting. Even after all IDE details are factored out, the
> code is quite convoluted. No wonder Ruby on Rails and friends are so
> attractive by comparison. -- Andrei
For the record, the right tool
On 12/4/14 6:39 PM, deadalnix wrote:
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit more
general in reality. This stood out for me:
!…other languages like D and Go are too new to bet my work on."
On 05/12/2014 15:03, Ary Borenszweig wrote:
On 12/5/14, 9:42 AM, Chris wrote:
On Friday, 5 December 2014 at 12:06:55 UTC, Nemanja Boric wrote:
The good thing about unit tests is that they tell you when you break
existing code.
That's the great thing about unittests, and the reason why I write
On Fri, 12 Dec 2014 08:32:39 +0100
Jacob Carlborg via Digitalmars-d wrote:
> On 2014-12-11 09:05, ketmar via Digitalmars-d wrote:
>
> > except that there's no need to parse source code over and over again,
> > which is good for other tools (like completion suggesting, intelligent
> > code browsi
On 2014-12-11 09:05, ketmar via Digitalmars-d wrote:
except that there's no need to parse source code over and over again,
which is good for other tools (like completion suggesting, intelligent
code browsing and so on).
Wouldn't you need to parse the IR?
--
/Jacob Carlborg
11-Dec-2014 04:17, Walter Bright пишет:
On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
Yeah, the compiler cannot instantiate the template without access to the
full body. It *could*, though, if we were to store template body IR in
object files, perhaps under specially-dedicated obje
On Thu, 11 Dec 2014 12:11:35 +
Tobias Pankrath via Digitalmars-d wrote:
> If what you have in mind is indeed impossible with current object
> files, it may
> be worthwhile to create our own. But as I see it, the only
> benefit of storing an AST is compilation speed, which currently
> is no
On Thu, 11 Dec 2014 12:06:39 +
Paulo Pinto via Digitalmars-d wrote:
> > with "AST-companions" D is in position to occupy that niche. D
> > is
> > c-like, D has great metaprogramming abilities, D is
> > open-source. it's
> > doomed to win.
>
> To be honest, with .NET Native and OpenJDK get
On Thu, 11 Dec 2014 12:02:43 +
Tobias Pankrath via Digitalmars-d wrote:
> On Thursday, 11 December 2014 at 11:46:50 UTC, ketmar via
> Digitalmars-d wrote:
> >
> > you can't see how this can help 'cause we don't have such
> > AST-companions yet. i can see how this will help 'cause i have
> >
the core of the component framework a-la BlackBox Component
Builder is
dynamic module system. this requires dynamic linker, and the
linker
must know alot about framework internals to be fast and usable.
with
precompiled modules which keeps symbolic information and ASTs
for
templates such linke
On Thu, 11 Dec 2014 12:04:28 +
Paulo Pinto via Digitalmars-d wrote:
> BlackBox! A fellow user. :)
yeah! i miss BCB almost every day i'm doing any coding.
> Another example, the Oberon operating system, specially the
> System 3 Gadgets framework.
yep, they have the same roots. i didn't ment
On Thursday, 11 December 2014 at 12:00:25 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 11 Dec 2014 10:51:21 +
Tobias Pankrath via Digitalmars-d
wrote:
>> Come on, that is not even a half decent analogy.
> it is. you can't see any uses of (semi)compiled module files
> (and i
> can; it's
On Thursday, 11 December 2014 at 11:46:50 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 11 Dec 2014 09:44:49 +
John Colvin via Digitalmars-d
wrote:
Parsing is so fast it's not worth spending huge numbers of
man-hours building an effective cacheing system for it.
and generating machine cod
On Thursday, 11 December 2014 at 11:46:50 UTC, ketmar via
Digitalmars-d wrote:
you can't see how this can help 'cause we don't have such
AST-companions yet. i can see how this will help 'cause i have
alot of
expirience with turbo/borland pascal and BlackBox Component
Builder.
think a-la BCB ca
On Thu, 11 Dec 2014 10:51:21 +
Tobias Pankrath via Digitalmars-d wrote:
> >> Come on, that is not even a half decent analogy.
> > it is. you can't see any uses of (semi)compiled module files
> > (and i
> > can; it's essential for component framework, for example). i
> > can't see
> > any us
On Thu, 11 Dec 2014 09:44:49 +
John Colvin via Digitalmars-d wrote:
> Parsing is so fast it's not worth spending huge numbers of
> man-hours building an effective cacheing system for it.
and generating machine code is useless at all, it's enough to simply
improve CTFE.
> The rest
> of comp
Come on, that is not even a half decent analogy.
it is. you can't see any uses of (semi)compiled module files
(and i
can; it's essential for component framework, for example). i
can't see
any uses of compiled binaries (i don't need that in component
framework).
Actually I asked in this thread
On Wednesday, 10 December 2014 at 23:23:50 UTC, Walter Bright
wrote:
On 12/10/2014 4:15 AM, Paulo Pinto wrote:
I prefer the model used by the referred languages, where
binary libraries and
metadata is used, instead of the C toolchain model.
For example, just shipping the .TPU/.DCU libraries in
On Thursday, 11 December 2014 at 09:07:18 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 11 Dec 2014 08:57:56 +
Tobias Pankrath via Digitalmars-d
wrote:
>>
>> Storing it as body IR accomplishes nothing practical over
>> storing it as source file, i.e. .di files.
> except that there's no n
On Thu, 11 Dec 2014 09:18:05 +
Tobias Pankrath via Digitalmars-d wrote:
> >> Which usually hold an AST in memory anyway. We have a fast
> >> parser, parsing even a big codebase once is really not a
> >> problem, see DCD for example.
> >>
> >> If the only advantage is to skip a parsing stag
Which usually hold an AST in memory anyway. We have a fast
parser, parsing even a big codebase once is really not a
problem, see DCD for example.
If the only advantage is to skip a parsing stage here or
there, it does not justify the work that would be needed.
as we have a fast compiler too,
On Thu, 11 Dec 2014 08:57:56 +
Tobias Pankrath via Digitalmars-d wrote:
> >>
> >> Storing it as body IR accomplishes nothing practical over
> >> storing it as source file, i.e. .di files.
> > except that there's no need to parse source code over and over
> > again,
> > which is good for ot
On Thursday, 11 December 2014 at 08:05:13 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 10 Dec 2014 17:17:11 -0800
Walter Bright via Digitalmars-d
wrote:
On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, the compiler cannot instantiate the template without
> access to the
>
Storing it as body IR accomplishes nothing practical over
storing it as source file, i.e. .di files.
except that there's no need to parse source code over and over
again,
which is good for other tools (like completion suggesting,
intelligent
code browsing and so on).
Which usually hold an A
On Wed, 10 Dec 2014 17:17:11 -0800
Walter Bright via Digitalmars-d wrote:
> On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
> > Yeah, the compiler cannot instantiate the template without access to the
> > full body. It *could*, though, if we were to store template body IR in
> > objec
On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
Yeah, the compiler cannot instantiate the template without access to the
full body. It *could*, though, if we were to store template body IR in
object files, perhaps under specially-dedicated object file sections. It
wouldn't prevent rev
On Thu, Dec 11, 2014 at 10:17:29AM +1100, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d" wrote in message
> news:mailman.3042.1418240846.9932.digitalmar...@puremagic.com...
>
> >Also, storing a full AST is probably overkill -- lexing and parsing
> >the source generally do
On 10 Dec 2014 18:30, "H. S. Teoh via Digitalmars-d"
wrote:
>
> On Wed, Dec 10, 2014 at 06:15:48PM +, Paulo Pinto via Digitalmars-d wrote:
> > On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
> > Digitalmars-d wrote:
> [...]
> > >In D, this should be akin to:
> > >
> > >// Packa
On 12/10/2014 4:15 AM, Paulo Pinto wrote:
I prefer the model used by the referred languages, where binary libraries and
metadata is used, instead of the C toolchain model.
For example, just shipping the .TPU/.DCU libraries in the Object Pascal world.
If the metadata had enough info in it to do
"H. S. Teoh via Digitalmars-d" wrote in message
news:mailman.3042.1418240846.9932.digitalmar...@puremagic.com...
Also, storing a full AST is probably overkill -- lexing and parsing the
source generally doesn't take up too much of the compiler's time, so we
might as well just use the source cod
On Wednesday, 10 December 2014 at 22:34:50 UTC, Dicebot wrote:
Then please show something that actually helps and is
applicable to D template system. There is not much value in
vague references with "imagine rest yourself" flavor.
To be specific I am interested how would it handle pattern like
On Wednesday, 10 December 2014 at 21:39:42 UTC, Paulo Pinto wrote:
That was just an example, I could have written lots of other
stuff.
Then please show something that actually helps and is applicable
to D template system. There is not much value in vague references
with "imagine rest yourself
On Wednesday, 10 December 2014 at 21:59:57 UTC, deadalnix wrote:
On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto
wrote:
Simple, by dropping C based linker model as I state on my
comment.
Ho please, that is a salesman answer, not an engineer one.
I was talking how the toolchains
On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote:
Simple, by dropping C based linker model as I state on my
comment.
Ho please, that is a salesman answer, not an engineer one.
On Wednesday, 10 December 2014 at 19:24:17 UTC, Dicebot wrote:
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
The libraries contain the required metadata for symbol tables
and code locations that need to be extracted into the
executable/library.
Package definition files c
On Wed, Dec 10, 2014 at 08:33:22PM +0100, Jacob Carlborg via Digitalmars-d
wrote:
> On 2014-12-10 18:43, H. S. Teoh via Digitalmars-d wrote:
>
> >That's why the current object file model doesn't work very well.
> >
> >You'd have to extend the object file format to include compiler IR
> >for templ
On Wed, Dec 10, 2014 at 07:00:24PM +, Tobias Pankrath via Digitalmars-d
wrote:
> >>// my code
> >>foo!(ArcaneType1, DubiousType2)(a, d);
> >
> >That's why the current object file model doesn't work very well.
> >
> >You'd have to extend the object file format to include compiler IR
> >for temp
On 2014-12-10 18:43, H. S. Teoh via Digitalmars-d wrote:
That's why the current object file model doesn't work very well.
You'd have to extend the object file format to include compiler IR for
templates, then the compiler can instantiate templates from that IR
without needing access to the sour
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
The libraries contain the required metadata for symbol tables
and code locations that need to be extracted into the
executable/library.
Package definition files contain the minimum information the
compiler needs to know to se
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround broken function behavior. It is not the usage of
empty templates that is bad but the fact that plain func
// my code
foo!(ArcaneType1, DubiousType2)(a, d);
That's why the current object file model doesn't work very well.
You'd have to extend the object file format to include compiler
IR for
templates, then the compiler can instantiate templates from
that IR
without needing access to the source. W
On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote:
On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath
wrote:
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
On Wed, Dec 10, 2014 at 06:15:48PM +, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
> Digitalmars-d wrote:
[...]
> >In D, this should be akin to:
> >
> >// Package header
> >module functions;
> >void Swap(T)(out T x, out T y);
> >
> >// P
On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath
wrote:
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
..
Paulo
I don't see how symbol table information and relocation
On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 10 December 2014 at 14:16, Paulo Pinto via Digitalmars-d
wrote:
On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias
Pankrath wrote:
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto
wrote:
On Wed, Dec 10, 2014 at 05:19:53PM +, Tobias Pankrath via Digitalmars-d
wrote:
> On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto wrote:
>
> >
> >Lots of options are possible when the C compiler and linker model
> >aren't being used.
> >
> >..
> >Paulo
>
> I don't see how symbol
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
..
Paulo
I don't see how symbol table information and relocation meta data
is sufficient to produce the correct object code if the temp
On 10 December 2014 at 14:16, Paulo Pinto via Digitalmars-d
wrote:
> On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote:
>>
>> On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto wrote:
>>>
>>> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On
On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath
wrote:
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto
wrote:
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto
wrote:
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround broken function behavior. It is not t
On Wednesday, 10 December 2014 at 10:48:12 UTC, Walter Bright
wrote:
On 12/10/2014 2:24 AM, Paulo Pinto wrote:
This cannot be the solution if D aspires to be used in
contexts where binary
libraries are used.
C++ is excused to have template code in headers given the
primitive tooling, but
lang
On 12/10/2014 2:24 AM, Paulo Pinto wrote:
This cannot be the solution if D aspires to be used in contexts where binary
libraries are used.
C++ is excused to have template code in headers given the primitive tooling, but
languages like Ada and Modula-3 support proper information hiding for generi
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto
wrote:
This cannot be the solution if D aspires to be used in contexts
where binary libraries are used.
For completely opaque libraries one can compile against interface
files.
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround broken function behavior. It is not the usage of
empty templates that is bad but the fact that plain func
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround broken function behavior. It is not the usage of
empty templates that is bad but the fact that plain functions
remain broken => not really a solution.
You can compile
On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
I don't see what's the problem with making it an "empty"
template. It
eliminates dead code in your executable if you never call that
function,
it enables attribute inference, and it allows inlining. The
only major
On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
As someone (ab)using empty template "idiom", I agree, we need
a better
solution.
[...]
I don't see what's the problem with making it an "empty"
template. It
eliminates dead code in your executable if you never ca
On Tue, Dec 09, 2014 at 10:22:13PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
> 09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет:
> >On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d
> > wrote:
> >>On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via
> >>Digitalmars-
09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет:
On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d
wrote:
On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
On Tue, Dec 09, 2014 at 07:16:56
On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d
wrote:
> On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d
> wrote:
>> 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
>> >On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via
>> >Digitalmars-d
On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
> 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
> >On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d
> >wrote:
> >>08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
[...]
>
09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote:
[...]
As with any
On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
> 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
> >On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d
> >wrote:
> >[...]
> >>As with any of these situation the convoluted hardcoded
08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
On Mon, Dec 08, 2014 at 08:33:16AM +, Russel Winder via Digitalmars-d wrote:
[...]
As with any of these situation the convoluted hardcoded for a specific
processor code, especially assembly language will always win. I don't
care about th
On Tue, Dec 09, 2014 at 11:09:44AM +, Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> > Yeah, I find in my own experience that gdc -O3 tends to produce code
> > that's consistently ~20% faster than dmd -O, especially in
> >
On Tue, 09 Dec 2014 11:34:34 +
Russel Winder via Digitalmars-d wrote:
> > > I am not up to compiling gdc from source, but compiling ldc2 is very
> > > straightforward,
> > to the extent that i can't build git head. ;-)
>
> Works fine for me, I just built it 15 mins ago.
to be honest i tried
On Tue, 2014-12-09 at 13:22 +0200, ketmar via Digitalmars-d wrote:
> On Tue, 09 Dec 2014 11:09:44 +
> Russel Winder via Digitalmars-d wrote:
[…]
> > GDC is tied to the GCC release program I guess
> nope. it's just lack of developers.
Too much effort expended on DMD I guess ;-)
> > I am not u
On Tue, 09 Dec 2014 11:09:44 +
Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote:
> […]
> > Yeah, I find in my own experience that gdc -O3 tends to produce code
> > that's consistently ~20% faster than dmd -O, especially in
> > comp
1 - 100 of 276 matches
Mail list logo
