On Wed, 04 Feb 2015 07:26:04 +, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
>> as for uglyness... it's too late to thing about this. one more,
>> one less... ;-)
>
> Are you following the reasoning: the uglier the better, because that
> will set
Oops, no, not new.
On 4 February 2015 at 15:16, Daniel Murphy via Digitalmars-d
wrote:
> "Manu via Digitalmars-d" wrote in message
> news:mailman.5867.1423017226.9932.digitalmar...@puremagic.com...
>
>> In the inevitable case that I always seem to find myself in, where I'm
>> wrapping something in a thin shim that
Looks like a relatively new function, so I guess, snn simply
doesn't implement it.
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
as for uglyness... it's too late to thing about this. one more,
one less... ;-)
Are you following the reasoning: the uglier the better, because
that will set us up for a clean slate syntax redesign? :)
On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
>> there. i still can't see what's wrong with `@attribute("inline")`,
>> `@attribute("force_inline")` and so on. ah, except it breaks one of the
>> first rules in The Book
On Tuesday, 3 February 2015 at 22:41:30 UTC, Jonathan M Davis
wrote:
Well, as far as I can tell, that's pretty much exactly what
Walter meant by
"hot" and "cold" - how likely they are to be called, with the
idea that the
compiler could then use that information to better optimize -
be it inlini
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
there. i still can't see what's wrong with
`@attribute("inline")`,
`@attribute("force_inline")` and so on. ah, except it breaks
one of the
first rules in The Book Of D: "try to escape uniformity
whenever it is possible".
Using pragm
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Wednesday, February 04, 2015 03:33:50 Martin Nowak via Digitalmars-d wrote:
> As you might have noticed already, this functionality is currently
> missing in phobos leading people to write buggy or platform specific code.
>
> We just fixed this in dub.
> https://github.com/D-Programming-Language
On Wed, 04 Feb 2015 05:24:18 +, Orvid King wrote:
> Yes, but @attribute isn't defined when compiling with DMD, resulting in
> the need for some fun with version statements.
exactly one module, say, for example, `gcccompat.d`:
module gcccompat;
version(GNU) {
public import gcc.attribu
On Tue, 03 Feb 2015 17:33:53 +, Russel Winder via Digitalmars-d wrote:
> The issue is though that Dub was created because someone did something
> rather than just talking (and emailing) about it.
i have my build system with automatic dependency tracking and flexible
scripting for many years
On Tue, 03 Feb 2015 21:08:05 +, Paulo Pinto wrote:
>> sorry, i mean XML per se. it's unwriteable, unreadable and
>> unmaintainable. i just can't see the actual contents behind all that
>> tag noise.
>
> Completly usable in any XML aware IDE. :)
i.e. unusable. ;-) it's better to use binary fo
On Wednesday, 4 February 2015 at 01:04:42 UTC, Martin Nowak wrote:
On 02/03/2015 04:20 AM, Martin Nowak wrote:
On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir
Panteleev wrote:
I might revisit Dub again once some of the fixable issues
mentioned
here are fixed.
Another very important arg
On Tue, 03 Feb 2015 23:37:58 +, Justin Whear wrote:
> On Tue, 03 Feb 2015 23:34:15 +, an wrote:
>
>> Pragmas can be used as attribute that doesn't affect the semantics.
>> This syntax is not supported in this DIP?
>>
>> pragma(inline, true)
>> {
>> void foo() { }
>> void bar() { }
>> }
>
On 2/3/15 9:05 PM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:mar39k$hvh$1...@digitalmars.com...
I think the best route here - and the most in-the-spirit-of-D - is to
provide introspection on whether a function is being inlined or not.
Then we can always have in libraries
On Wednesday, 4 February 2015 at 05:17:11 UTC, ketmar wrote:
On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright
wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed th
"Manu via Digitalmars-d" wrote in message
news:mailman.5867.1423017226.9932.digitalmar...@puremagic.com...
In the inevitable case that I always seem to find myself in, where I'm
wrapping something in a thin shim that should behave IDENTICAL to the
thing I'm wrapping.
It's the source of the vas
On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote:
> On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP56
>>
>> There's been enough discussion, time to make a decision and move on.
>>
>> I changed the description to:
>>
>> "If a pragma specifies alway
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright
wrote:
The pragma will cause it to ignore the cost function and always
inline it.
So, if pragma(inline, true) ignores the cost function, will it
*always* inline it, or always apply the -inline compiler flag
rules (whatever they ar
On 2/3/2015 9:00 PM, Mike wrote:
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright wrote:
The pragma will cause it to ignore the cost function and always inline it.
So, if pragma(inline, true) ignores the cost function, will it *always* inline
it, or always apply the -inline compil
On Wednesday, 4 February 2015 at 05:03:03 UTC, Walter Bright
wrote:
So, if pragma(inline, true) ignores the cost function, will it
*always* inline
it, or always apply the -inline compiler flag rules (whatever
they are)?
If the former,
Yes.
Ok, then please ignore all my posts on this top
"Andrei Alexandrescu" wrote in message news:mar39k$hvh$1...@digitalmars.com...
I think the best route here - and the most in-the-spirit-of-D - is to
provide introspection on whether a function is being inlined or not. Then
we can always have in libraries:
bool uart(ubyte b)
{
static ass
On 2/3/2015 5:57 PM, ZombineDev wrote:
Will this proposal allow to override the inlining of a function at the call
site?
No. It marks the function, not the call site.
Though there would a simple way to do this - make a 'never inline' function that
wraps the 'always inline' one, and call the
On 2/3/2015 4:24 PM, Mike wrote:
...it should read...
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the command line
...as that is really the intent of DIP56 as confirmed by W
On Wednesday, 4 February 2015 at 04:11:39 UTC, Mike wrote:
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:
pragma(inline, true) will not compile if you enabled warnings
as errors.
I know, but this is the mediocrity I'm talking about: it only
works as one wishes/expects under cer
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:
pragma(inline, true) will not compile if you enabled warnings
as errors.
I know, but this is the mediocrity I'm talking about: it only
works as one wishes/expects under certain conditions.
Mike
On Wednesday, 4 February 2015 at 02:44:46 UTC, Mike wrote:
This is not what I want either. I find @always_inline and
@never_inline attributes with compile-time enforcement *far*
more useful.
pragma(inline, true) will not compile if you enabled warnings as
errors.
Excellent post. This situation is very obvious to us at
Sociomantic, as we're at the forefront of a massive disruption
that is happening in the advertising industry. D has far better
prospects in disruptive technology, rather than trying to
compete with incumbents in the rapidly disappearing tr
On Wednesday, 4 February 2015 at 02:52:07 UTC, Andrei
Alexandrescu wrote:
The question is, can you get work done with the currently
proposed semantics? If so, let's commit to this and move on.
Yes, I may be able to make use of it on occasion, but only
because other, more useful features ar
On 2/3/15 6:44 PM, Mike wrote:
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the command line
...as that is real
On Tuesday, 3 February 2015 at 15:38:06 UTC, Atila Neves wrote:
How would one go about starting to be a contributor?
Atila
I'll start by getting the thing to build, figure out something
that is not working and come to me so we can have a battle plan
(or directly make a PR if this is simple)
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the
command line
...as that is really the intent of DIP56 as conf
As you might have noticed already, this functionality is currently
missing in phobos leading people to write buggy or platform specific code.
We just fixed this in dub.
https://github.com/D-Programming-Language/dub/pull/497
Time to finally add this to phobos, what's missing is someone to
imple
On 3 February 2015 at 23:27, Daniel Murphy via Digitalmars-d
wrote:
> "Manu via Digitalmars-d" wrote in message
> news:mailman.5832.1422967168.9932.digitalmar...@puremagic.com...
>
>> I'd personally prefer an attribute, and I'll argue for it, but I'll
>> take whatever I can get. Pragma will likel
On Wed, Feb 04, 2015 at 02:30:23AM +0100, Martin Nowak via Digitalmars-d wrote:
> On 02/03/2015 10:02 PM, H. S. Teoh via Digitalmars-d wrote:
> >Rather than scan the whole source tree every time, it takes the
> >changeset as input -- either from the OS, or from some other source
> >of information.
Will this proposal allow to override the inlining of a function
at the call site?
On 02/03/2015 10:02 PM, H. S. Teoh via Digitalmars-d wrote:
Rather than scan the whole source tree every time, it
takes the changeset as input -- either from the OS, or from some other
source of information.
Indeed a good idea, although according to his graphs, this only starts
to matter for +
On 02/03/2015 04:20 AM, Martin Nowak wrote:
On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir Panteleev wrote:
I might revisit Dub again once some of the fixable issues mentioned
here are fixed.
Another very important argument is consistency in using packages.
I recently tried digger which
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Wednesday, 4 February 2015 at 00:24:25 UTC, Mike wrote:
I think this whole debate could have been avoided if the DIP
was worded differently.
Instead of...
pragma(inline, true); // always inline
pragma(inline, false); // never inline
pragma(inline);// revert to default behavior
...
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On 2/3/2015 2:47 PM, Orvid King wrote:
I just created a proposal for a more general syntax to allow user's to apply
attributes like inlining in a way that can easily be supported across compilers,
and, in my eyes, is clearer about what code the attribute is applied to than a
pragma is.
http://wi
On Tuesday, 3 February 2015 at 02:38:57 UTC, Zach the Mystic
wrote:
I'm arguing from the perspective that the approval must come
first, and the piloting second. Who would want to develop a
module in the "pre-pilot" phase, without having any idea of
whether they were developing it finally for ph
On Monday, 2 February 2015 at 17:29:05 UTC, Nick Sabalausky wrote:
The right-side panel is WAY too prominent. It takes nearly an
entire third of the horizontal space, leaving the main content
much to squished.
Yeah, I'd forgotten to update the max-widths.
https://github.com/D-Programming-Lang
On Tue, 03 Feb 2015 23:34:15 +, an wrote:
> Pragmas can be used as attribute that doesn't affect the semantics. This
> syntax is not supported in this DIP?
>
> pragma(inline, true)
> {
> void foo() { }
> void bar() { }
> }
I assume it's covered by "If this pragma is outside of a function, it
On Tuesday, 3 February 2015 at 23:25:26 UTC, Peter Alexander
wrote:
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:
We have an attribute system, why make this a pragma ?
Rationale is in the DIP: "These are not attributes because they
should not affect the semantics of the functi
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:
We have an attribute system, why make this a pragma ?
Rationale is in the DIP: "These are not attributes because they
should not affect the semantics of the function. In particular,
the function signature must not be affected."
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
There's been enough discussion, time to make a decision and
move on.
I'm glad this is being said more and more around these parts.
Some stuff just seems to be stagnating forever.
On Tuesday, 3 February 2015 at 22:27:38 UTC, Orvid King wrote:
On Tuesday, 3 February 2015 at 22:19:08 UTC, Tourist wrote:
Source code:
https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp
Origin:
http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot
On Tuesday, February 03, 2015 11:41:35 via Digitalmars-d wrote:
> On Tuesday, 3 February 2015 at 11:33:35 UTC, Mike wrote:
> > I don't like "hot/cold" as it does not convey the effect.
>
> Yeah, I believe LLVM has a register saving calling convention
> that is cold_cc, so "cold" would be more suite
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot inline it, a
warning will be generated. Implementations will likely vary in their ability to
inline."
On Tuesday, 3 February 2015 at 22:19:08 UTC, Tourist wrote:
Source code:
https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp
Origin:
http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot
The thing to realize about the .net GC is that it is precise,
On Tue, Feb 03, 2015 at 10:13:49PM +, Chris via Digitalmars-d wrote:
[...]
> Keeping the old clunky logo is like having a brand new Maserati with
> the hood of a Volkswagen Beetle :-) He!
Actually, the Volkswagen Beetle is my all-time favorite car shape. I
would totally dig a Beetle with a mod
Source code:
https://raw.githubusercontent.com/dotnet/coreclr/master/src/gc/gc.cpp
Origin:
http://www.reddit.com/r/programming/comments/2unrll/net_core_is_on_github/coa2uot
On Tuesday, 3 February 2015 at 16:29:21 UTC, Jonathan Marler
wrote:
On Monday, 2 February 2015 at 16:06:00 UTC, Atila Neves wrote:
XML? Please, no. Anything but XML.
FWIW, here's the same data written in ASON (the first language
example anyway)
https://github.com/marler8997/mored/wiki/ASON-
On Wednesday, 28 January 2015 at 15:54:31 UTC, anonymous wrote:
On Tuesday, 27 January 2015 at 20:02:12 UTC, anonymous wrote:
PR:
https://github.com/D-Programming-Language/dlang.org/pull/869 -
For details see here.
Live version: http://ag0aep6g-dlang.rhcloud.com - If you've
visited this before
On Tuesday, 3 February 2015 at 21:05:38 UTC, Atila Neves wrote:
I didn't forget it myself, but thanks for bringing it up. I'm
considering having a tup backend actually.
Tup is cool but unfortunately is still "too manual", for lack
of a better term. I'd much rather write "add_executable" and
not
On Tuesday, 3 February 2015 at 19:54:52 UTC, Szymon Gatner wrote:
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Please no. If anything, *any* new library for D should be bas
On Tuesday, 3 February 2015 at 03:20:49 UTC, Martin Nowak wrote:
On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir Panteleev
wrote:
With dub you do this instead.
dub fetch digger
dub run digger -- --help
This is the killer feature for me! As a user I don't really care
about how it is bui
On Monday, 2 February 2015 at 21:48:03 UTC, ketmar wrote:
On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote:
On 3/02/2015 5:35 a.m., ketmar wrote:
On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote:
...
i can't even read that linenoise.
There is three sets of files if I
On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi
wrote:
On Tuesday, 3 February 2015 at 17:34:05 UTC, Russel Winder
wrote:
The issue is though that Dub was created because someone did
something
rather than just talking (and emailing) about it. As Hans and
colleagues
took knowledge a
This is really good feedback, thanks. Would you be interested in
discussing this further privately? I've already got some ideas
brewing in my head.
Atila
On Tuesday, 3 February 2015 at 18:00:31 UTC, Russel Winder wrote:
On Mon, 2015-02-02 at 16:50 +, Atila Neves via
Digitalmars-d wrote:
On Tue, Feb 03, 2015 at 08:41:38PM +, Jonathan Marler via Digitalmars-d
wrote:
> On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi wrote:
> >[1] http://gittup.org/tup/
>
> I don't know who wrote that site but they are quite hilarious :)
>
> "Unfortunately, tup is so fast that you
On Tuesday, 3 February 2015 at 20:45:03 UTC, Dicebot wrote:
On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi
wrote:
Don't forget tup!!! [1]
[1] http://gittup.org/tup/
This is first time I hear about tup but I must admit it looks
really cool. It has all the good thing I love abou
On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi
wrote:
Don't forget tup!!! [1]
[1] http://gittup.org/tup/
This is first time I hear about tup but I must admit it looks
really cool. It has all the good thing I love about make but with
more thinking being put into it and no awkwa
On Tuesday, 3 February 2015 at 20:18:31 UTC, Paolo Invernizzi
wrote:
[1] http://gittup.org/tup/
I don't know who wrote that site but they are quite hilarious :)
"Unfortunately, tup is so fast that your chair mounted jousting
might suffer. I apologize in advance if someone besmirches your
hon
On Tuesday, 3 February 2015 at 17:34:05 UTC, Russel Winder wrote:
The issue is though that Dub was created because someone did
something
rather than just talking (and emailing) about it. As Hans and
colleagues
took knowledge and experience and created Gradle, somebody, or
group of
people, need
On Tue, 03 Feb 2015 20:46:55 +0100, Jacob Carlborg wrote:
> On 2015-02-01 19:58, Iain Buclaw via Digitalmars-d wrote:
>> Hi,
>>
>> Next list of things that need sorting out⢠in GDC is how the compiler
>> works out where module interfaces are installed vs. where the library
>> actually installed
On 2015-02-03 at 18:53, captaindet wrote:
i am a simple user writing mostly programs to crunch my scientific data. i'd
like to move my C code to D. but i deal with GBs of data that i have to sieve
through many times. in C, i have lots of repeating integer stunts in the inner
loop that must be
On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
> On 02/03/2015 09:51 AM, ketmar wrote:
>> 'cause it really sux as a build tool.
>
> Not getting into any of the lengthy discussions of yours, but 'it sux'
> isn't really helping anyone to improve it.
repeating the reasons why it sux doesn'
On Monday, 2 February 2015 at 04:00:31 UTC, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC - Java DataBase Connectors).
Please no. If anything, *any* new library for D should be based
on C++ version and then make it nicer with D features. Basing
On 2015-02-01 19:58, Iain Buclaw via Digitalmars-d wrote:
Hi,
Next list of things that need sorting out™ in GDC is how the compiler
works out where module interfaces are installed vs. where the library
actually installed them - this is tricky when taking into
consideration:
I don't know if thi
On 2015-02-03 17:42, FG wrote:
A misfeature? If the ORM only allowed SELECT *, it wouldn't be of much
use with records containing blobs or big amounts of other data. If the
object was retrieved only for read and to update a few fields, pulling
all columns would be very wasteful.
Martin Nowak s
On 02/02/2015 12:00 PM, Manu via Digitalmars-d wrote:
If my D project depends on a C lib, then what am I supposed to do to
make dub useful for me?
This is a simple problem to solve.
All package tools support a way to build "native" extensions, mostly by
scripting the builds.
You can already ad
On 02/03/2015 09:51 AM, ketmar wrote:
'cause it really sux as a build tool.
Not getting into any of the lengthy discussions of yours, but 'it sux'
isn't really helping anyone to improve it.
On 02/02/2015 10:44 AM, Andrej Mitrovic wrote:
What's worse, I have to wait 15-20 minutes for the latest tagged version
of a dependency to finally show up on code.dlang.org.
Filed as https://github.com/D-Programming-Language/dub-registry/issues/92.
Please comment if you have any other ideas to
On Tuesday, 3 February 2015 at 18:16:20 UTC, Andrei Alexandrescu
wrote:
I think the best route here - and the most in-the-spirit-of-D -
is to provide introspection on whether a function is being
inlined or not. Then we can always have in libraries:
bool uart(ubyte b)
{
static assert(__trai
On Tuesday, 3 February 2015 at 18:16:20 UTC, Andrei Alexandrescu
wrote:
static assert(__traits(inlined),
"Inlining of uart() must be supported.");
This is unworkable:
1. You want to be able to turn off inlining for debugging.
2. You would have to wait with evaluating static_assert u
On 2/3/15 9:29 AM, Dicebot wrote:
On Tuesday, 3 February 2015 at 08:31:24 UTC, Walter Bright wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
The user can modify the code to allow it to be inlined. There are a
huge number
of constructs that cause dmd's inliner to completely give up. If a
funct
On Tue, 2015-02-03 at 13:19 +, Tofu Ninja via Digitalmars-d wrote:
[…]
> Why not invest your time into improving dub and adding these
> features, we don't need another tool. Improving dub would have a
> much bigger impact than making another tool that is almost
> certainly never going to get
On Mon, 2015-02-02 at 20:05 +, Dragos Carp via Digitalmars-d wrote:
[…]
> Why not building on cmake? You have experience with it.
I would argue because the CMake build description language really,
really suck.
Yes, you can describe builds using it, but only once you have entered a
state of S
On Mon, 2015-02-02 at 16:50 +, Atila Neves via Digitalmars-d wrote:
[…]
>
> I have ideas that go beyond this, but this is useful input. I
> wonder how to proceed now about gathering actual requirements
> from D devs and seeing which ones are important.
Learn lessons from SBT vs. SCons/Gant/
On 2015-02-03 05:05, Daniel Murphy wrote:
"Walter Bright" wrote in message news:maq8ao$2idu$1...@digitalmars.com...
Yup. I understand the concern that a compiler would opt out of
inlining those if it legally could, but I just cannot see that
happening in reality. Modern compilers have been inli
On Tue, 2015-02-03 at 08:51 +, ketmar via Digitalmars-d wrote:
> On Tue, 03 Feb 2015 02:19:55 +, Martin Nowak wrote:
>
> > There seems to be a general scepticism against dub and I wonder what the
> > reasons are.
>
> 'cause it really sux as a build tool.
I am reminded of some history tha
On Tuesday, 3 February 2015 at 08:31:24 UTC, Walter Bright wrote:
On 2/2/2015 8:36 PM, Daniel Murphy wrote:
The user can modify the code to allow it to be inlined. There
are a huge number
of constructs that cause dmd's inliner to completely give up.
If a function
_must_ be inlined, the compil
On Tuesday, 3 February 2015 at 11:51:31 UTC, Joseph Rushton
Wakeling wrote:
On Monday, 2 February 2015 at 17:44:53 UTC, Dicebot wrote:
In Arch Linux it is prohibited to package source-only libraries
How do they handle boost?
Boost does provide prebuild static libraries, despite being
templat
Ok than it is ok :)
- Původní zpráva -
Od:"Vadim Lopatin via Digitalmars-d"
Odesláno:3. 2. 2015 18:00
Komu:"digitalmars-d@puremagic.com"
Předmět:Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 15:30:42 UTC, Daniel Kozák wrote:
> V Tue, 03 Feb 2015 15:20:40 +0
For blobs or other unneeded data you can setup column as lazy fetch. What I
mean is situation when you have object in inconsistent state.
- Původní zpráva -
Od:"FG via Digitalmars-d"
Odesláno:3. 2. 2015 17:45
Komu:"digitalmars-d@puremagic.com"
Předmět:Re: H1 2015 - db access support
On Tuesday, 3 February 2015 at 15:30:42 UTC, Daniel Kozák wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d
napsáno:
On Tuesday, 3 February 2015 at 14:41:02 UTC, Vadim Lopatin
wrote:
> On Tuesday, 3 February 2015 at 10:49:07 UTC, Robert burner
>> IMO writing:
>>
>> fo
On Tuesday, 3 February 2015 at 15:17:21 UTC, Atila Neves wrote:
It's easier to get started without getting tied down by an
existing codebase, for one. But you've got me thinking: if I do
anything I should do it as a library first and foremost to make
its possible future inclusion into dub a lot
On 2015-02-03 at 16:30, Daniel Kozák via Digitalmars-d wrote:
V Tue, 03 Feb 2015 15:20:40 +
Vadim Lopatin via Digitalmars-d napsáno:
Update in v0.2.19: you can specify field list for select
writeln("reading all user table rows, but fetching only id
and name (you will see default valu
On Tuesday, 3 February 2015 at 14:03:22 UTC, Kagamin wrote:
The database client library or the database itself in case of
sqlite, i.e. code you link with. Dependency also means you
should get it somewhere, possibly compiling with dmc.
If only interfaces included into Phobos, it's not a problem
On Monday, 2 February 2015 at 16:06:00 UTC, Atila Neves wrote:
XML? Please, no. Anything but XML.
FWIW, here's the same data written in ASON (the first language
example anyway)
https://github.com/marler8997/mored/wiki/ASON-(Application-Specific-Object-Notation)
Language {
Name D
nice!
get it into phobos or vibe
In my experience such optimizations are usually needed only for
reading, so the query may return a plain tuple instead of true
mapped object. Well, this can depend on whether you have an ORM
container.
Am Tue, 03 Feb 2015 07:09:10 -0800
schrieb Andrei Alexandrescu :
> On 2/3/15 12:17 AM, Johannes Pfau wrote:
> > Well I see that you're not even considering adding a simple pragma
> > to help embedded programming. In that case I see absolutely no
> > reason to continue working on that. You guys say
1 - 100 of 167 matches
Mail list logo
