Re: colour lib

Am Fri, 2 Sep 2016 15:58:05 +1000 schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > On 2 September 2016 at 06:09, Marco Leise via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > > I'd suspect #1 to be the best option, too. However, I don't >

Re: colour lib

> Is it s or z ? :) It's an alias to forego any language bike shedding.

Re: colour lib

Am Wed, 31 Aug 2016 15:58:28 +1000 schrieb Manu via Digitalmars-d : > I have this implementation issue, which I'm having trouble applying > good judgement, I'd like to survey opinions... > > So, RGB colours depend on this 'normalised integer' concept, that is: >

Re: Do you like bounded integrals?

Am Tue, 23 Aug 2016 16:40:06 -0400 schrieb Andrei Alexandrescu : > Currently checkedint (https://github.com/dlang/phobos/pull/4613) stands > at 2432 lines and implements a variety of checking behaviors. At this > point I just figured I can very easily add custom

Re: Optimisation possibilities: current, future and enhancements

Am Thu, 25 Aug 2016 11:45:40 + schrieb Cauterite : > - if a function is pure and called with constexpr parameters, the > compiler could potentially execute that call in the CTFE engine > (automatically), as part of the constant-folding phase I guess. > Such a technique

Re: [OT] of [OT] I am a developer and I hate documentation

Am Fri, 19 Aug 2016 07:34:51 -0700 schrieb "H. S. Teoh via Digitalmars-d" : > On Fri, Aug 19, 2016 at 10:50:20AM +, Chris via Digitalmars-d wrote: > > On Thursday, 18 August 2016 at 17:23:09 UTC, H. S. Teoh wrote: > > > On Thu, Aug 18, 2016 at 04:56:32PM +,

Re: Why D is not popular enough?

Am Fri, 19 Aug 2016 13:36:05 + schrieb Adam D. Ruppe : > On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote: > > If we hypothetically switched to a ubyte+ubyte=ubyte semantic, > > then code like this breaks silently: > > However, if it took the entire

Re: Why D is not popular enough?

Am Mon, 15 Aug 2016 10:54:11 -0700 schrieb Ali Çehreli : > On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote: > > On 08/14/2016 01:18 AM, Shachar Shemesh wrote: > > >> Also, part of our > >> problems with this is that introspection also does not see refs, which > >>

Re: Why D is not popular enough?

Am Thu, 18 Aug 2016 22:50:27 + schrieb John Smith : > Well you could say the same for the same for int. Why isn't "int > + int = long"? Right now it is following the rule "int + int = > int". I believe in C, int reflects the native machine word that the CPU always uses

Re: [OT] of [OT] I am a developer and I hate documentation

Am Thu, 18 Aug 2016 14:59:08 + schrieb Chris : > On Thursday, 18 August 2016 at 14:31:47 UTC, Adam D. Ruppe wrote: > It would be a good starting point for documentation stubs, not a > substitute for a proper, full-fledged documentation. The most > annoying thing about

Re: Cannot compare object.opEquals is not nogc

Am Sat, 23 Jul 2016 13:18:03 + schrieb Rufus Smith : > Trying to compare a *ptr value with a value in nogc code results > in the error: > > Error: @nogc function '...' cannot call non-@nogc function > 'object.opEquals' > > Shouldn't object opEquals be

Re: DConf Videos

Am Thu, 21 Jul 2016 23:04:11 + schrieb sarn : > On Thursday, 21 July 2016 at 13:45:28 UTC, Steven Schveighoffer > wrote: > > On 6/6/16 6:40 AM, sarn wrote: > >> What's the best source of DConf videos at the moment? Are > >> there are any > >> edited versions

Re: new cpuid is ready for comments

Am Mon, 11 Jul 2016 16:30:44 + schrieb Ilya Yaroshenko : > Please report your CPU (GitHub/Gist): Instead of yet another Haswell/Broadwell, here is an oldie but goldie: A 16 year old Pentium-III-M from an IBM T23 notebook:

Re: QtE5 - is a wrapping of Qt-5 for D

Very nice! -- Marco

Re: The Case Against Autodecode

Am Thu, 2 Jun 2016 18:54:21 -0400 schrieb Andrei Alexandrescu : > On 06/02/2016 06:10 PM, Marco Leise wrote: > > Am Thu, 2 Jun 2016 15:05:44 -0400 > > schrieb Andrei Alexandrescu : > > > >> On 06/02/2016 01:54 PM, Marc Schütz wrote:

Re: The Case Against Autodecode

Am Thu, 2 Jun 2016 15:05:44 -0400 schrieb Andrei Alexandrescu : > On 06/02/2016 01:54 PM, Marc Schütz wrote: > > Which practical tasks are made possible (and work _correctly_) if you > > decode to code points, that don't already work with code units? > > Pretty

[OT] Effect of UTF-8 on 2G connections

Am Wed, 01 Jun 2016 13:57:27 + schrieb Joakim : > No, I explicitly said not the web in a subsequent post. The > ignorance here of what 2G speeds are like is mind-boggling. I've used 56k and had a phone conversation with my sister while she was downloading a 800 MiB

Re: Variables should have the ability to be @nogc

Am Tue, 31 May 2016 20:41:09 + schrieb Basile B. : > The only thing is that I'm not sure about is the tri-state and > the recursion. I cannot find a case where it would be justified. The recursion is simply there to find pointers in nested structs and their GcScan

[OT] UTF-16

Am Tue, 31 May 2016 15:47:02 -0700 schrieb Walter Bright : > But I didn't know which encoding would win - UTF-8, UTF-16, or UCS-2, so D > bet > on all three. If I had a do-over, I'd just support UTF-8. UTF-16 is useful > pretty much only as a transitional encoding

Re: Our Sister

Am Wed, 1 Jun 2016 01:06:36 +1000 schrieb Manu via Digitalmars-d : > D loves templates, but templates aren't a given. Closed-source > projects often can't have templates in the public API (ie, source > should not be available), and this is my world. Same effect for

Re: The Case Against Autodecode

Am Tue, 31 May 2016 16:56:43 -0400 schrieb Andrei Alexandrescu : > On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote: > > In the vast majority of cases what folks care about is full character > > How are you so sure? -- Andrei Because a full

Re: The Case Against Autodecode

Am Tue, 31 May 2016 13:06:16 -0400 schrieb Andrei Alexandrescu : > On 05/31/2016 12:54 PM, Jonathan M Davis via Digitalmars-d wrote: > > Equality does not require decoding. Similarly, functions like find don't > > either. Something like filter generally would, but

Re: The Case Against Autodecode

Am Tue, 31 May 2016 16:29:33 + schrieb Joakim : > Part of it is the complexity of written language, part of it is > bad technical decisions. Building the default string type in D > around the horrible UTF-8 encoding was a fundamental mistake, > both in terms of

Re: Variables should have the ability to be @nogc

Am Tue, 31 May 2016 15:53:44 + schrieb Basile B. : > This solution seems smarter than using the existing '@nogc' > attribute. Plus one also for the fact that nothing has to be done > in DMD. I just constrained myself to what can be done in user code from the start. :) >

