Re: Let's celebrate Dlang on D day
It's still a good idea, however, to acknowledge the real D-Day veterans on any event on D-Day.
Re: Let's celebrate Dlang on D day
On 5/24/2019 9:00 PM, Mike Franklin wrote: 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. I'm sure you mean well, but I will be spending D-Day remembering the sacrifice of these men: https://en.wikipedia.org/wiki/Normandy_landings#/media/File:Normandy_American_Cemetery_and_Memorial,_June_2012.jpg Perhaps you could find a way to use the D language to honor them. I think it's alright. I was invited to teach a D seminar in Holland a few years back around Memorial Day. They were happy to conflate the two (it was their idea), and the Dutch revere the sacrifice of the Allies on D-Day. My father was a D-Day veteran, too, and I very much doubt he would have been offended by it. My Dutch friends were thrilled to find out my father was a vet, and they certainly would have shown him a good time had he come along. They even gave me some D-Day gifts. The D for D-Day thing was all in good fun all around. When I was a boy nobody cared my father was a vet. Everyone's dad was a vet. My neighbor next door was a paratrooper who'd lost his leg. My dad's best friend had his face burned off. It was kinda normal. But in his later years, people started to acknowledge the remaining veterans, and my father really enjoyed that. If you are lucky enough to know one, tell him thanks. You'll make his day.
Re: Let's celebrate Dlang on D day
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. I'm sure you mean well, but I will be spending D-Day remembering the sacrifice of these men: https://en.wikipedia.org/wiki/Normandy_landings#/media/File:Normandy_American_Cemetery_and_Memorial,_June_2012.jpg Perhaps you could find a way to use the D language to honor them. Mike
Let's celebrate Dlang on D day
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.
Re: D GUI Framework (responsive grid teaser)
Is the source available anywhere? Would be interesting to look through unless this is close source?
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote: I'd been holding off on announcing this until DIP1008 actually got implemented, and now it has: https://code.dlang.org/packages/nogc This dub package has a @nogc version of `std.conv.text` (which probably isn't as good yet) that, instead of returning a `string` returns an `automem.vector.Vector` of char. This handles managing memory allocation for the exception message itself in `NoGcException`, which does what it says on the tin. Confused? Here's some code: Ok, so exceptions don't rely on the GC anymore. That's super cool. However, they are still classes. So does that mean they also need RTTI (i.e. TypeInfo)? BetterC builds and some of use trying to use D in a pay-as-you-go fashion intentionally eliminate RTTI from the runtime. Is there any way we can take this a bit further to no longer require RTTI? Do exceptions even necessarily need to be classes? Thanks, Mike
Re: D GUI Framework (responsive grid teaser)
On Friday, 24 May 2019 at 19:32:38 UTC, Nick Sabalausky (Abscissa) wrote: Wow, you're just deliberately *trying* not to listen at this point, aren't you? Fine, forget it, then. I have no problem listening. As far as I can tell generic scenegraph frameworks like Inventor, Ogre (and I presume Horde) seem to have lost terrain in favour of more dedicated solutions.
Re: D GUI Framework (responsive grid teaser)
On 5/23/19 5:01 PM, Ola Fosheim Grøstad wrote: On Thursday, 23 May 2019 at 20:20:52 UTC, Nick Sabalausky (Abscissa) wrote: flexibility. And I think you're *SEVERELY* underestimating the flexibility of modern game engines. And I say this having personally used modern game engines. Have you? No, I don't use them. I read about how they are organized, but I have no need for the big gaming frameworks which seems to look very bloated, and frankly limiting. I am not really interested in big static photorealistic landscapes. Wow, you're just deliberately *trying* not to listen at this point, aren't you? Fine, forget it, then.
Re: D GUI Framework (responsive grid teaser)
On 25/05/2019 5:33 AM, Ola Fosheim Grøstad wrote: On Friday, 24 May 2019 at 17:19:23 UTC, rikki cattermole wrote: Be careful with that assumption. Server motherboards made by Intel come with GPU's as standard. Yes, they also have CPUs with FPGAs... And NVIDIA has embedded units with crazy architectures, like this entry level mode ($99?): https://developer.nvidia.com/embedded/buy/jetson-nano-devkit The stagnation of CPU capabilities had led to some interesting moves. Anyway, having a solid CPU renderer doesn't prevent one from using a GPU as well, if the architecture is right. Oh no, you found something that I want now.
Re: D GUI Framework (responsive grid teaser)
On Friday, 24 May 2019 at 17:19:23 UTC, rikki cattermole wrote: Be careful with that assumption. Server motherboards made by Intel come with GPU's as standard. Yes, they also have CPUs with FPGAs... And NVIDIA has embedded units with crazy architectures, like this entry level mode ($99?): https://developer.nvidia.com/embedded/buy/jetson-nano-devkit The stagnation of CPU capabilities had led to some interesting moves. Anyway, having a solid CPU renderer doesn't prevent one from using a GPU as well, if the architecture is right.
Re: D GUI Framework (responsive grid teaser)
On 25/05/2019 5:04 AM, Robert M. Münch wrote: On 2019-05-24 10:12:10 +, Ola Fosheim Grøstad said: I guess server rendering means that you can upgrade the software without touching the clients, so that you have a network protocol that transfers the graphics to a simple and cheap client-display. Like, for floor information in a building. Even much simpler use-cases make sense, example: Render 3D previews of 100.000 CAD models and keep them up to date when things change. You need some CLI tool to render it, but most likely you don't have OpenGL or a GPU on the server. Be careful with that assumption. Server motherboards made by Intel come with GPU's as standard.
Re: nogc v0.5.0 - DIP1008 works!
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.
That's right. If you are wrapping code that is provided by a
third party, you should not mark any code as @trusted that makes
calls to the third party library. By doing this, you are saying
"any third party code I call is memory safe (source: dude just
trust me)". That may work in the case where this third party code
is set in stone and has been hand-audited by either you or the
maintainers (ideally both), but you're accepting any
implementation through a template argument. Doing this is
extremely dangerous, because you're making memory safety promises
about every single Allocator implementation in existence, in the
present AND for the future.
What you have to do is leave the functions that make these calls
unmarked (no @system, @trusted OR @safe), and allow the compiler
to infer it based on the whether the third party implementation
is @system/@trusted/@safe. That's the only sane way I can think
of to do this.
Re: D GUI Framework (responsive grid teaser)
On 2019-05-24 10:12:10 +, Ola Fosheim Grøstad said: I guess server rendering means that you can upgrade the software without touching the clients, so that you have a network protocol that transfers the graphics to a simple and cheap client-display. Like, for floor information in a building. Even much simpler use-cases make sense, example: Render 3D previews of 100.000 CAD models and keep them up to date when things change. You need some CLI tool to render it, but most likely you don't have OpenGL or a GPU on the server. If running an app on a server and using an own front-end client instead of a browser these days makes sense, I'm not sure. However, all people have tremendous CPU power on their desks, which isn't used. So, I'm still favoring desktop apps, and a lot of users do it too. Be contrarian in this sector makes a lot of sense :-) You are probably right. What I find particularly annoying about GPUs is that the OS vendors keep changing and deprecating the APIs. Like Apple is no longer supporting OpenGL, IIRC. Yep, way too much hassles and possibilities to break things from external. Can become a support hell. Better to stay on your own as much as possible. Sadly, GPU features provide a short path to (forced) obsoletion… In the 2D realm I don't see so much gain using a GPU over using a CPU. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: nogc v0.5.0 - DIP1008 works!
On 24.05.19 18:51, ag0aep6g wrote: char[3] buf; [...] buf.ptr[i .. i + 3] = '!'; [...] UnsafeAllocator.instance.i = 8; /* greater than buf.length, whoops */ Actually, anything greater than zero is a whoops, of course.
Re: nogc v0.5.0 - DIP1008 works!
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.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote: On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote: Thanks for this. I think the only violation is calling `stringz` on `Z`, and that was due to a poorly designed DbI check on being able to call `stringz`. Allocating generally isn't @system, and freeing is ok to trust since vector is taking care of it for us. I've pushed a fix. I think you're missing the point. When your function is marked as @safe or @trusted, then any execution of a user-provided @system function is a safety violation. 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?
Re: D GUI Framework (responsive grid teaser)
On Friday, 24 May 2019 at 08:42:48 UTC, Robert M. Münch wrote: Currently we don't use a GPU, it's only CPU based. I think CPU rendering has its merits and is underestimated a lot. +1 One big bottleneck for CPU renderer is pixel upload, but apart from that it's pretty rad.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote: Thanks for this. I think the only violation is calling `stringz` on `Z`, and that was due to a poorly designed DbI check on being able to call `stringz`. Allocating generally isn't @system, and freeing is ok to trust since vector is taking care of it for us. I've pushed a fix. I think you're missing the point. When your function is marked as @safe or @trusted, then any execution of a user-provided @system function is a safety violation. My `puts`s might not do any harm, but they could just as well be buffer overflows.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 12:32:45 UTC, ag0aep6g wrote:
On 24.05.19 13:41, Atila Neves wrote:
[...]
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.stdc.stdio: puts;
struct S1
{
S2 s2;
this(ref const S1 src) const @nogc @system { this.s2 =
src.s2; }
}
struct S2
{
this(ref const S2 src) const @nogc @system { puts("@system
1"); }
}
struct Z
{
char* stringz() const @nogc @system
{
puts("@system 2");
return null;
}
}
struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
enum instance = UnsafeAllocator.init;
void deallocate(void[] bytes) @nogc @system
{
puts("@system 3");
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
puts("@system 4");
return Mallocator.instance.allocate(sz);
}
}
void main() @safe @nogc
{
import nogc: BUFFER_SIZE, text;
S1 a;
Z* z;
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(a, z);
}
All of the `puts` lines are executed. That should not be
possible in @safe code. You're applying @trusted too liberally.
Thanks for this. I think the only violation is calling `stringz`
on `Z`, and that was due to a poorly designed DbI check on being
able to call `stringz`. Allocating generally isn't @system, and
freeing is ok to trust since vector is taking care of it for us.
I've pushed a fix.
Re: nogc v0.5.0 - DIP1008 works!
On 24.05.19 13:41, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually got
implemented, and now it has:
https://code.dlang.org/packages/nogc
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.stdc.stdio: puts;
struct S1
{
S2 s2;
this(ref const S1 src) const @nogc @system { this.s2 = src.s2; }
}
struct S2
{
this(ref const S2 src) const @nogc @system { puts("@system 1"); }
}
struct Z
{
char* stringz() const @nogc @system
{
puts("@system 2");
return null;
}
}
struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
enum instance = UnsafeAllocator.init;
void deallocate(void[] bytes) @nogc @system
{
puts("@system 3");
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
puts("@system 4");
return Mallocator.instance.allocate(sz);
}
}
void main() @safe @nogc
{
import nogc: BUFFER_SIZE, text;
S1 a;
Z* z;
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(a, z);
}
All of the `puts` lines are executed. That should not be possible in
@safe code. You're applying @trusted too liberally.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote: I'd been holding off on announcing this until DIP1008 actually got implemented, and now it has: [...] Awesome!! Now we just need to get to compile Druntime and Phobos with -preview=dip1008, s.t. we can enable it by default :) See e.g. https://github.com/dlang/dmd/pull/8508
nogc v0.5.0 - DIP1008 works!
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that, instead of returning a `string`
returns an `automem.vector.Vector` of char. This handles managing
memory allocation for the exception message itself in
`NoGcException`, which does what it says on the tin. Confused?
Here's some code:
@safe @nogc unittest {
import nogc;
import std.algorithm: equal;
int a = 1, b = 2;
try
enforce(a == b, a, " was not equal to ", b);
catch(NoGcException e) {
assert(equal(e.msg, "1 was not equal to 2"));
}
try
throw new NoGcException(42, " foobar ", 33.3);
catch(NoGcException e) {
assert(equal(e.msg, "42 foobar 33.30"));
assert(e.file == __FILE__);
assert(e.line == __LINE__ - 4);
}
}
It doesn't leak memory either, as proved by ldc's asan.
Re: D GUI Framework (responsive grid teaser)
On Friday, 24 May 2019 at 08:42:48 UTC, Robert M. Münch wrote: Well, the main market I see for a software renderer is the embedded market and server rendering. Making money with development tools, components or frameworks is most likely only possible in the B2B sector. Indeed. Software that should be easy to port to new hardware, like point-of-sale terminals, calling systems etc. I guess server rendering means that you can upgrade the software without touching the clients, so that you have a network protocol that transfers the graphics to a simple and cheap client-display. Like, for floor information in a building. Or do you plan on support CPUs where there is no GPU available? Currently we don't use a GPU, it's only CPU based. I think CPU rendering has its merits and is underestimated a lot. You are probably right. What I find particularly annoying about GPUs is that the OS vendors keep changing and deprecating the APIs. Like Apple is no longer supporting OpenGL, IIRC. Sadly, GPU features provide a short path to (forced) obsoletion…
Re: D GUI Framework (responsive grid teaser)
On Friday, 24 May 2019 at 08:35:27 UTC, Robert M. Münch wrote: I'm not fully understand the discussion about accuracy WRT GUIs. Of course you need to draw things accurate. And my interjection WRT 35-FPS was just to give an idea about the possible achievable performance. I like desktop apps that are fast and small, nothing more. Yes. What I meant is that it is better for an application developer to have a GUI framework that is predictable and solid than to have the highest possible performance. So if someone provides a drawing canvas then I'd rather have correctly drawn anti-aliased primitives (like bezier curves) than something that is 20% faster but incorrect. Just an example. Just in general, predictable, less to worry about, so that the application developer can focus on the application and not the peculiarities of the GUI framework. care if you wish). For this we are creating a set of building-blocks that fit perfectly together following a radical KISS and minimal dependency strategy. Sounds reasonable.
Re: D GUI Framework (responsive grid teaser)
On 2019-05-23 17:27:09 +, Ola Fosheim Grøstad said: Yeah, that leaves a lot of headroom to play with. Do you think there is a market for a x86 CPU software renderer though? Well, the main market I see for a software renderer is the embedded market and server rendering. Making money with development tools, components or frameworks is most likely only possible in the B2B sector. One needs to find a niche where companies are interested in: speed and ressource-efficency is definetely one. Or do you plan on support CPUs where there is no GPU available? Currently we don't use a GPU, it's only CPU based. I think CPU rendering has its merits and is underestimated a lot. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D GUI Framework (responsive grid teaser)
On 2019-05-23 20:22:28 +, Ola Fosheim Grøstad said: STILL, I think Robert M. Münch is onto something good if he aims for accuracy and provides say a canvas that draws bezier curves to the spec (whether it is PDF or SVG). I think many niche application areas involve accuracy, like a CNC router program, or a logo cutter or 3D printing. So I think there is a market. I'm not fully understand the discussion about accuracy WRT GUIs. Of course you need to draw things accurate. And my interjection WRT 35-FPS was just to give an idea about the possible achievable performance. I like desktop apps that are fast and small, nothing more. If you can provide everything people need in one framework, then people might want to pay for it. If you just provide what everyone else sloppily does, then why bother (just use Gtk, Qt or electron instead). *shrug* Exactly. Our goals is to create a GUI framework which you can use to make desktop apps without caring about the OS specifics (which doesn't mean we are limiting in a way that you can't care if you wish). For this we are creating a set of building-blocks that fit perfectly together following a radical KISS and minimal dependency strategy. If you want, you should be able to maintain a desktop app using a specific version of the framework for 15+ years, without running into any limitations. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D GUI Framework (responsive grid teaser)
On 2019-05-23 19:29:26 +, Ola Fosheim Grøstad said: When creating a user interface framework you should work with everything from sound editors, oscilloscopes, image editors, vector editors, CAD programs, spreadsheets etc. You cannot really assume much about anything. What you want is max flexibility. That's exactly the right direction. Most GUI frameworks fail at this, so you have to do all yourself if you want anything with descent quality, but that is not how it should be. Yep, I can't agree more. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
