Re: D GUI Framework (responsive grid teaser)

[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...


Even embedded parts have many cores; look at every mobile 
processor.


Usually limited. Correctness is more difficult to prove with high 
levels of parallelism... And you can use FPGA...


Multi-core focused software tends to perform better on 
single-core

setups than software that was written for single-core in my
experience.


That is odd. Parallell algorithms usually comes with overhead.

At the time,

we
worried about how the super-scalar choices we were making would 
affect

Gamecube which still had just one core.


You meant parallell? (super scalar just means that a single core 
has multiple execution units, a single core can schedule multiple 
instructions at the same time)



If you write a
single-threaded app, you are almost 100% guaranteed to blatantly
disregard software engineering in favour of a laser focus on 
your API
and user experience, and you will write bad software as a 
result.


Well, if you need more than a single thread to update a gui (sans 
rendering) then you've picked the wrong layout strategy in my 
opinion.


I dont want the gui to suck up a lot of cpu time and polute the 
caches.


And yes I think layout engine API as well as styling are very 
important to do well, even if it incurs overhead.


I'd rather have simple layout if that is the bottle neck...

Layout engine design a styling engine design is really the 
biggest challenge. You cannot design the architecture before 
those two are known.  Also embedded have fixed screen 
dimensions... No need for real time resizing...


What is missing is a good detailed description of primary use 
scenarios. Without that no rational design decisions can be made.


That is software engineering 101.

Without that we will just talk past eachother making different 
assumptions.


What is certain is that the long page browser layout engine isn't 
very well suited for fixed dimensions...

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

[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

[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

because of issues with 16 byte stack alignment.

This means that generated code will no longer work on older x86 
processors that
do not have XMM registers. If this is an issue, please file a 
bug report.


https://github.com/dlang/dmd/pull/9895

DMD always had that capability, it just wasn't enabled for 
backwards compatibility with older processors.


Thanks a lot. I expect it resolves some ancient issues I had with 
math functions when compiled with DMD.


Does DMD still use x87 for float/double on other targets?

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

[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 generated code will no longer work on older x86 processors that
do not have XMM registers. If this is an issue, please file a bug report.

https://github.com/dlang/dmd/pull/9895

DMD always had that capability, it just wasn't enabled for backwards 
compatibility with older processors.

Re: Let's celebrate Dlang on D day

[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)

[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.
>
> If Robert is aiming for embedded and server rendering then he
> probably wants a simple structure with limited multi-threading.

Huh? Servers take loads-of-cores as far as you possibly can! Zen2
parts announced the other day, they'll give our servers something like
256 threads!

Even embedded parts have many cores; look at every mobile processor.
But here's the best part; if you design your software to run well on
computers... it does!
Multi-core focused software tends to perform better on single-core
setups than software that was written for single-core in my
experience.
My most surprising example was when we rebooted our engine in 2005 for
XBox360 and PS3 because we needed to fill 6-8 cores with work and our
PS2 era architecture did not do that effectively. At the time, we
worried about how the super-scalar choices we were making would affect
Gamecube which still had just one core. It was a minor platform so we
thought we'd just wear the loss to minimise tech baggage... boy were
we wrong! Right out of the gate, our scalability-focused architecture
ran better on the single-core machines than the previous highly mature
code that had received years of optimisation. It looked like there
were more moving parts in the architecture, but it still ran
meaningfully faster.
The key reason was proper partitioning of work. If you write a
single-threaded app, you are almost 100% guaranteed to blatantly
disregard software engineering in favour of a laser focus on your API
and user experience, and you will write bad software as a result.
Every time.

Re: D GUI Framework (responsive grid teaser)

[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 limited multi-threading.


*shrug*

Re: D GUI Framework (responsive grid teaser)

[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 run the GUI on a single thread then you have
> a lot to take into account.

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: Let's celebrate Dlang on D day

[Walter Bright via Digitalmars-d-announce]

This is getting way off topic, guys.

Re: nogc v0.5.0 - DIP1008 works!

[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 
user-provided types are involved is extra hard, because you can't even 
trust fundamental operations like assignment or copying.


Please note that the allocator stuff is just one of the three violations 
I had pointed out. You've already pushed a fix for the unsafe .stringz, 
but you haven't addressed unsafe copy constructors yet.


And my list wasn't meant to be complete. There may be other safety holes 
I didn't notice.

Re: nogc v0.5.0 - DIP1008 works!

[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 allocator to be @safe?


For @safe allocators, Vector can be @safe.

For specific @system allocators, like Mallocator, you can make 
special @trusted cases in Vector.


For generic @system allocators, Vector cannot be @safe (or 
@trusted).


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.


I'd be nice if I could detect at compile-time that it's not just 
Mallocator but an allocator that's built using it as well (e.g. 
FallBackAllocator).

Re: Let's celebrate Dlang on D day

[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 it,


It is hard to tell. IKEA is a foundation, it's creator insists 
that it is real, others might say that it is so for taxation 
reasons. Certainly for profit, yet has some social profile by not 
being "snobbish".


Here in Norway the COOP has become quite big over the years, but 
they are very much for profit, although are technically owned by 
their customers.


In the US you have FSF though, which totally changed the software 
industry in the 90s with the GPL. Granted BSD has since then 
gained ground, but I don't think that would have happened without 
the GPL to the same extent. I think the GPL created some sort of 
competition for attention in the software sector? GCC also 
totally undercut commercial compilers…


Kinda funny. (Unless you are a compiler publisher…)


the US: Anything that doesn't directly facilitate "money is 
power, might makes right" just gets labeled "communist" or 
"socialist" and rejected outright by the nationalist rednecks 
we've been overrun by ever since 9/11. (Go figure, they attack


Well, there was a lot of brainwashing on both sides during the 
cold war (until to 1990). It takes time for it to fade away, 
although the younger US generation that I see in youtube comment 
fields appears to be openminded?



had. Figures, coming from the same fine folks who brought the 
world such hits as "Puritanism", "Witch Trials" and "Shorten a


I think our situation is better when smaller parties get a say. 
When there is two big parties that switch roles then they become 
too smug, when a big party has to beg a small party for support 
then they become more humble…


But I guess parliamentarism would be difficult to establish in 
the US as the constitution seems to be revered by many as holy.

Re: Let's celebrate Dlang on D day

[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 people into our 
community. I will try to give some talks at universities in 
order to get the attention of the people. I suggest you all do 
similar stuff. In the Dlang facebook group 
https://www.facebook.com/groups/662119670846705/ which has 
already reached 135 members, we will be doing lots of fun 
stuff. Please show up and join the group to participate. I will 
try to turn this into an actual holiday. I hope you can all 
help me out.


I dont think it's a good idea. One of mine grandpa served in the 
french Marine when they destroyed the ships at Toulon. The other 
went from algeria, from a spanish colony, to here...

This D day idea is completly stupid.

Re: nogc v0.5.0 - DIP1008 works!

[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 @safe.

For specific @system allocators, like Mallocator, you can make special 
@trusted cases in Vector.


For generic @system allocators, Vector cannot be @safe (or @trusted).

Re: nogc v0.5.0 - DIP1008 works!

[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 really does 
want to corrupt memory they can just tag all their functions 
with @trusted, and unless someone looks at their code nobody 
will be the wiser.


... and a @safe conscious programmer will not touch that 
library ever with a 5 five meters pole.


I'm still not convinced that trusted code should accept 
generic system code ... can you elaborate more?


I'm not convinced either - I'm having a dialogue to figure out 
potential issues.


:-)

My nice-try to reduce the problem is: trusted code block needs to 
by "manually verified" for safety by humans, so it should be 
"@safe pure", aka, if you can't perform the analysis looking only 
at the statements in the trusted block, that can't be marked 
trusted.

Re: nogc v0.5.0 - DIP1008 works!

[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 example. You can try 
it at home. It does overwrite `foo` and `bar`. It does not 
throw a RangeError.


You're right - I should have run it first.

Yes, you can use @trusted to use Mallocator safely. And your 
code (probably) does that. But the allocator in my example 
isn't Mallocator, it's UnsafeAllocator. Your code doesn't use 
that one safely.


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?


In this thread, you're the author of that 3rd party library. 
You've got the bad @trusted functions that lead to memory 
corruption. I'm the guy who looked at it, noticed the problem, 
and tells you.


Thanks for bringing it up.

Re: nogc v0.5.0 - DIP1008 works!

[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 functions 
with @trusted, and unless someone looks at their code nobody 
will be the wiser.


... and a @safe conscious programmer will not touch that 
library ever with a 5 five meters pole.


I'm still not convinced that trusted code should accept generic 
system code ... can you elaborate more?


I'm not convinced either - I'm having a dialogue to figure out 
potential issues.

Re: nogc v0.5.0 - DIP1008 works!

[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` and `bar`. It does not throw a RangeError.


The other issue is that Mallocator has a @safe allocate function and a 
@system deallocate function since it's up to the user of the interface 
to supply a slice that was actually malloc'ed. It's clear that this 
interface is one that can be used @safely (and is by 
automem.vector.Vector). Likewise, reallocating is @system because there 
might be references to the old pointer, but it makes sense that a 
@trusted block could exist where the reviewer makes sure that there's 
only ever one reference to the allocated memory.


Yes, you can use @trusted to use Mallocator safely. And your code 
(probably) does that. But the allocator in my example isn't Mallocator, 
it's UnsafeAllocator. Your code doesn't use that one safely.


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 nobody will be the wiser.


In this thread, you're the author of that 3rd party library. You've got 
the bad @trusted functions that lead to memory corruption. I'm the guy 
who looked at it, noticed the problem, and tells you.

Re: D GUI Framework (responsive grid teaser)

[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 substantial.


Btw, I agree that spatial constraint solvers are tricky… it is a 
rather specialized field with very specialized algorithms…


…but as Robert said CSS Flex then we know that there are free 
implementations out there that perform very well (Chromium, 
Firefox, etc).


I don't know how useful Flex is for UI layout though, based on my 
experience with browser layout. But I guess that is something one 
will have to experiment with.

Re: nogc v0.5.0 - DIP1008 works!

[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 nobody 
will be the wiser.


... and a @safe conscious programmer will not touch that library 
ever with a 5 five meters pole.


I'm still not convinced that trusted code should accept generic 
system code ... can you elaborate more?


Thanks,
Paolo

Re: nogc v0.5.0 - DIP1008 works!

[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 allocator code 
could do that?


Sure. You just write beyond some buffer instead of calling 
`puts`:



char[3] buf;
char[3] foo = "foo";
char[3] bar = "bar";

struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
static instance = UnsafeAllocator.init;
size_t i;
void deallocate(void[] bytes) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
return Mallocator.instance.allocate(sz);
}
}

void main() @safe @nogc
{
{
import nogc: BUFFER_SIZE, text;
UnsafeAllocator.instance.i = 8;
/* greater than buf.length, whoops */
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(42);
assert(foo == "foo"); /* fails */
UnsafeAllocator.instance.i = 16;
/* also greater than buf.length, whoops again */
}
assert(bar == "bar"); /* fails */
}


You just can't trust user-provided @system code. It doesn't 
matter if it's allocator code or whatever.


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.


The other issue is that Mallocator has a @safe allocate function 
and a @system deallocate function since it's up to the user of 
the interface to supply a slice that was actually malloc'ed. It's 
clear that this interface is one that can be used @safely (and is 
by automem.vector.Vector). Likewise, reallocating is @system 
because there might be references to the old pointer, but it 
makes sense that a @trusted block could exist where the reviewer 
makes sure that there's only ever one reference to the allocated 
memory.


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 nobody will be 
the wiser.

Re: D GUI Framework (responsive grid teaser)

[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)

[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 design. So, on that, believe it or not, it sounds like we 
already agree. ;)


That's the case. The 2D layer could be replaced. It's not yet perfectly 
isolated and minified, because we are still learning & experimenting to 
see how things fit together. Refactoring for isolation comes after this.



And @Robert: FWIW, I *am* definitely curious to see where this project goes.


We too :-)

Also: While it *looks* in the video like a simple grid being resized, 
you've commented that under-the-hood it's really more of a flexbox-like 
design.


Correct.

The grid is structured like this: root-> 1..X columns -> 1..Y cells per 
column and the only property given is to use the available vertical and 
horizontal space evenly.


This suggests that the computations you're doing are (or will be) 
capable of far more flexibility than what is apparent in the video.


Yes, the idea is that you get a responsive app GUI, which resizes in a 
smart way which fits your app layout. So, you have control over this. 
Getting browsers to do what you want can be pretty tedious. We want to 
avoid this.


I'm curious what sorts of CSS flex-like features are currently being 
accommodated for in the computations, and are projected in the 
(hopefully?) near future?


The stuff that one really needs, so no frills. We want to create a node 
structure with layout rules/hints per node and as a result you get a 
perfect responsive layout for your app.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster