On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu
wrote:
On 10/5/14, 7:55 AM, Dicebot wrote:
1) lack of vision
The vision is to expand user base and make a compelling case
for using D alongside existing code bases. There are two
important aspects to that: interoperability with
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
No need to explain it here. When I speak about vision I mean
something that anyone coming to dlang.org page or GitHub repo
sees. Something that is explained in a bit more details,
possibly with code examples. I know I am asking much but
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
Right now I have no idea where the development is headed and
what to expect from next few releases. I am not speaking about
wiki.dlang.org/Agenda but about bigger picture. Unexpected
focus on C++ support, thread about killing
On Sunday, 5 October 2014 at 22:11:38 UTC, eles wrote:
On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
No need to explain it here. When I speak about vision I mean
something that anyone coming to dlang.org page or
On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
No need to explain it here. When I speak about vision I mean
something that anyone coming to dlang.org page or GitHub repo
sees. Something that is explained in a bit
On 10/5/14, 3:08 PM, eles wrote:
On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
Right now I have no idea where the development is headed and what to
expect from next few releases. I am not speaking about
wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on
C++
Am Thu, 25 Sep 2014 21:19:29 +
schrieb Marc Schütz schue...@gmx.net:
I think it should just refuse to work on char[], wchar[] and
dchar[]. Instead, byCodeUnit, byCodePoint (which already exist)
would be required. This way, users would need to make a conscious
decision, and there would
On 2014-09-25 23:23:06 +, H. S. Teoh via Digitalmars-d said:
On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 9/25/14, 2:03 PM, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
lack of attention paid to tightening up
much like C++ although he does not really go
into it much and it was a very small part of the video it still brings
up some questions.
What I am curious is what are the worst parts of D? What sort of
things would be done differently if we could start over or if we were
designing a D3? I am
Dne 2.10.2014 v 19:02 ketmar via Digitalmars-d napsal(a):
On Thu, 02 Oct 2014 16:45:21 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
That's pretty cool, so you basically use the reflection
capabilities of D to generate your own custom CLI to the
application?
yes. some naming
On Thursday, 2 October 2014 at 17:02:35 UTC, ketmar via
Digitalmars-d wrote:
yes. some naming conventions and one mixin -- and all
interesting
variables and functions from the given module are automatically
registered in command console. so i can inspect and change
variables
and fields, call
On Fri, 03 Oct 2014 10:00:07 +0200
Martin Drašar via Digitalmars-d digitalmars-d@puremagic.com wrote:
That is mighty interesting. Would you be willing to share some code?
alas, only very old and rudimentary module is available. basically,
it's the core of the full-featured console, but... only
On Fri, 03 Oct 2014 08:30:10 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Please share when you are ready, I am gonna leach off yer code…
;-)
sure, i'm planning to open it as PD/WTFPL as soon as i'll settle some
issues. there is nothing really spectacular here, i must say, just
On 25/09/2014 07:22, H. S. Teoh via Digitalmars-d wrote:
Nevertheless, I think there is still room for debuggers to improve.
Recently, for example, I learned that gdb has acquired the ability to
step through a program backwards. Just missed the point in your program
where the problem first
On 25/09/2014 04:55, Walter Bright wrote:
I've also found that the more high level abstractions are used, the less
useful a symbolic debugger is. Symbolic debuggers are only good for
pedestrian, low level code that ironically is also what other methods
are very good at, too.
Err... are you
On Thu, 02 Oct 2014 13:18:43 +0100
Bruno Medeiros via Digitalmars-d digitalmars-d@puremagic.com wrote:
Err... are you talking in the context of D, or programming in general?
i'm not using interactive debuggers for 10+ years. the only use of GDB
for me is doing post-mortem inspection. i found
On Thursday, 2 October 2014 at 12:59:37 UTC, ketmar via
Digitalmars-d wrote:
i'm not using interactive debuggers for 10+ years. the only use
of GDB
for me is doing post-mortem inspection. i found that logging and
integrated control console lets me debug my code faster than any
interactive debug
On Thu, 02 Oct 2014 15:11:37 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
CLI based debugging in gdb is painful.
i used alot of frontends too. martian ddd, then kde's frontend, then
tried cgdb. and some other i can't even remember. it's not about bad
interface. ;-)
but a debugger
On Thursday, 2 October 2014 at 15:29:17 UTC, ketmar via
Digitalmars-d wrote:
sure, i'm not a guru and just talking about personal expirience
here. i
found myself much more productive after throwing interacteve
debuggers
out of the window. ;-)
Debugging preferences are very personal, I would
But I agree that debuggers can be annoying, reconfiguring them
is often more troublesome than just adding some printf() hacks.
I find them indispensable when I am really stuck though: duh,
I have spent 15 minutes on this, time to fire up the debugger.
Hehhe reconfigure a debugger. Lolz.
On Thu, 02 Oct 2014 16:13:31 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
In environments like javascript/python I often can find the
problem just as fast by just using the interactive console if the
code is written in a functional style.
actually, i'm cheating here, 'cause
On Thu, 02 Oct 2014 16:22:38 +
po via Digitalmars-d digitalmars-d@puremagic.com wrote:
Hehhe reconfigure a debugger. Lolz. Poor linux people. Living it
up like its still 1980.
did you updated your antivirus today?
signature.asc
Description: PGP signature
On Thursday, 2 October 2014 at 16:22:39 UTC, po wrote:
Hehhe reconfigure a debugger. Lolz. Poor linux people. Living
it up like its still 1980.
:-) Well, gdb is not my favourite, but it works well on C code.
I think this holds for all kinds of debuggers (including VS and
XCode)… In all
On Thursday, 2 October 2014 at 16:26:15 UTC, ketmar via
Digitalmars-d wrote:
and i must say that integrating such
console in C projects was tiresome. with D i can do it almost
automatically, skipping annoying variable registration and
wrappers for functions.
the first thing i wrote in D was
On Thu, 02 Oct 2014 16:45:21 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
That's pretty cool, so you basically use the reflection
capabilities of D to generate your own custom CLI to the
application?
yes. some naming conventions and one mixin -- and all interesting
variables
On 23/09/2014 20:05, Andrei Alexandrescu wrote:
On 9/23/14, 12:01 PM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 18:38:08 UTC, Andrei Alexandrescu wrote:
Well put. Again, the two things we need to work on are C++
compatibility and the GC. -- Andrei
Has much thought gone into how
On 25/09/14 13:08, Don wrote:
C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
complex types. float.min. @property.
Let me add: base class protection. It's deprecated but not completely
removed. I have never seen base class protection being used in practice.
--
On Thursday, 25 September 2014 at 17:45:56 UTC, Andrei
Alexandrescu wrote:
On 9/25/14, 10:26 AM, Atila Neves wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg
wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file
for
On 9/25/2014 9:38 PM, Daniel Murphy wrote:
Walter Bright wrote in message news:m02qcm$2mmn$1...@digitalmars.com...
What would the 3rd version of setExtension be named, then?
setExtension. Making up new clever names for functions that do the same thing
with different types is a burden for
Am Wed, 24 Sep 2014 23:56:24 +
schrieb Cliff cliff.s.hud...@gmail.com:
On Wednesday, 24 September 2014 at 23:20:00 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 11:02:51PM +, Cliff via
Digitalmars-d wrote:
On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S.
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote in
message news:mailman.1690.1411686833.5783.digitalmar...@puremagic.com...
On Thu, Sep 25, 2014 at 10:56:55PM +, Sean Kelly via Digitalmars-d
wrote:
..
Nah, they should be behead() and amputate().
Then the language would
On 9/25/2014 9:26 PM, Daniel Murphy wrote:
Oh yeah. D's one variable-sized type.
Pointers too!
On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei
Alexandrescu wrote:
On 9/25/14, 4:30 AM, Joakim wrote:
I'm sorry but it's ridiculous for you two co-BDFLs not to put
these new priorities or pre-approved features (perhaps even a
list of features you'd automatically reject) in a list on the
On Thursday, 25 September 2014 at 17:44:49 UTC, Jacob Carlborg
wrote:
LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of
these platforms [1].
It mentioned only 32-bit ELF on the About page. Since that
matches with what was previously the case in terms of debugging
support, I
On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via
Digitalmars-d wrote:
So basically, we're paying (1) lower performance, (2)
non-random access
for strings, (3) subtle distinction between index and count and
other
such gotchas, and (4) tons of special-cased Phobos code with the
Sean Kelly:
When I use algorithms on strings in D, I always cast them to
ubyte[]. Which is a poor solution.
In Phobos we have representation, and assumeUTF that are
better than naked casts. I use them only sparingly (and I avoid
cast), despite I use strings often.
Bye,
bearophile
On Fri, Sep 26, 2014 at 10:22:49AM +, Joakim via Digitalmars-d wrote:
On Thursday, 25 September 2014 at 13:56:20 UTC, Andrei Alexandrescu wrote:
On 9/25/14, 4:30 AM, Joakim wrote:
I'm sorry but it's ridiculous for you two co-BDFLs not to put
these new priorities or pre-approved features
On 2014-09-26 08:51, Atila Neves wrote:
Because I don't use unittest blocks, I use my own library. The one thing
it can't use the compiler for is discover what files are in a directory,
so I need to generate the main function that calls into unit-threaded
with a list of compile-time strings.
On 2014-09-26 14:14, Wyatt wrote:
It mentioned only 32-bit ELF on the About page.
I don't know which About page you're reading. The one I'm reading [1]
doesn't mention ELF at all.
[1] http://lldb.llvm.org/index.html
--
/Jacob Carlborg
On Friday, 26 September 2014 at 07:56:57 UTC, Marco Leise wrote:
Am Wed, 24 Sep 2014 23:56:24 +
You do know that your email is in plain text in the news
message header? :p
Actually I did not, as I am not presently using a newsreader to
access the forums, just the web page. I keep
On 9/26/2014 6:55 AM, Sean Kelly wrote:
On Friday, 26 September 2014 at 04:37:06 UTC, H. S. Teoh via Digitalmars-d
wrote:
So basically, we're paying (1) lower performance, (2) non-random access
for strings, (3) subtle distinction between index and count and other
such gotchas, and (4) tons of
Reading this thread makes me a little sad, because all of the
wish list stuff seems to be about features that VS already has,
and the I use every day :(
For example, the idea of stepping through lines of code (i.e.
individual
statements) is a convenient simplification, but really, in
On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
If you like building real airplanes out of Lego pieces, be my guest.
Me, I prefer using more suitable tools. :-P
I spend very little time fussing with
On 9/24/2014 11:05 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:23:48PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/24/2014 10:08 PM, H. S. Teoh via Digitalmars-d wrote:
If you like building real airplanes out of Lego pieces, be my guest.
Me, I prefer using more
On Wed, Sep 24, 2014 at 10:30:49PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a
pretty printer for, and use that. No conceivable debugger can
On Wed, 24 Sep 2014 21:15:59 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
needs to write should in theory be simply:
Program(mySuperApp, src/main.d);
and everything else will be automatically figured out.
ah, that's exactly why i migrated to jam! i got bored
On Wed, 24 Sep 2014 21:44:26 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
Make is the C++ of build systems. It may be ugly, but you can get it
to work.
'make' reminds me assembler language: it's possible to do alot of cool
things with 'make', but it's compilcated and
On Wed, Sep 24, 2014 at 11:14:30PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
You noted my preference for simple makefiles (even if they tend to get
verbose). I've been using make for 30 years now, and rarely have
problems with it. Of course, I also eschew using every last feature of
On Wed, 24 Sep 2014 23:14:30 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
And I use make -j on posix for parallel builds, it works fine on dmd.
me too. paired with `git clean -dxf` to get clean of the cleanest
possible fileset. it's good that dmd build times are so
On Wed, 24 Sep 2014 23:22:56 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
gdb does allow calling your program's functions out-of-band in
'print'.
it's handy. what else handy is quake-like embedded console. i'm using
that in my c software alot (i can connect to some port
On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:
Well, Cliff I (and whoever's interested) will see what we can do about
that. Perhaps in the not-so-distant future we may have a D build tool
that can serve as the go-to build tool for D projects.
What problems do you see with Dub?
--
On Thu, 25 Sep 2014 09:04:43 +0200
Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote:
What problems do you see with Dub?
i, for myself, see a great problem with Dub: it's not a universal build
tool. some of my internal D projects, for example, builds C libraries
from source (and
[...]
If you have a passion and interest in this space and would
like to
collaborate, I would be thrilled. We can also split this
discussion
off of this thread since it is not D specific.
I'm interested. What about Atila?
Definitely interested. BTW, I agree with everything you said
On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Sep 24, 2014 at 10:18:29PM +, Atila Neves via
Digitalmars-d wrote:
[...]
Now throw in things like built-in parallelization ala SCons
(I'm not
sure if tup does that too, I suspect it does),
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
Anything in the spec that depends on you having an x86 CPU, or
being tied to a specific platform.
1) D Inline Assembler.
- First because suddenly to have a conformant compiler you
On Thursday, 25 September 2014 at 07:34:11 UTC, Iain Buclaw wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja
wrote:
What do you think are the worst parts of D?
Anything in the spec that depends on you having an x86 CPU, or
being tied to a specific platform.
Special
On Thursday, 25 September 2014 at 07:04:43 UTC, Jacob Carlborg
wrote:
On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:
Well, Cliff I (and whoever's interested) will see what we
can do about
that. Perhaps in the not-so-distant future we may have a D
build tool
that can serve as the
Am Wed, 24 Sep 2014 22:30:49 -0700
schrieb Walter Bright newshou...@digitalmars.com:
There's more than that, but yeah. Most of my types I'll write a
pretty printer for, and use that. No conceivable debugger can guess
how I want to view my data.
You can call functions with GDB, but I guess you
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
No prob. The initiating post was an invitation to a wine
festival, and that's what we have :-)
:D
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright
wrote:
On 9/24/2014 7:56 AM, Don wrote:
For example: We agreed *years* ago to remove the NCEG
operators. Why haven't
they been removed yet?
They do generate a warning if compiled with -w.
They should be gone completely. So
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
I make similar statements all the time. It doesn't result in
action on anyone's part. I don't tell people what to do - they
work on aspects of D that interest them.
Even people who ask me what to work on never follow my
On Thursday, 25 September 2014 at 07:28:10 UTC, Atila Neves wrote:
[...]
If you have a passion and interest in this space and would
like to
collaborate, I would be thrilled. We can also split this
discussion
off of this thread since it is not D specific.
I'm interested. What about Atila?
On Thursday, 25 September 2014 at 11:30:52 UTC, Joakim wrote:
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
I make similar statements all the time. It doesn't result in
action on anyone's part. I don't tell people what to do - they
work on aspects of D that interest
On 25/09/14 07:30, Walter Bright wrote:
There's more than that, but yeah. Most of my types I'll write a pretty
printer for, and use that. No conceivable debugger can guess how I want
to view my data.
With LLDB you can implement your own custom formatters [1]. For example,
in Xcode, Apple
Am Thu, 25 Sep 2014 11:08:23 +
schrieb Don x...@nospam.com:
They should be gone completely. So should built-in sort.
I think there's something important that you haven't grasped yet.
It was something I didn't really appreciate before working here.
** Keeping deprecated features alive
On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
In fact, one thing that impressed me immensely is the fact that building
the dmd toolchain is as simple as it is. I know of no other compiler
project that is comparable. Building gcc, for example, is a wondrous
thing to behold -- when it
On 9/25/14, 4:08 AM, Don wrote:
C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
complex types. float.min. @property.
That's a good list I agree with. FWIW I'm glad no random name changes.
I've recently used Rust a bit and the curse of D users as of 6-7 years
ago
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file for
unittest builds. There's no current way (or at least there wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D file from
a dub package and list it as a dependency of
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file for
unittest builds. There's no current way (or at least there wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D file from
a dub package and list it as a dependency of
On 9/25/14, 4:30 AM, Joakim wrote:
I'm sorry but it's ridiculous for you two co-BDFLs not to put
these new priorities or pre-approved features (perhaps even a
list of features you'd automatically reject) in a list on the
wiki and maintain it yourselves. It's the least you can do
considering the
On Thursday, 25 September 2014 at 13:31:24 UTC, Jacob Carlborg
wrote:
Perhaps it's time to look at some modern alternatives and not
be stuck with GDB ;)
I might look at the modern alternative once it supports
debugging 64-bit executables. :/
-Wyatt
On 9/25/14, 5:41 AM, Wyatt wrote:
On Thursday, 25 September 2014 at 11:30:52 UTC, Joakim wrote:
On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
I make similar statements all the time. It doesn't result in action
on anyone's part. I don't tell people what to do - they work
On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
[...]
But even then, I *did* run into the problem of non-reproducible
builds with dmd. So there's still a blemish there. :-P Makes me want
to alias `make`
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg
wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file
for
unittest builds. There's no current way (or at least there
wasn't when I
brought it up in the dub forum) to tell it to
Am 25.09.2014 07:30, schrieb Walter Bright:
On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
printf debugging FTW! :-P
There's more than that, but yeah. Most of my types I'll write a pretty
printer for, and use that. No conceivable debugger can guess how I want
to view my data.
For
25-Sep-2014 01:12, Andrei Alexandrescu пишет:
On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
That's unfortunate indeed. I wish I could inspire them as to how cool a
properly-done build system can be.
[snip]
That's all nice. However: (1) the truth is there's no clear modern build
On Thursday, 25 September 2014 at 13:51:17 UTC, Jacob Carlborg
wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file
for
unittest builds. There's no current way (or at least there
wasn't when I
brought it up in the dub forum) to tell it to
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg
wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file
for
unittest builds. There's no current way (or at least there
wasn't when I
brought it up in the dub forum) to tell it to
On Thursday, 25 September 2014 at 14:25:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via
Digitalmars-d wrote:
On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
[...]
But even then, I *did* run into the problem of
non-reproducible
On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've
updated the compiler?
--
/Jacob Carlborg
On 2014-09-25 16:01, Wyatt wrote:
I might look at the modern alternative once it supports debugging
64-bit executables. :/
LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of these
platforms [1]. Are you looking for Windows support?
[1] http://lldb.llvm.org/
--
/Jacob Carlborg
On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
wrote:
On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know
I've updated the compiler?
The compiler is an input to
On 9/25/14, 10:26 AM, Atila Neves wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file for
unittest builds. There's no current way (or at least there wasn't when I
On 9/25/14, 10:47 AM, Cliff wrote:
On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
wrote:
On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've
updated the
On Thu, Sep 25, 2014 at 09:18:26PM +0400, Dmitry Olshansky via Digitalmars-d
wrote:
[...]
I had an insanely complicated one could handle 2 platforms, 3
emulators and a few custom build steps (including signing binaries),
cleaning, tracking dependencies with minimal rebuilds. For instance,
On Thu, Sep 25, 2014 at 07:42:08PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
That's the hallmark of make-based projects.
This was Ninja actually. But how would the build system know I've
updated the compiler?
[...]
The
On 9/24/14, 3:20 AM, Jacob Carlborg wrote:
On 24/09/14 07:37, Walter Bright wrote:
So help out!
You always say we should help out instead of complaining. But where are
all the users that want C++ support. Let them implement it instead and
lets us focus on actual D users we have now.
Maybe
On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
You don't know if
recompiling after checking out a previous release of your code
will
actually give you the same binaries that you shipped 2 months
ago.
To be clear, even if nothing changed, re-running the
On 9/25/2014 6:49 AM, Andrei Alexandrescu wrote:
FWIW I'm glad no random name changes. I've
recently used Rust a bit and the curse of D users as of 6-7 years ago reached
me: most code I download online doesn't compile for obscure reasons, it's nigh
impossible to figure out what the fix is from
On Thu, Sep 25, 2014 at 07:19:14PM +, Cliff via Digitalmars-d wrote:
On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
You don't know if recompiling after checking out a previous release
of your code will actually give you the same binaries that you
On 9/25/2014 4:08 AM, Don wrote:
[...]
I agree with Andrei, it's a good list. I'll move these issues to the next step
in the removal process.
I'd also like to see us getting rid of those warts like assert(float.nan) being
true.
See discussion:
On 9/25/2014 10:45 AM, Andrei Alexandrescu wrote:
On 9/25/14, 10:26 AM, Atila Neves wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
On 25/09/14 09:38, Atila Neves wrote:
Here's one: having to manually generate the custom main file for
unittest builds. There's no
On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/25/2014 4:08 AM, Don wrote:
[...]
Ask yourself, if D had no users other than you, so that you break
*anything*, what would you remove? Make a wishlist, and then find out
what's possible. Remember, when you
On Thu, Sep 25, 2014 at 12:51:45PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
I've found:
-main -unittest -cov
to be terribly convenient when developing modules. Should have added
-main much sooner.
Yeah, I do that all the time nowadays when locally testing Phobos fixes.
In
On 2014-09-25 21:02, Ary Borenszweig wrote:
Maybe Facebook needs D to interface with C++?
But I only see Andrei working on that. Don't know how much coding he
does in practice for C++ compatibility.
--
/Jacob Carlborg
On 2014-09-25 19:26, Atila Neves wrote:
I don't want an empty main function. I want the main function and the
file it's in to be generated by the build system.
What do you want the main function to contain?
--
/Jacob Carlborg
On 2014-09-25 20:49, H. S. Teoh via Digitalmars-d wrote:
The compiler and compile flags are inputs to the build rules in SCons.
In my SCons projects, when I change compile flags (possibly for a subset
of source files), it correctly figures out which subset (or the entire
set) of files needs to
On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg
wrote:
On 25/09/14 09:38, Atila Neves wrote:
Andrei spoke about an idiom that they constantly use at
Facebok, because there aparrently nobody runs *main and
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
lack of attention paid to tightening up what we've already got
and deprecating old stuff that no one wants any more. And
inconsistency in how things work in the language.
The feeling that I have is that if D2 does not get a
On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
On 9/25/2014 4:08 AM, Don wrote:
[...]
Ask yourself, if D had no users other than you, so that you break
*anything*, what would you remove? Make a
101 - 200 of 434 matches
Mail list logo