Re: asm woes...

Am Fri, 27 May 2016 10:16:48 + schrieb Era Scarecrow : > On Friday, 27 May 2016 at 10:14:31 UTC, Era Scarecrow wrote: > > inc dword ptr [EAX+Foo.x.offsetof]; > > > So just tested it, and it didn't hang, meaning all unittests > also passed. > > Final solution is:

Re: asm woes...

Am Fri, 27 May 2016 10:06:28 + schrieb Guillaume Piolat : > Referencing EBP or ESP yourself is indeed dangerous. Not sure why > the documentation would advise that. Using "this", names of > parameters/locals/field offset is much safer. DMD makes sure that the EBP

Re: Variables should have the ability to be @nogc

I "solved" it with a UDA called GcScan in my code. It can be attached to any field or type and is a tri-state. In the undecided case (GcScan.auto) it recursively scans for potential GC pointers, excluding those marked GcScan.no. In the decided case (GcScan.yes/no) it simply assumes the user knows

Re: The Case Against Autodecode

Am Tue, 31 May 2016 07:17:03 + schrieb default0 : > Thinking about this a bit more - what algorithms are actually > correct when implemented on the level of code units? Calculating the buffer size of a string, validation and fast versions of general algorithms that

Re: The Case Against Autodecode

A relevant thread in the Rust bug tracker I remember from three years ago: https://github.com/rust-lang/rust/issues/7043 May it be of inspiration. -- Marco

Re: The Case Against Autodecode

> 4: Indonesians* shall be converted to a sane alphabet *Correction: Koreans (2-4 Hangul syllables (code points) form each letter) -- Marco

Re: The Case Against Autodecode

Am Fri, 27 May 2016 15:47:32 +0200 schrieb ag0aep6g : > On 05/27/2016 03:32 PM, Andrei Alexandrescu wrote: > >>> However the following do require autodecoding: > >>> > >>> s.walkLength > >>> s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation > >>> s.count!(c => c >=

Re: The Case Against Autodecode

Am Mon, 30 May 2016 17:14:47 + schrieb Andrew Godfrey : > I like "make string iteration explicit" but I wonder about other > constructs. E.g. What about "sort an array of strings"? How would > you tell a generic sort function whether you want it to interpret > strings by code

Re: The Case Against Autodecode

Am Mon, 30 May 2016 17:35:36 + schrieb Chris : > I was actually talking about ICU with a colleague today. Could it > be that Unicode itself is broken? I've often heard criticism of > Unicode but never looked into it. You have to compare to the situation before, when every

Re: The Case Against Autodecode

Am Thu, 26 May 2016 16:23:16 -0700 schrieb "H. S. Teoh via Digitalmars-d" : > On Thu, May 26, 2016 at 12:00:54PM -0400, Andrei Alexandrescu via > Digitalmars-d wrote: > [...] > > s.walkLength > > s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation > >

Re: The Case Against Autodecode

Am Mon, 30 May 2016 09:26:09 + schrieb Chris : > If it's true that auto decode is unnecessary in many cases, then > it shouldn't affect the whole code base. But I might be mistaken > here. Maybe we should make a list of the functions where auto > decode does make a

Re: Our Sister

Am Sat, 28 May 2016 14:15:45 +1000 schrieb Manu via Digitalmars-d : > On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d > wrote: > > On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote: > >> > >> not if [] would be ref-counted too

Re: Is placing data with align(32) on the stack with 16-byte alignment an error?

Am Sun, 29 May 2016 13:20:12 + schrieb Johan Engelen : > On Sunday, 29 May 2016 at 12:07:02 UTC, Marco Leise wrote: > > > > void main() { > > import core.simd; > > Matrix4x4 matrix; // No warning > > float8 vector; // No warning > > } > > Did you do some LDC

Re: Is placing data with align(32) on the stack with 16-byte alignment an error?

P.S.: From the following bug report, it looks like gcc and icc honor stack alignments >= 16: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948 That would be a good solution for dmd, too. -- Marco

Is placing data with align(32) on the stack with 16-byte alignment an error?

I'll try to be concise: The stack on x64 is 16-byte aligned, enough for SSE registers, but not the 32-byte AVX registers. Any data structure containing AVX registers, cannot be guaranteed to be correctly aligned on the stack, but we get no warning if we try anyways: align(32) struct Matrix4x4 {

Re: Is there an easy way to convert a pointer to malloc'd memory to an array?

Am Tue, 24 May 2016 20:58:14 + schrieb Gary Willoughby : > On Tuesday, 24 May 2016 at 18:43:22 UTC, Adam D. Ruppe wrote: > > On Tuesday, 24 May 2016 at 18:42:41 UTC, Gary Willoughby wrote: > >> I have a T* pointer to the start of a malloc'd chunk of > >> memory, the type T

Re: Need a Faster Compressor

Am Tue, 24 May 2016 19:16:07 + schrieb Anon : > Upping it to sixteen levels: > > current: Generate a 3_688_679 byte symbol > lz4 -9: Generate a 3_688_679 byte symbol, then compress it to > 15535 bytes > lzma -9: Generate a 3_688_679 byte symbol, then compress it to > 840

Re: Need a Faster Compressor

Am Mon, 23 May 2016 12:04:48 + schrieb Stefan Koch : > The method for archiving perfect compression it outlined here: > https://github.com/Cyan4973/lz4/issues/183 Nice, if it can keep the compression speed up. -- Marco

Re: Need a Faster Compressor

Am Sun, 22 May 2016 23:42:33 -0700 schrieb Walter Bright : > The file format: http://cyan4973.github.io/lz4/lz4_Block_format.html > > It doesn't look too difficult. If we implement our own LZ4 compressor based > on > that, from scratch, we can boost license it. Ok,

Re: Need a Faster Compressor

Am Sun, 22 May 2016 20:22:06 +0200 schrieb Rainer Schuetze : > The 3 consecutive ?s are also in the object file, so they are actually > part of the mangled symbol. VC++ uses only ASCII characters for mangling > (which D should do, too, IMO). In general I agree. The extended

Re: Need a Faster Compressor

Am Sun, 22 May 2016 13:02:37 -0700 schrieb Walter Bright : > On 5/22/2016 9:06 AM, Marco Leise wrote: > > Are there any objections > > against the benchmarking method or the license? > > BSD may cause problems. > > > Can the implementation be in D? > > Not yet.

Re: Need a Faster Compressor

Am Sun, 22 May 2016 17:19:38 + schrieb Stefan Koch : > Here are my answers please take them with a grain of ignorance. > […] Maybe you are right about the dictionary. I haven't put much any thought into it. Anyways I was looking for input from the core devs who

Re: Need a Faster Compressor

Am Sun, 22 May 2016 14:06:52 + schrieb Stefan Koch : > On Sunday, 22 May 2016 at 14:05:23 UTC, Marco Leise wrote: > > ⬅ Download proof of concept > > > > This is a proof of concept micro-benchmark compressing the > > 37_640 bytes symbol from the bug report linked

Re: Need a Faster Compressor

⬅ Download proof of concept This is a proof of concept micro-benchmark compressing the 37_640 bytes symbol from the bug report linked above with both id_compress from the dmd backend and lz4 (without dictionary). The lz4 result is additionally transformed to 7-bits similar to base-64. Original

Re: Need a Faster Compressor

Am Sun, 22 May 2016 10:55:40 + schrieb Era Scarecrow : > On Sunday, 22 May 2016 at 10:40:46 UTC, qznc wrote: > > On Saturday, 21 May 2016 at 21:12:15 UTC, Walter Bright wrote: > > It links to SMAZ: > > > > https://github.com/antirez/smaz > > > > It uses a codebook primed

Re: Need a Faster Compressor

Am Sat, 21 May 2016 14:12:15 -0700 schrieb Walter Bright : > The current one is effective, but slow: > >https://github.com/dlang/dmd/blob/master/src/backend/compress.c > > Anyone want to make a stab at making it faster? Changing the format is fair > game, as

Re: Need a Faster Compressor

Am Sun, 22 May 2016 09:57:20 + schrieb Era Scarecrow : > On Sunday, 22 May 2016 at 09:48:32 UTC, Stefan Koch wrote: > > Nice results. > > This is with one sample to test against. I need a much bigger > sample, but I'm not sure how to generate/find it to give it a >

Re: Always false float comparisons

Am Tue, 17 May 2016 04:12:09 + schrieb Era Scarecrow : > I understand fixed floating point Quote of the day :D -- Marco

Re: Formatted Output: Exact number of Decimal Places

Am Mon, 16 May 2016 20:24:51 + schrieb Q. Schroll : > Lets say I want to print a table with floats. How can it be > formatted like that: > | 2.4 | > | 12.2 | > | 8.131 | > | 17.44 | > Also acceptable is > | 2.400 | > | 12.200 | > | 8.131 | > | 17.440 |

Re: Always false float comparisons

I wondered how the precision of typical SSE vs FPU code would compare. SSE uses floats and doubles as the main mean to control precision, while the FPU is configured via x87 control word. The attached program calculates 5^-441 iteratively using these methods, then converts to double and prints

Re: Always false float comparisons

Am Mon, 16 May 2016 00:52:41 -0700 schrieb Walter Bright : > On 5/15/2016 11:14 PM, Ola Fosheim Grøstad wrote: > > But hey, here is another one: > > > > const real x = f(); > > assert(0<=x && x<1); > > x += 1; > > > > const float f32 = cast(float)(x); > > const real

Re: The Case Against Autodecode

Am Thu, 12 May 2016 13:15:45 -0700 schrieb Walter Bright : > 7. Autodecode cannot be used with unicode path/filenames, because it is legal > (at least on Linux) to have invalid UTF-8 as filenames. More precisely they are byte strings with '/' reserved to separate

Re: Always false float comparisons

Am Thu, 12 May 2016 09:03:58 -0400 schrieb Steven Schveighoffer : > Not taking one side or another on this, but due to D doing everything > with reals, this is already the case. > > -Steve As far as I have understood the situation: - FPU instructions are inaccurate - FPU

Re: Always false float comparisons

Am Thu, 12 May 2016 08:55:52 -0700 schrieb Walter Bright : > On 5/12/2016 3:30 AM, Manu via Digitalmars-d wrote: > > If you're set on a warning, at least make the warning recommend > > down-casting the higher precision term to the lower precision? > > Yes, of

Re: Always false float comparisons

Am Mon, 9 May 2016 04:26:55 -0700 schrieb Walter Bright : > > I wonder what's the difference between 1.30f and cast(float)1.30. > > There isn't one. Oh yes, there is! Don't you love floating-point... cast(float)1.30 rounds twice, first from a base-10

Re: Casting Pointers?

Am Thu, 12 May 2016 09:32:17 + schrieb Rene Zwanenburg : > In this case, you can use a union: > > union DL > { > double d; > long l; > } > > auto dl = DL(1.0); > writeln(dl.l); The pointer cast solution is specifically supported at CTFE, because

Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.

Am Wed, 11 May 2016 11:37:03 + schrieb Marc Schütz : > On Monday, 9 May 2016 at 08:44:53 UTC, Dmitry Olshansky wrote: > > On 09-May-2016 02:38, Jon D wrote: > >> [...] > > > > The only problem is that it should consider multi-codepoint > > replacements aka full-case

Re: Dconf videos offline download?

Until edited 1080p videos become available, you can use FlashGot in Firefox to get at the flash video files in ustream.tv. Here is a set of extracted links: Day 1: http://upmv09-gblx-upmv.ustream.tv/iphash/0/1/86/86468/86468045/1_22379980_86468045.flv?e=1463519354=df9f0848ed7767b223472273f08bdbfa

Re: Always false float comparisons

Am Mon, 09 May 2016 15:56:21 + schrieb Nordlöw : > On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote: > > On 5/9/2016 4:38 AM, Nordlöw wrote: > >> Would that include comparison of variables only aswell? > > No. > > Why? Because the float would be

Re: Always false float comparisons

Am Mon, 9 May 2016 02:10:19 -0700 schrieb Walter Bright : > Don Clugston pointed out in his DConf 2016 talk that: > > float f = 1.30; > assert(f == 1.30); > > will always be false since 1.30 is not representable as a float. However, > > float f =

Re: inferred size for static array initialization

Am Mon, 2 May 2016 18:52:11 +0200 schrieb ag0aep6g : > On 02.05.2016 15:53, Marco Leise wrote: > >immutable tab = { static enum S[] s = [ > > `static enum`? What kind of black magic is this? I don't know, but it works, haha. -- Marco

Re: inferred size for static array initialization

Am Mon, 02 May 2016 13:00:27 + schrieb Erik Smith : > Is there a way to initialize a static array and have it's size > inferred (and that works for arrays of structs using braced > literals)? This would make it easier to maintain longer static > array definitions.

Re: My favourite game: DMD guess the error reason.

I don't have an ARMv8 or emulator to test on, so I'll take a wild guess. Is the answer 1,2,3,4,5,6,7,8,9 ? -- Marco

Off-topic: Nationalism on the rise again?

Am Sat, 30 Apr 2016 13:08:28 + schrieb QAston : > On Friday, 29 April 2016 at 09:07:47 UTC, Marco Leise wrote: > > It might be difficult with your daily > > experience in Berlin to look at the world from above, but if > > you do it should become obvious looking at Turkey,

Re: Clarification about compilation model and the mapping of package names to directory.

It is de facto allowed, yes. But if it only works in compile-at-once, and isn't essential for some use case, it is just friction and I agree to forcing package names to match their paths. But I suspect there is _are_ use cases. It's not the first time we talk about this, IIRC. -- Marco

Re: Walter's Famous German Language Essentials Guide

Am Thu, 28 Apr 2016 13:49:15 + schrieb jack : > unfortunately - too many islam and erdogan people Great anonymous comment directed at a Turk for him to take offense. How about you respect the constitution and ask others to respect it, leaving religion and ethnics aside? You'll

Re: Walter's Famous German Language Essentials Guide

Am Thu, 28 Apr 2016 09:15:27 + schrieb Chris : > Except when it corresponds to the natural gender, i.e. der Mann, > die Frau. It's interesting that the word for child is neuter (das > Kind). Looks like children are not yet considered to be of any > sex, which makes a lot of

Re: LZ4 decompression at CTFE

Am Tue, 26 Apr 2016 23:55:46 -0700 schrieb Walter Bright : > On 4/26/2016 3:05 PM, Stefan Koch wrote: > > Hello, > > > > originally I want to wait with this announcement until DConf. > > But since I working on another toy. I can release this info early. > > > > So as

Re: Walter's Famous German Language Essentials Guide

It just came to my ears that Seb was just joking about that WC rule. -- Marco

Re: Walter's Famous German Language Essentials Guide

Am Wed, 27 Apr 2016 03:59:04 + schrieb Seb : > nitpick: Wo ist _das_ WC? > In German WC we have definite articles and as a WC can be used by > both sexes, it is neutral (disclaimer: not a rule). There are some reasons why some words are feminine, masculine or neutral, but I

Re: Garbage Collector : Ignoring a reference

Am Tue, 26 Apr 2016 13:35:37 + schrieb Begah : > When the screen switches to another screen ie from menu to the > game, > I want that the "button.png" texture is automaticly destroyed by > the gc. My ideological point of view is that you must not use

Re: Checking if an Integer is an Exact Binary Power

Am Mon, 25 Apr 2016 17:04:43 + schrieb tsbockman : > On Monday, 25 April 2016 at 16:48:14 UTC, Lass Safin wrote: > > Example; > > > > import core.bitop; > > import core.cpuid; > > > > int count; > > if(hasPopcnt) > > count = _popcnt; // Uses x86-instruction

Re: An important pull request: accessing shared affix for immutable data

Am Sat, 13 Feb 2016 19:16:43 +0100 schrieb Timon Gehr : > Not necessarily. shared is transitive and prefix/suffix are arbitrary > types which might contain mutable indirections. I don't want to disturb your conversation, but how about designing a working "shared" first? My

Re: Any usable SIMD implementation?

Am Sat, 23 Apr 2016 10:40:12 + schrieb Johan Engelen : > I have a question perhaps you can comment on? > With LLVM, it is possible to specify something like "+sse3,-sse2" > (I did not test whether this actually results in SSE3 > instructions being used, but no SSE2 instructions).

Re: Checking if an Integer is an Exact Binary Power

Am Sat, 23 Apr 2016 20:34:52 + schrieb Nordlöw : > On Saturday, 23 April 2016 at 17:28:21 UTC, Andrei Alexandrescu > wrote: > >> Yah, that's the canonical. I forgot why I chose (x & -x) > (x > >> - 1) over > >> it. -- Andrei > > So is there a way to check if popcnt

Re: Adding a float with all four elements of a float4

Am Thu, 21 Apr 2016 00:14:53 + schrieb Straivers : > Hi, > > I want to make a utility wrapper around a core.simd.float4, and > have been trying to make the following code work, but have been > met with no success. > > auto add(float rhs) > { > return

Re: Distributor's whishlist and questions for D

> > You can only install headers for one library version with this > > approach! A versioned approach is nicer > > /usr/include/d/libfoo/1.0.0 but requires explicit compiler > > support and it's unlikely this will happen (or explicit dub > > support and you compile everything through dub). >

Re: Distributor's whishlist and questions for D

Am Thu, 21 Apr 2016 15:34:35 + schrieb Matthias Klumpp : > That doesn't seem to be the case for LDC on Debian... It installs > Phobos into /usr/include/d/std, which makes GDC go crazy as soon > as LDC is installed too. See also:

Re: Distributor's whishlist and questions for D

Am Thu, 21 Apr 2016 01:01:01 + schrieb Matthias Klumpp : > Hello! > Me bringing dub to Debian (and subsequently Ubuntu) has sparked > quite some interest in getting more D applications shipped in > Linux distributions. Having been in a similar situation years ago, I

Re: Blog post: PGO: Optimizing D's virtual calls

Am Fri, 15 Apr 2016 09:04:21 + schrieb Johan Engelen : > On Wednesday, 13 April 2016 at 11:34:26 UTC, Johan Engelen wrote: > > Hi all, > > I've written an article about how I implemented > > profile-guided optimization (PGO) of virtual calls to direct > > calls (a

Re: about destroy and delete.

The semantics of `delete` from C++ are pretty clear. It is meant for dynamically allocated memory. destroy(…) however is a generic tool that brings the thing you pass in back to an initial state. For pointers, null is assigned, for structs and classes (which are not pointers but references) the

Re: Policy for exposing range structs

What about using old string compression algorithms on the mangled name? That should effectively get rid of all the repeated words. -- Marco

Re: Phobos posix.mak -> D file using reggae: round 2

Am Tue, 19 Apr 2016 17:02:43 + schrieb Atila Neves : > > DC_FLAGS=-O5 (flags for that compiler) > > LDFLAGS=-L=-O1 (flags for the linker) > > PREFIX=/usr (installation prefix) > > These I need to add. Well, if there's enough of a use-case anyway. It's just normal

On attribute inference...

Currently the compiler makes sure, that it can see the entire nested call chain when performing attribute inference. So it limits itself to function literals and templates where the source has to be right there for them to compile. The remaining functions could roughly be classified as functions

Re: DIP64: Attribute Cleanup

Am Mon, 18 Apr 2016 20:49:45 + schrieb jmh530 : > As an aside, the reason for not having function attribute > inference everywhere is that it doesn't work when function bodies > are not available. How common is this? I feel like I never write > functions like

Re: Phobos posix.mak -> D file using reggae: round 2

Am Mon, 18 Apr 2016 15:15:26 + schrieb Atila Neves : Just remember that makefiles are well integrated with other systems (i.e. package managers) and there are some conventions, about what certain environment variables mean. To name a few: MAKEOPTS=-j4 (parallel build

Re: We need a couple hundreds of these

Am Fri, 15 Apr 2016 12:08:37 -0400 schrieb Andrei Alexandrescu : > https://github.com/D-Programming-Language/phobos/pull/4200 -- Andrei Whenever I notice something like that in my code, it makes me smile with the reassuring thought that the right design choices

Re: Any usable SIMD implementation?

Am Sat, 16 Apr 2016 21:46:08 -0700 schrieb Walter Bright : > On 4/16/2016 2:40 PM, Marco Leise wrote: > > Tell me again, what's more elgant ! > > If I wanted to write in assembler, I wouldn't write in a high level language, > especially a weird one like GNU

Re: So what does (inout int = 0) do?

Am Fri, 15 Apr 2016 09:44:05 -0400 schrieb Andrei Alexandrescu : inout must go. -- Andrei Ceterum censeo Carthaginem esse delendam. -- Marcus Porcius Cato :o) -- Marco

Re: Any usable SIMD implementation?

Am Tue, 12 Apr 2016 23:22:37 -0700 schrieb Walter Bright : > >"mulq %[y]" > >: "=a" tmp.lo, "=d" tmp.hi : "a" x, [y] "rm" y; > > I don't see anything elegant about those lines, starting with "mulq" is not > in > any of the AMD or Intel CPU

Re: Any usable SIMD implementation?

Am Fri, 15 Apr 2016 18:54:12 + schrieb jmh530 : > On Tuesday, 12 April 2016 at 10:55:18 UTC, xenon325 wrote: > > > > Have you seen how GCC's function multiversioning [1] ? > > > > I've been thinking about the gcc multiversioning since you > mentioned it

Re: Who wore it better?

Am Fri, 15 Apr 2016 14:48:26 -0400 schrieb Andrei Alexandrescu : > On 4/15/16 2:46 PM, Steven Schveighoffer wrote: > > On 4/15/16 1:24 PM, Andrei Alexandrescu wrote: > >> auto overlap(T, U)(T[] r1, U[] r2) @trusted pure nothrow > >> if (is(typeof(r1.ptr < r2.ptr)

Re: Any usable SIMD implementation?

Am Wed, 13 Apr 2016 04:14:48 -0700 schrieb Walter Bright : > On 4/13/2016 3:58 AM, Marco Leise wrote: > > How about this style as an alternative?: > > > > immutable bool mmx; > > immutable bool hasPopcnt; > > > > shared static this() > > { > > import gcc.builtins;

Re: Any usable SIMD implementation?

Am Wed, 13 Apr 2016 11:21:35 +0200 schrieb Iain Buclaw via Digitalmars-d : > Yes, cpu_supports is a good way to do it as we only need to invoke > __builtin_cpu_init once and cache all values when running 'shared > static this()'. I was under the assumption that GCC

Re: Any usable SIMD implementation?

Am Wed, 13 Apr 2016 09:51:25 +0200 schrieb Iain Buclaw via Digitalmars-d : > On 13 April 2016 at 07:59, Walter Bright via Digitalmars-d > wrote: > > But core.cpuid needs to be made to work in GDC, whatever it takes to do so. > > > >

Re: Any usable SIMD implementation?

Am Tue, 12 Apr 2016 13:22:12 -0700 schrieb Walter Bright : > On 4/12/2016 9:53 AM, Marco Leise wrote: > > LDC implements InlineAsm_X86_Any (DMD style asm), so > > core.cpuid works. GDC is the only compiler that does not > > implement it. We agree that core.cpuid should

<    1   2   3   4   5   6   >