Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 May 2019 at 21:21:35 UTC, Manu wrote: Huh? Servers take loads-of-cores as far as you possibly can! Yes, but you might want to limit a single client to a process and limit the thread count, for isolation and simple load balancing. But I am not sure what the use scenario is...

Re: DMD 32 bit Linux code gen now uses XMM for float & double

2019-05-27 Thread Walter Bright via Digitalmars-d-announce
On 5/27/2019 6:46 PM, 9il wrote: Does DMD still use x87 for float/double on other targets? Yes - Win32 and FreeBSD32. We'll see how this goes, and if it's good we can do the rest.

Re: DMD 32 bit Linux code gen now uses XMM for float & double

2019-05-27 Thread 9il via Digitalmars-d-announce
On Tuesday, 28 May 2019 at 01:23:18 UTC, Walter Bright wrote: 32 Bit Linux now uses XMM registers for float and double rather than the x87. This should substantially speed up routine float and double processing. SIMD vector operations, however, are still not support on 32 bit Linux code

DMD 32 bit Linux code gen now uses XMM for float & double

2019-05-27 Thread Walter Bright via Digitalmars-d-announce
32 Bit Linux now uses XMM registers for float and double rather than the x87. This should substantially speed up routine float and double processing. SIMD vector operations, however, are still not support on 32 bit Linux code because of issues with 16 byte stack alignment. This means that

Re: Let's celebrate Dlang on D day

2019-05-27 Thread Mike Franklin via Digitalmars-d-announce
On Saturday, 25 May 2019 at 21:56:57 UTC, Murilo wrote: Sorry people It's ok. I know you meant well, and we're happy to have people in this community so passionate about D. Mike

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Manu via Digitalmars-d-announce
On Mon, May 27, 2019 at 2:00 PM Ola Fosheim Grøstad via Digitalmars-d-announce wrote: > > On Monday, 27 May 2019 at 20:14:26 UTC, Manu wrote: > > Computers haven't had only one thread for almost 20 years. Even > > mobile > > phones have 8 cores! > > This leads me back to my original proposition.

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 May 2019 at 20:14:26 UTC, Manu wrote: Computers haven't had only one thread for almost 20 years. Even mobile phones have 8 cores! This leads me back to my original proposition. If Robert is aiming for embedded and server rendering then he probably wants a simple structure with

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Manu via Digitalmars-d-announce
On Mon, May 27, 2019 at 1:05 AM Ola Fosheim Grøstad via Digitalmars-d-announce wrote: > > On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote: > > How does the API's threadsafety mechanisms work? How does it > > scale to my 64-core PC? How does it schedule the work? etc... > > Ah yes, if you don't

Re: Let's celebrate Dlang on D day

2019-05-27 Thread Walter Bright via Digitalmars-d-announce
This is getting way off topic, guys.

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
On 27.05.19 15:34, Atila Neves wrote: It's ugly but would work. Right now I don't think I can do any better than to follow your suggestion, but I predict many beard-stroking walks for me along Lake Geneva in the near future. Oh, yeah. Getting @trusted right is hard. Getting it right when

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
On Monday, 27 May 2019 at 10:31:10 UTC, ag0aep6g wrote: On 27.05.19 12:06, Atila Neves wrote: No, and I guess it can't. I'm trying to figure out what the implications are. Can Vector only be @safe for Mallocator? Is it possible to write a @safe Vector at all without having to force the

Re: Let's celebrate Dlang on D day

2019-05-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 May 2019 at 05:34:55 UTC, Nick Sabalausky (Abscissa) wrote: I suspect our closest hope may lie with something like this: Although, even that only seems a mere "step in the right direction", rather than a solution...(Under

Re: Let's celebrate Dlang on D day

2019-05-27 Thread Basile B. via Digitalmars-d-announce
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote: On the 6th of June(6/6) we celebrate the D day on Normandy, but I have decided to turn it into our own holiday to celebrate the D language. So on this day please take the time to tell the world about this language and to invite more

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
On 27.05.19 12:06, Atila Neves wrote: No, and I guess it can't. I'm trying to figure out what the implications are. Can Vector only be @safe for Mallocator? Is it possible to write a @safe Vector at all without having to force the allocator to be @safe? For @safe allocators, Vector can be

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Paolo Invernizzi via Digitalmars-d-announce
On Monday, 27 May 2019 at 10:01:15 UTC, Atila Neves wrote: On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote: On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
On Monday, 27 May 2019 at 09:48:27 UTC, ag0aep6g wrote: On 27.05.19 10:54, Atila Neves wrote: I don't see the problem here. This example would throw RangeError at runtime instead of actually overwriting memory unless bounds checking is turned off. No, it doesn't. It's a complete, runnable

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote: On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library really does want to corrupt memory they can just tag all their

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread ag0aep6g via Digitalmars-d-announce
On 27.05.19 10:54, Atila Neves wrote: I don't see the problem here. This example would throw RangeError at runtime instead of actually overwriting memory unless bounds checking is turned off. No, it doesn't. It's a complete, runnable example. You can try it at home. It does overwrite `foo`

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote: Actually, I'm not really interested in rendering much. From the original posts, the rendering time is most uninteresting cus it's the end of the pipeline, the time that I was commenting on at the start is the non-rendering time, which was

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Paolo Invernizzi via Digitalmars-d-announce
On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library really does want to corrupt memory they can just tag all their functions with @trusted, and unless someone looks at their code

Re: nogc v0.5.0 - DIP1008 works!

2019-05-27 Thread Atila Neves via Digitalmars-d-announce
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: On 24.05.19 18:19, Atila Neves wrote: On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote: [...] My `puts`s might not do any harm, but they could just as well be buffer overflows. Could you please give an example of how @system

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 May 2019 at 05:31:29 UTC, Manu wrote: How does the API's threadsafety mechanisms work? How does it scale to my 64-core PC? How does it schedule the work? etc... Ah yes, if you don't run the GUI on a single thread then you have a lot to take into account.

Re: D GUI Framework (responsive grid teaser)

2019-05-27 Thread Robert M. Münch via Digitalmars-d-announce
On 2019-05-27 04:46:42 +, Nick Sabalausky (Abscissa) said: Besides, from what Robert described, it sounds like he already has it decoupled and modular enough that performance *can* likely be improved later (probably by an order of magnitude) without too much disruption to it's core