On Sat, 21 Jun 2014 20:48:40 +
Brian Schott via Digitalmars-d wrote:
> On Saturday, 21 June 2014 at 19:41:42 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > And to add to that, this proposal doesn't even make things
> > consistent. You
> > _still_ have t
On Sun, 22 Jun 2014 05:49:33 +
Mason McGill via Digitalmars-d wrote:
> I was referring to the `Property` and `PropertyIdentifier`
> entities in the D grammar (http://dlang.org/attribute.html),
> which are special cases of attributes. "New-style" attributes,
> like "property", "safe", and "nog
On Fri, 20 Jun 2014 19:22:02 +
Brian Schott via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too
> verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to add
On Sat, 21 Jun 2014 22:07:22 -0700
Jonathan M Davis via Digitalmars-d wrote:
> On Sat, 21 Jun 2014 20:48:40 +
> Brian Schott via Digitalmars-d wrote:
>
> > Why is D being consistent with other languages a more important
> > goal than D being consistent with D?
>
>
On Sat, 21 Jun 2014 15:39:03 -0700
Andrei Alexandrescu via Digitalmars-d
wrote:
> On 6/19/14, 3:27 PM, Andrej Mitrovic via Digitalmars-d wrote:
> > I claimed a bounty recently, and I just wanted to say thanks to
> > Andrei and his company for backing the bounty.
> >
> > I won't be able to take an
On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote:
> http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca
> n-open-security-holes-in-your-code
>
> This is an opportunity for D to define the spec in such away as to preclude
> the bad optimizations while
> Sent: Monday, June 23, 2014 at 10:26 AM
> From: "Andrei Alexandrescu via Digitalmars-d"
> To: digitalmars-d@puremagic.com
> Subject: Re: Optimizing Java using D
>
> Corollary: the default sorting algorithm in std will always be unstable,
> even if for certain data types and inputs it will produ
On Monday, June 23, 2014 17:30:18 John via Digitalmars-d wrote:
> The @ symbols used on all those attributes like @nogc @nothrow
> @pure @safe make the D code look ugly.
>
> If possible, please get rid of those @ symbols. The attributes
> look good without the "@" symbols.
It would be very cool if
> Sent: Tuesday, June 24, 2014 at 12:39 PM
> From: "H. S. Teoh via Digitalmars-d"
> To: digitalmars-d@puremagic.com
> Subject: Re: std.file read with start position
>
> P.S. the problem with the table of contents links pointing to the wrong
> place is a known bug:
>
> https://issues.dlang
> Sent: Thursday, June 26, 2014 at 10:52 AM
> From: "Nick Sabalausky via Digitalmars-d"
> To: digitalmars-d@puremagic.com
> Subject: Re: Bounty Increase on Issue #1325927
>
> On 6/26/2014 7:02 AM, Shammah Chancellor wrote:
> > I've increased the bounty on this bug. Fast CTFE is very important.
On Thursday, June 26, 2014 17:45:23 Meta via Digitalmars-d wrote:
> On Thursday, 26 June 2014 at 17:26:02 UTC, bearophile wrote:
> > Meta:
> >> There has been discussion before about doing away with string
> >> lambdas. Maybe this is a good time to do that.
> >
> > If they get deprecated I will hav
On Monday, June 30, 2014 22:22:50 francesco cattoglio via Digitalmars-d wrote:
> I found out today that the following code won't compile:
>
> import std.conv;
>
> class MyClass {}
>
> void doStuffKo(const MyClass instance)
> {
> string temp = to!(string)(instance);
> }
>
> Everything compiles fin
On Wed, 02 Jul 2014 07:07:17 +
Wanderer via Digitalmars-d wrote:
> On Tuesday, 1 July 2014 at 01:13:25 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > The long term plan is to remove toString, opEquals, toHash, and
> > opCmp from
> > Object so that the derived cl
On Wed, 02 Jul 2014 11:33:54 +
Wanderer via Digitalmars-d wrote:
> "~" operator has to do with toString(), because it performs
> string concatenation (at least documentation says so) and
> toString() is the common way to convert arbitrary object into a
> string.
The common way to convert any
On Wed, 02 Jul 2014 23:56:21 -0700
Walter Bright via Digitalmars-d wrote:
> On 7/2/2014 8:48 PM, Sean Kelly wrote:
> > I'm still unclear whether we're aiming for C interoperability or
> > hardware support though, based on Walter's remark about SPARC and
> > PPC. There, 'long double' is represent
On Thu, 03 Jul 2014 12:45:17 -0700
Walter Bright via Digitalmars-d wrote:
> On 7/3/2014 3:49 AM, Jonathan M Davis via Digitalmars-d wrote:
> > I don't think that there's anything unclear about that. The problem
> > is that if real is supposed to be the largest hardwa
On Thu, 3 Jul 2014 14:01:23 -0700
Jonathan M Davis via Digitalmars-d wrote:
> I'm fine with real varying from platform to platform depending on
> what makes sense for that platform, but I think that it should be
> clear what real is generally supposed to be (e.g. the largest
&g
On Sun, 06 Jul 2014 15:03:35 -0700
Adam Wilson via Digitalmars-d wrote:
> On Sun, 06 Jul 2014 14:57:34 -0700, Adam Wilson
> wrote:
>
> And now I look like a complete idiot for hitting the wrong button!
> *embarrassed*
At least you accidentally shared _good_ news. :)
At while it was personal, i
> Sent: Wednesday, July 09, 2014 at 7:51 PM
> From: "logicchains via Digitalmars-d"
> To: digitalmars-d@puremagic.com
> Subject: Thread-local GC?
>
> I was wondering if thread-local GC had been considered an option
> for making D's GC work better in threaded code? Erlang has this
> (well, process-
On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
> On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
> > You're right. I forgot about those two. But it's still the case that the
> > number of function attributes that don't h
On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
> > On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
> >> But in this case I see no improvement that could justify it.
> >
> > Fixes problems people
On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d
wrote:
>
> Change has been reverted. -- Andrei
Yay!
- Jonathan M Davis
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
> wrote:
> > consistent. They're
> > always going to be inconsistent in one way or another, even if
> > it's simply
> > because they don't match what anyone coming from
On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
> wrote:
> > inconsistencies and annoying points in the language. And much
> > of the time,
> > those inconsistencies and annoying points are forced by other
> > aspect
On Thursday, January 29, 2015 13:47:47 Walter Bright via Digitalmars-d wrote:
> Even so, lots of languages survive execrable features if they are
> counterbalanced by more desirable one.
C!
- Jonathan M Davis
On Monday, February 02, 2015 22:37:13 Joseph Rushton Wakeling via Digitalmars-d
wrote:
> On 02/02/15 15:40, Dicebot via Digitalmars-d wrote:
> > Quick summary of my opinion can look like this:
> >
> > 1) dub is a horrible build tool
> > 2) git submodules is a horrible way for dependency management
On Monday, February 02, 2015 13:01:28 Walter Bright via Digitalmars-d wrote:
> On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote:
> > I'm pretty sure the only controversy is that you want it to be a
> > pragma, everyone else wants it to be an attribute.
>
> That's correct.
>
> My reasoning is simpl
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
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 Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:
> Looks like a relatively new function, so I guess, snn simply
> doesn't implement it.
No. If I grep dmc's folder, snn.lib contains _wsopen. It doesn't contain
_wsopen_s, which is what MS wants folks to use, but it does have
On Wednesday, February 04, 2015 00:13:21 Jonathan M Davis via Digitalmars-d
wrote:
> On Wednesday, February 04, 2015 07:34:14 Kagamin via Digitalmars-d wrote:
> > Looks like a relatively new function, so I guess, snn simply
> > doesn't implement it.
>
> No. If I
On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d wrote:
> You got it declared with stdcall convention, should change to
> cdecl.
Well, I have it as extern(Windows) like everything else in
core.sys.windows.windows - it has extern(Windows): at the top. Should that
be something else
On Wednesday, February 04, 2015 00:29:58 Jonathan M Davis via Digitalmars-d
wrote:
> And the second problem is that
> dmc has that block of function declarations surrounded by
>
> #ifdef __NT__
> #ifndef __STDC__
> // declarations
> #endif
> #endif
>
> an
On Wednesday, February 04, 2015 09:02:01 ketmar via Digitalmars-d wrote:
> On Wed, 04 Feb 2015 00:33:48 -0800, Jonathan M Davis via Digitalmars-d
> wrote:
>
> > On Wednesday, February 04, 2015 08:18:46 Kagamin via Digitalmars-d
> > wrote:
> >> You got it declared w
On Wednesday, February 04, 2015 09:07:12 ketmar via Digitalmars-d wrote:
> D is in the same position now. "that ship is sailed", "we don't break the
> code", "happy legacy, folks!"
Not quite. The C++ folks basically won't break backwards compatibility for
anything. There are a few rare cases in th
On Wednesday, February 04, 2015 19:51:38 Daniel Murphy via Digitalmars-d wrote:
> "Jonathan M Davis via Digitalmars-d" wrote in message
> news:mailman.5879.1423038837.9932.digitalmar...@puremagic.com...
>
> > Well, I have it as extern(Windows) like everything else in
>
On Wednesday, February 04, 2015 09:33:22 ketmar via Digitalmars-d wrote:
> On Wed, 04 Feb 2015 01:13:18 -0800, Jonathan M Davis via Digitalmars-d
> wrote:
>
> >> for the most time `extern(Windows)` is using only for winapi calls. and
> >> `wsopen` is a library call,
On Wednesday, February 04, 2015 16:24:14 Andrei Alexandrescu via Digitalmars-d
wrote:
> I'm seeing another idiom that seems to become fashionable. Consider this
> excerpt from
> https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
>
> auto opSli
On Thursday, February 05, 2015 01:33:54 David Nadlinger via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu
> wrote:
> > Non-debug mode removes asserts statically. -- Andrei
>
> Using pre-/post-conditions allows the _caller_ to specify whether
> the checks a
On Thursday, February 05, 2015 08:13:32 eles via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 06:55:09 UTC, Vlad Levenfeld
> wrote:
> > On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
> > wrote:
> >> I could care less
> >
> > Er, stupid but unfortunately common american engli
On Thursday, February 05, 2015 17:42:11 Daniel Murphy via Digitalmars-d wrote:
> "Meta" wrote in message news:ejqtxksoifmqzetll...@forum.dlang.org...
>
> > I don't know about others (besides Beatophile, who religiously adheres to
> > writing contacts), but putting contracts on functions is a hassl
On Thursday, February 05, 2015 08:13:31 via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 08:01:06 UTC, Jonathan M Davis
> wrote:
> > the function exits, but in the vast majority of cases, what
> > you're testing
> > with an out contract is what unit tests would be testing, in
> > which ca
On Thursday, February 05, 2015 08:31:08 via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 08:25:56 UTC, Jonathan M Davis
> wrote:
> > case where in blocks would be of value, though I really don't
> > see much
> > difference between checking the assertions in an in block and
> > checking an
On Thursday, February 05, 2015 21:01:19 Daniel Murphy via Digitalmars-d wrote:
> "Jonathan M Davis via Digitalmars-d" wrote in message
> news:mailman.6014.1423124756.9932.digitalmar...@puremagic.com...
> > The real killer feature would be if we could figure out how
On Thursday, February 05, 2015 12:34:34 Kagamin via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 09:43:53 UTC, Jonathan M Davis
> wrote:
> > There is no such difference in the current implementation.
> > assertions inside
> > of in and out blocks are no different from assertions inside of
On Thursday, February 05, 2015 12:03:29 Walter Bright via Digitalmars-d wrote:
> On 2/5/2015 12:22 AM, Jonathan M Davis via Digitalmars-d wrote:
> > No. It's just a frustratingly common mistake - like saying "for all
> > intensive purposes" instead of "for all
On Sunday, February 08, 2015 18:08:31 Walter Bright via Digitalmars-d wrote:
> On 2/8/2015 5:52 PM, Jakob Ovrum wrote:
> > On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
> >> Anyone interested in taking up this flag?
> >
> > Is this idea different from the one in std.internal.test
On Sunday, February 08, 2015 16:43:25 Andrej Mitrovic via Digitalmars-d wrote:
> We still have quite a few features which are listed as
> to-be-deprecated, but without any dates listed:
>
> http://dlang.org/deprecate.html
>
> So, what's the status of these?
I think that it's a case of us agreeing
On Tuesday, February 10, 2015 12:36:50 Walter Bright via Digitalmars-d wrote:
> On 2/9/2015 11:07 PM, deadalnix wrote:
> > On Tuesday, 10 February 2015 at 07:01:18 UTC, Jacob Carlborg wrote:
> >> DMD will complain about the second example if warnings are enabled.
> >
> > Ok I think that answer the
On Tuesday, February 10, 2015 21:25:51 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Feb 10, 2015 at 09:00:33PM -0800, Walter Bright via Digitalmars-d
> wrote:
> > On 2/10/2015 7:49 PM, Jonathan M Davis via Digitalmars-d wrote:
> > >Wait, what? I thought that something had to
On Wednesday, February 11, 2015 08:00:53 Jakob Ovrum via Digitalmars-d wrote:
> Putting the complexity of the container concept aside; I think we
> should factor out the concept checkers from std.range.primitives
> and put them in std.range.concept and establish a convention of
> using modules name
On Wednesday, February 11, 2015 08:59:30 Jakob Ovrum via Digitalmars-d wrote:
> On Wednesday, 11 February 2015 at 08:54:41 UTC, Jonathan M Davis
> wrote:
> > We really haven't been using the
> > term concepts for anything in D, and instead have been heavily
> > using the
> > term traits for what yo
On Wednesday, February 11, 2015 09:30:12 Jakob Ovrum via Digitalmars-d wrote:
> There is a difference between a concept and a trait. A concept
> can be composed of multiple traits. In the context of a concept,
> these traits could be called primitives.
>
> Saying that `isInputRange` is a trait is j
On Monday, February 23, 2015 15:28:21 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 2/23/15 2:15 PM, Walter Bright wrote:
> > This is pretty straightforward.
> [snip]
>
> The code builds if you slap a "@safe:" at the top. There is one bug in
> the compiler: "delete" must not be allowed in @saf
On Monday, February 23, 2015 23:02:03 Walter Bright via Digitalmars-d wrote:
> On 2/23/2015 9:59 PM, Jonathan M Davis via Digitalmars-d wrote:
> > And delete is supposed to have been deprecated ages ago, but yeah, it
> > _definitely_ shouldn't be considered @safe.
>
>
On Tuesday, February 24, 2015 01:44:07 Walter Bright via Digitalmars-d wrote:
> On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
> > The issue is that delete is considered @safe by the compiler,
>
> I thought more people would be interested in how to do a memory
On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote:
> Here is something I've noticed going on various time, recently in
> the memory management threads, but as to avoid an already heated
> debate, I'll use enum types as an example.
>
> We have a problem with the way enums ar
On Thursday, February 26, 2015 20:35:02 deadalnix via Digitalmars-d wrote:
> On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi
> wrote:
> > I think the real problem goes clearly beyond enums, it's an
> > overall approach to changes in the D language itself.
> >
> > I join to deadalnix
On Friday, February 27, 2015 01:48:00 Zach the Mystic via Digitalmars-d wrote:
> On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis
> wrote:
> > Well, I suspect that each case would have to be examined
> > individually to
> > decide upon the best action, but I think that what it comes
>
On Monday, March 09, 2015 12:26:18 Daniel Murphy via Digitalmars-d wrote:
> "Walter Bright" wrote in message news:mdiqav$17i8$1...@digitalmars.com...
>
> > On 3/8/2015 5:00 PM, Daniel Murphy wrote:
> > > If it's a new platform, why would 2.067 be able to target it?
> >
> > Because it'll have a C++
On Tuesday, March 10, 2015 00:41:50 Daniel Murphy via Digitalmars-d wrote:
> "Vladimir Panteleev" wrote in message
> news:vdwvdnzzzhenuybcb...@forum.dlang.org...
>
> > What about source Linux distributions, like Gentoo?
> >
> > What do other self-hosted languages do in this situation?
>
> Download
On Wednesday, March 11, 2015 17:23:13 welkam via Digitalmars-d wrote:
> Observation Nr. 1
> People prefer to write var++ instead of ++var.
>
> Observation Nr. 2
> Because of observation Nr. 1 and other reasons compilers became
> good at removing code that is not needed making var++ and ++var
> to p
On Saturday, March 14, 2015 16:48:21 Walter Bright via Digitalmars-d wrote:
> On 3/14/2015 4:15 PM, Brian Schott wrote:
> > What am I missing?
>
> I suggest defining "The One True Way" and have no configuration options.
Which would instantly make it useless for many users, because many of them
wil
On Saturday, March 14, 2015 13:14:50 Walter Bright via Digitalmars-d wrote:
> I've often thought, as do many others here, that immutability should be the
> default for variables.
>
> [This is a long term issue. Just thought maybe it's time for a conversation
> about it.]
>
> Because immutable is tr
On Saturday, March 14, 2015 21:31:46 Walter Bright via Digitalmars-d wrote:
> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful
> than they are.
Really? I love those. They're _way_ better than /* */. The fact that /* */
don't nest is _very_ annoying, and I think that /+
On Saturday, March 14, 2015 15:35:24 Ali Çehreli via Digitalmars-d wrote:
> On 03/14/2015 03:23 PM, deadalnix wrote:
>
> > But, for some reason, the topic come up again and again from C++ devs
> > that have no idea the optimization guys solved the issues for years now.
>
> If we are talking about
On Sunday, March 15, 2015 02:10:13 Walter Bright via Digitalmars-d wrote:
> > Let's _please_ not try and force any particular style on the D community.
>
> Forcing is a little strong. dfmt is an optional tool, not the core language.
Yes, sorry. Forcing is too strong a word. However, if we're putt
On Sunday, March 15, 2015 03:02:53 Walter Bright via Digitalmars-d wrote:
> Haven't we all got better things to do than argue about formatting styles?
Sure, like we have better things than to argue about vim vs emacs. But I
wouldn't want to be forced to use emacs (or micro-emacs) just because that
On Monday, March 16, 2015 22:27:36 Ali Çehreli via Digitalmars-d wrote:
> The following program compiles fine:
>
> interface I
> {}
>
> class B : I
> {}
>
> class C : B
> {
> int i;
> }
>
> void main()
> {
> auto c = new C;
>
> auto i = cast(I)c;// compiles
> auto b = cast(B
On Thursday, March 19, 2015 22:27:33 deadalnix via Digitalmars-d wrote:
> On Thursday, 19 March 2015 at 22:05:51 UTC, Walter Bright wrote:
> > On 3/19/2015 2:40 AM, deadalnix wrote:
> >> And I'm sorry, but if most function require DDoc, your code
> >> probably sucks quite
> >> badly and some renami
On Friday, March 20, 2015 11:54:20 w0rp via Digitalmars-d wrote:
> On Thursday, 19 March 2015 at 22:04:01 UTC, Walter Bright wrote:
> > Accessor functions that merely return a field variable are bull
> > anyway.
> >
>
> Hear, hear! I start with first with...
>
> public string name;
>
> Then if I re
On Sunday, March 22, 2015 02:32:36 deadalnix via Digitalmars-d wrote:
> On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:
> > On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:
> >> On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:
> >>> I actually think that there
On Saturday, March 21, 2015 22:56:58 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 3/21/15 8:54 PM, Daniel Murphy wrote:
> > "Andrei Alexandrescu" wrote in message
> > news:mel52r$252b$1...@digitalmars.com...
> >
> >> I've left a comment recently at
> >> https://github.com/D-Programming-Langu
On Tuesday, March 31, 2015 14:45:49 Idan Arye via Digitalmars-d wrote:
> But unittests already have
> names(http://dpaste.dzfl.pl/b15e94000f15), so the only required
> change is to allow the user to specify that name. This should be
> much simpler than adding entirely new fields.
Exactly what I wa
I am consistently seeing this when I try and run druntime's unit tests on
FreeBSD for either 2.067 or master:
0.000s PASS release64 object
0.000s PASS release64 core.atomic
0.008s PASS release64 core.bitop
0.000s PASS release64 core.checkedint
0.000s PASS release64 core.demangle
0.000s PASS releas
On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote:
> I think it's worth changing this.
>
> if (arr)
>
> translating to
>
> if (arr.length == 0)
>
> Is immediately obvious for anyone coming from at least a Python
> background. I have implemented my own hashmaps in a similar way.
> For
On Monday, April 06, 2015 20:16:19 Walter Bright via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP76
I am fully in favor of this. Most code really doesn't care about invalid
unicode, and if it does, it can check explicitly. Using the replacement
character is much cleaner and follows the Unicode
On Sunday, April 19, 2015 08:03:09 Muahmmad Adel via Digitalmars-d wrote:
> The following method definition is not possible because
> object.opEquals is not defined as pure.
>
> private pure ushort GetTypeHexadecimalValue(TypeInfo myType)
> {
> if (myType == typeid(byte))
> return
On Sunday, April 19, 2015 18:45:25 Brian via Digitalmars-d wrote:
> I need to use DMD compilation arm or arm64 version, don't know
> DMD now support for the arm.
>
> I think it is very important to the arm of a structure, such as
> rust/go is good enough to support the architecture.
>
> I hope we c
On Sunday, April 19, 2015 08:18:55 Joakim via Digitalmars-d wrote:
> I dusted off the old FreeBSD VM I had lying around and tried it
> out. For me, it hangs in core.thread on FreeBSD 9.1 i386 from a
> couple years ago when I try to run the druntime unit tests with
> dmd/druntime HEAD. At least mo
On Monday, April 20, 2015 04:36:35 Joakim via Digitalmars-d wrote:
> On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote:
> > LOL. Well, I just switched to FreeBSD from Linux so that I
> > could take proper
> > advantage of ZFS, so I may be stuck looking random problems
> > that pop up
On Monday, April 20, 2015 07:54:32 via Digitalmars-d wrote:
> Hi,
>
> I tried to learn about input ranges and got some anonymous advice
> http://forum.dlang.org/thread/dezlxxygufocmafvl...@forum.dlang.org
> , still the topic seems to warrant broader attention.
>
> The question is how pure input ran
On Monday, April 20, 2015 16:14:39 Kagamin via Digitalmars-d wrote:
> On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote:
> > the C folks would think that
> > the current behavior of it being equivalent to if(arr is null)
> > would be more
> > intuitive, since they're used to thinking
On Monday, April 20, 2015 20:44:48 Dan Olson via Digitalmars-d wrote:
> On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote:
> > I am consistently seeing this when I try and run druntime's
> > unit tests on
> > FreeBSD for either 2.067 or master:
> >
> > 0.000s PASS release64 object
>
On Monday, April 20, 2015 22:33:00 Brad Roberts via Digitalmars-d wrote:
> On 4/20/2015 10:24 PM, Jonathan M Davis via Digitalmars-d wrote:
> >
> > No idea whether that's related or not. But regardless, that does narrow down
> > the problem some. Still, given how consis
In any case, I just reported the bug:
https://issues.dlang.org/show_bug.cgi?id=14476
I guess that the fact that it wasn't found sooner just goes to show that not
many druntime developers are using FreeBSD (though that's not exactly
surprising).
- Jonahan M Davis
On Tuesday, April 21, 2015 19:53:47 ketmar via Digitalmars-d wrote:
> here's the interesting oversight for isInputRange:
> https://issues.dlang.org/show_bug.cgi?id=14478
>
> so be careful: ranges with non-copyable elements aren't input ranges for
> now. ;-)
If
auto h = r.front;
doesn't work, the
On Tuesday, April 21, 2015 23:33:38 ketmar via Digitalmars-d wrote:
> On Tue, 21 Apr 2015 15:48:25 -0700, Jonathan M Davis via Digitalmars-d
> wrote:
>
> > On Tuesday, April 21, 2015 19:53:47 ketmar via Digitalmars-d wrote:
> >> here's the interesting oversight
I should also point out that std.array.array can't work with non-copyable
elements, and that's a pretty major function in Phobos. So, if we _were_
going to support non-copyable elements, we couldn't do it simply by making
isInputRange accept them, but regardless, I don't think that it's worth the
e
On Wednesday, April 22, 2015 02:05:38 ketmar via Digitalmars-d wrote:
> On Tue, 21 Apr 2015 18:30:44 -0700, Jonathan M Davis via Digitalmars-d
> wrote:
>
> > And since isInputRange has guaranteed that elements have been copyable,
> > I think that it's perfectly reasona
On Wednesday, April 22, 2015 10:19:01 Kagamin via Digitalmars-d wrote:
> On Monday, 20 April 2015 at 18:01:20 UTC, Jonathan M Davis wrote:
> > An array in C is a pointer, not a struct.
>
> True. I only question the claim that they don't care about such
> things.
> Also difference between pointer an
On Wednesday, April 22, 2015 11:28:43 Daniel Kozak via Digitalmars-d wrote:
> This code compile fine under both versions:
>
> dmd (2.066, -debug -d):
> OK
>
> dmd (2.067, -debug -d):
> core.exception.AssertError@main.d(24): Assertion failure
>
> ./main() [0x46413f]
> ./main(_Dmain+
On Thursday, April 23, 2015 16:29:03 Steven Schveighoffer via Digitalmars-d
wrote:
> On 4/23/15 4:25 PM, bearophile wrote:
> > Martin Krejcirik:
> >
> >> So, should the case b compile or not ? Is the spec too restrictive
> >> here, or is it a bug ?
> >
> > Apparently it's a WONTFIX mess. The spec
On Friday, 24 April 2015 at 20:44:34 UTC, Walter Bright wrote:
On 4/24/2015 11:52 AM, H. S. Teoh via Digitalmars-d wrote:
I really wish we would just *make the darn decision* already,
whether to
kill off autodecoding or not, and MAKE IT CONSISTENT ACROSS
PHOBOS,
instead of introducing this schi
On Saturday, 25 April 2015 at 02:04:02 UTC, Steven Schveighoffer
wrote:
On 4/24/15 9:02 PM, Walter Bright wrote:
On 4/24/2015 4:56 PM, Steven Schveighoffer wrote:
This is pretty easy. We just have to create a string type
that is
backed by, but
isn't simply an alias to, an array of char.
Just
On Monday, 27 April 2015 at 17:01:03 UTC, H. S. Teoh wrote:
On Sat, Apr 25, 2015 at 02:27:45AM +, Jonathan M Davis via
Digitalmars-d wrote:
[...]
I suppose that a related alternative would be to change it so
that
strings aren't considered ranges anymore (at least
temporarily), and
On Tuesday, 28 April 2015 at 09:11:10 UTC, Chris wrote:
Would it be much work to show have example code or even an
experimental module that gets rid of auto-decoding, so we could
see what would be affected in general and how actual code we
have would be affected by it?
The topic keeps coming
On Tuesday, 28 April 2015 at 23:26:14 UTC, Damian wrote:
I second that! If we all make the switch, perhaps Walter will
too? :D
Walter isn't necessarily the one we have to convince in this
case. He'll be very concerned about avoiding breaking existing
code, so we'd need a solid transition plan
On Tuesday, 28 April 2015 at 21:57:31 UTC, Vladimir Panteleev
wrote:
On Tuesday, 28 April 2015 at 16:48:48 UTC, Jonathan M Davis
wrote:
But of course, we'd want to do the transition in a way that
didn't result in silent behavioral changes that would break
code,
One proposal is to make char an
On Wednesday, 29 April 2015 at 10:02:09 UTC, Chris wrote:
This sounds like a good starting point for a transition plan.
One important thing, though, would be to do some benchmarking
with and without autodecoding, to see if it really boosts
performance in a way that would justify the transition.
301 - 400 of 2444 matches
Mail list logo
