Re: Printing shortest decimal form of floating point number with Mir

On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad wrote: On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote: I suppose the answer would be that D doesn't pretend to support all C++ template features an

Re: Printing shortest decimal form of floating point number with Mir

On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad wrote: On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote: I suppose the answer would be that D doesn't pretend to support all C++ template features and the bug is not a bug because we live with this somehow for years. But it is

Re: Printing shortest decimal form of floating point number with Mir

On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. This is just silly. You don't have to accept a specific solution... ...but... YOU DO HAVE TO ACKNOWL

Re: Our community seems to have grown, so many people are joining the Facebook group

On Wednesday, 30 December 2020 at 02:31:36 UTC, Murilo wrote: On Tuesday, 29 December 2020 at 15:06:07 UTC, Ola Fosheim Grøstad wrote: No, the OP clearly stated that he made the group "official". That is a deliberate attempt to fracture. I'm sorry you see it like this but my i

Re: Printing shortest decimal form of floating point number with Mir

On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote: On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all co

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 15:36:47 UTC, Guillaume Piolat wrote: I see what you are saying, but that is a "controlling" position to hold. Once a language break into the mainstream, there is no way to control the community. Any attempt to contain the community to this or that medium is th

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 15:16:24 UTC, Adam D. Ruppe wrote: On Tuesday, 29 December 2020 at 15:06:07 UTC, Ola Fosheim Grøstad wrote: hostile ad hominem tone [...] deliberate attempt to fracture. tu quoque. Let's not assume any motives here. I wouldn't call it "offici

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 14:53:43 UTC, Guillaume Piolat wrote: On Tuesday, 29 December 2020 at 11:34:38 UTC, Ola Fosheim Grøstad wrote: Sorry but I don't think you get it. So, this hostile ad hominem tone is why it is beneficial with local groups... I've studied online commu

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 13:04:42 UTC, Tobias Pankrath wrote: You have a valid point, but still I am sure the facebook group is a net positive for the community. I'd see it as a digital version of a local user group. It certainly has some benefits, especially in the past when there was

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 11:34:38 UTC, Ola Fosheim Grøstad wrote: For instance slashdot is very poor in social boding terms, but much better than the dlang forums for aggregating helpful advice. So the "learn" forum is beneficial socially, but does erode the slashdo

Re: Our community seems to have grown, so many people are joining the Facebook group

On Tuesday, 29 December 2020 at 10:52:53 UTC, Guillaume Piolat wrote: On Tuesday, 29 December 2020 at 09:05:45 UTC, aberba wrote: So I'm sure the Facebook group will appeal to a certain audience who use Facebook. I've been a part of all sorts of Facebook groups related to my stack and I've co

Re: Printing shortest decimal form of floating point number with Mir

On Thursday, 24 December 2020 at 15:00:16 UTC, jmh530 wrote: That Foo-ish reminds me of something in D like static if (__traits(compiles, { auto temp = Foo!T.init; })) Yes, it is similar in spirit. It is pretty much the same as the C++17 version, but easier to write, especiall

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote: concept Bar(T) = requires(U)() { Foo!U; //akin to something like typename T::Foo; } where we would basically be telling the compiler that T has to be a Foo!U, which would mean you would have to use Bar like Bar!U...at least that'

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote: doing similar things). Abusing C++'s syntax you might have something like concept Bar(T) = requires(U)() { Foo!U; //akin to something like typename T::Foo; } where we would basically be telling the compiler that T has to be a Foo

Re: Printing shortest decimal form of floating point number with Mir

The big picture that the DIP suggested was that when stuff like this fails to compile: struct Foo(T) {} alias Bar(T) = Foo!T; void f(T)(Bar!T x) {} void main() { auto foo = Bar!int(); f(foo); } Then most programmers would just conclude that the compiler is broken beyond re

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 21:47:32 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 23 December 2020 at 21:37:11 UTC, Ola Fosheim Grøstad wrote: foo.f; foo.b; bar.f; bar.b; } argh, forget that... I am tired... Sorry. template struct Foo { }; template using Bar = Foo

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 21:37:11 UTC, Ola Fosheim Grøstad wrote: foo.f; foo.b; bar.f; bar.b; } argh, forget that... I am tired... Sorry.

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote: On Wednesday, 23 December 2020 at 16:25:58 UTC, 9il wrote: [snip] 1. Alias template function parameter resolution https://github.com/dlang/dmd/pull/9778 [snip] I gave some thought to potential alternatives, but this is really the

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 19:49:44 UTC, aberba wrote: None of which seems to me we're making it easy for people without time of their hands to make contribution. Spending hours-days writing a DIP or pull request that doesn't get the attention it deserves can be very demoralizing (underv

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 18:38:01 UTC, 9il wrote: Or that was just a very good mockery. But as was said that doesn't really matter for the result we have. True. Other languages try to iron out perceived flaws. I am quite impressed by how C++ has managed to move, even though it is stuc

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: Have you read the DMD PR thread (not the DIP itself)? It was a mockery executed by Atila accompanied by silent Walter's and Andrei's ignoring. I am not sure if I read the same one, I didn't perceive it as mockery. Atila seemed to im

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote: https://issues.dlang.org/show_bug.cgi?id=16486 https://issues.dlang.org/show_bug.cgi?id=16465 https://issues.dlang.org/show_bug.cgi?id=10884 and the oldest one reported in 2008 https://issues.dlang.org/show_bug.cgi?id=1807 C++ templates

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 16:20:37 UTC, Timon Gehr wrote: On 23.12.20 16:37, Ola Fosheim Grøstad wrote: On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote: You, Andrey, and Atila don't care about language features that have been requested for Mir or even more: rejectin

Re: Printing shortest decimal form of floating point number with Mir

On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote: You, Andrey, and Atila don't care about language features that have been requested for Mir or even more: rejecting DIP draft + DMD partial implementation for no real reason. Out of curiosity, which language features would improve Mir?

Re: New language based on D

On Thursday, 12 November 2020 at 19:00:51 UTC, bachmeier wrote: On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote: Maybe these type of subset languages could be integrated in the D frontpage. I hope not. That would create lots of problems: - There are multiple versions of the la

Re: Symmetry Investments and the D Language Foundation are Hiring

On Tuesday, 1 September 2020 at 11:53:25 UTC, Ola Fosheim Grøstad wrote: you scale things up, but there are fast noncryptographic hashes. Some are like 10-500x faster than SHA1: More like 10-50x...

Re: Symmetry Investments and the D Language Foundation are Hiring

On Monday, 31 August 2020 at 21:24:53 UTC, starcanopy wrote: I think the majority opinion is that sha1 is fine for non-security purposes like monitoring files for changes to obviate superfluous work in a build system; Not a big fan of using hashes, since collisions do arise when you scale thi

Re: DIP 1024---Shared Atomics---Accepted

On Wednesday, 8 January 2020 at 02:31:24 UTC, Manu wrote: On Wed, Jan 8, 2020 at 12:20 PM Walter Bright via Digitalmars-d-announce wrote: It will still do that, either now... or later. So, why wait? Since @safe and shared is all syntactical in nature then all these problems can be avoided b

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 17:19:11 UTC, Adam D. Ruppe wrote: You could conceivably write a child class that wraps or converts. For example, perhaps: class Serializer { void serialize(Serializable s) {} } class ExtendedSerializer: Serializer { override void serialize(Object o) {

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 16:03:18 UTC, Ola Fosheim Grøstad wrote: comes to virtual function parameters. Then again, I think overriding the implementation of the subclass is kinda ugly. That made no sense, I meant superclass...

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 15:25:19 UTC, Adam D. Ruppe wrote: On the parameters side it is a little more confusing, but it still makes sense: abstract class Generic { void generic(Generic g); } class Specialized : Generic { override void generic(Specialized g) {} } But this doesn

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 15:12:46 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 3 December 2019 at 14:51:58 UTC, Adam D. Ruppe wrote: Maybe, but it is pretty sound once you get to know it. You mean contracts? Yes. But I was thinking of contravariant/covariant parameters on virtual

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 14:51:58 UTC, Adam D. Ruppe wrote: Maybe, but it is pretty sound once you get to know it. You mean contracts? Yes. But I was thinking of contravariant/covariant parameters on virtual functions. Doesn't work with overloading though, so D only has it on return typ

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 14:40:21 UTC, Adam D. Ruppe wrote: h geeze I was so focused on inheriting the contract that I didn't even test if it didn't have one at all. So we need a Maybe also test with D interfaces? I suppose they have the same behaviour as superclasses? Anyway, I th

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 10:39:08 UTC, Robert M. Münch wrote: In large scale projects this will become a big problem as you can't assume that every developer knows about all the contracts of a superclass. Yes, like if you just want to constrain a signed int to be >=1. If you forget to a

Re: interfaces and contracts - new pattern

On Tuesday, 3 December 2019 at 02:57:13 UTC, Adam D. Ruppe wrote: On Monday, 2 December 2019 at 22:31:08 UTC, Ola Fosheim Grøstad wrote: Interesting, could be useful, but now you have to remember to add "in(false)". Yeah, it is kinda tempting to propose a language change, where a

Re: interfaces and contracts - new pattern

On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. Interesting, could be

Re: Proposal for porting D runtime to WebAssembly

On Monday, 25 November 2019 at 13:52:29 UTC, Sebastiaan Koppe wrote: You don't have to wait for that. That future is already here. The in and output could also be distributed storage, event streams or some queue. Yes, I am most familiar with Google Cloud. Earlier this year Google Functions wa

Re: Proposal for porting D runtime to WebAssembly

On Monday, 25 November 2019 at 12:52:46 UTC, Sebastiaan Koppe wrote: As an example, it is just a matter of time before a PaaS provider fully embraces wasm. This sounds interesting, I've been pondering about serverless FaaS (function as a service), where you basically (hopefully) get functions

Re: Proposal for porting D runtime to WebAssembly

On Saturday, 23 November 2019 at 23:21:49 UTC, Nick Sabalausky (Abscissa) wrote: On 11/23/19 3:48 PM, Sebastiaan Koppe wrote: years, but never got the impression anyone else cared. The fact that C# has had them for eons and D still seems to have no interest in coroutines that *don't* involve th

Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment

On Monday, 28 October 2019 at 19:23:30 UTC, jmh530 wrote: they are all const. That there is only one mutable way to access data sounds like restrict to me. Well, if you add the constraint that there also is no const way to access the data. But unique ownership is stricter than «restrict», wh

Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment

On Monday, 28 October 2019 at 21:53:50 UTC, Walter Bright wrote: I've always known it was a bad idea (not just me, it was common knowledge). People have a hard time understanding restrict, and are guaranteed to use it wrong. Let alone errors using it from people who do understand it. Compiler

Re: DConf 2019 Videos

On Thursday, 13 June 2019 at 10:18:47 UTC, Bastiaan Veelo wrote: Which talk? Kai Nacke's: https://youtu.be/PJpGySqFm2U?t=562 Believe this is the repo: https://github.com/funkwerk/antlr-d

Re: DConf 2019 Videos

On Saturday, 8 June 2019 at 07:32:35 UTC, Mike Parker wrote: Everything is now online. I updated the DConf site with the links for Days 1 & 2 yesterday and will add the Day 3 links shortly. Now that the videos are all online, I'll be posting a recap of DConf on the blog before the weekend is ou

Re: D GUI Framework (responsive grid teaser)

On Wednesday, 29 May 2019 at 05:56:45 UTC, Nick Sabalausky (Abscissa) wrote: I think I still have a stack of floppies from an early version of MS Visual C/C++. Plus similar floppy stacks from other 90's compilers[1] But 31 install disks is quite impressive, I'm not sure I can match that[2]. I t

Re: D GUI Framework (responsive grid teaser)

On Tuesday, 28 May 2019 at 07:22:06 UTC, Ola Fosheim Grøstad wrote: Just be aware that implementing a multithreaded constraint solver is something that you will have to spend a lot of time on. Btw, Apple is using a version of Cassowary. There are many implementations available: http

Re: D GUI Framework (responsive grid teaser)

On Tuesday, 28 May 2019 at 07:33:39 UTC, dayllenger wrote: You can change the element dimensions programmatically - directly or via styling, maybe with transition effects. They can be dependent on each other or on the parent/sibling dimensions. In all these cases, the computations layout engine

Re: D GUI Framework (responsive grid teaser)

On Tuesday, 28 May 2019 at 06:37:47 UTC, Robert M. Münch wrote: We are considering MT. A GUI should never stuck, as a user I'm the most important part and my time is most valuable. So, an application should never ever slow me down. Just be aware that implementing a multithreaded constraint sol

Re: D GUI Framework (responsive grid teaser)

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

Re: D GUI Framework (responsive grid teaser)

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 l

Re: Let's celebrate Dlang on D day

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: D GUI Framework (responsive grid teaser)

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 subs

Re: D GUI Framework (responsive grid teaser)

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)

On Monday, 27 May 2019 at 05:01:36 UTC, Manu wrote: Performance is a symptom of architecture, and architecture *is* the early stage. I expected that answer, but the renderer itself can just be a placeholder. So yes, you need to think about where accelerating datastructures/processes fit in.

Re: D GUI Framework (responsive grid teaser)

On Monday, 27 May 2019 at 04:46:42 UTC, Nick Sabalausky (Abscissa) wrote: without too much disruption to it's core design. So, on that, believe it or not, it sounds like we already agree. ;) Alright! :-) And I'll point out *again*, the only points I was trying to make here were to dispel the

Re: D GUI Framework (responsive grid teaser)

On Monday, 27 May 2019 at 03:35:48 UTC, Nick Sabalausky (Abscissa) wrote: suggestion that Robert could get this going an order of magnitude faster without too terribly much trouble. Luckily, Ethan explained my stance better than I was able to. I think you guys overestimate the importance of pe

Re: D GUI Framework (responsive grid teaser)

On Monday, 27 May 2019 at 01:52:05 UTC, Manu wrote: I don't insist, I was just inviting him to the chat channel where a similar effort is already ongoing, and where there are perf experts who can help. Yes, sure, is always a good thing to hash out ideas with others who have an interest in the

Re: D GUI Framework (responsive grid teaser)

On Monday, 27 May 2019 at 00:33:45 UTC, Nick Sabalausky (Abscissa) wrote: flat-out wrong) to say about game programming. People hear the word "game", associate it with "insignificant" and promptly shut their brains off. Not insignificant, but also not necessarily relevant for the project in t

Re: Let's celebrate Dlang on D day

On Monday, 27 May 2019 at 00:56:50 UTC, Nick Sabalausky (Abscissa) wrote: in defense against the benign. So congrats those pretending to be anti-Nazi while utilizing that to build the NEXT new fundamentalist regime. I have to admit that I do use gmail, but I wonder if it is healthy that NSA h

Re: Let's celebrate Dlang on D day

On Monday, 27 May 2019 at 00:12:51 UTC, Nick Sabalausky (Abscissa) wrote: Don't know about Europe, but here in the US, an unfortunate part of the basic culture is that people tend to spend their entire lives here going around LOOKING for reasons to be offended, and by golly, they WILL be CERTAI

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 18:37:49 UTC, Ola Fosheim Grøstad wrote: On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote: AFAIK Ganesh sucked and it was dropped. They use nv path rendering now. https://developer.nvidia.com/nv-path-rendering Ah, do you know if this is in Chromium as well, or is

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 17:41:01 UTC, NaN wrote: On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote: On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce wrote: What? ... this thread is bizarre. Why would a high quality SVG renderer decide to limit to 16x AA? Are you suggesting

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote: AFAIK Ganesh sucked and it was dropped. They use nv path rendering now. https://developer.nvidia.com/nv-path-rendering Ah, do you know if this is in Chromium as well, or is it something that is closed off to Chrome? I also noticed that the

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 16:56:39 UTC, Ola Fosheim Grøstad wrote: If the SVG renderer in the browser is relevant? Depends. SVG is animated through CSS, so the browser must be able to redraw on every frame. For some interfaces it certainly would be relevant, but I don't think Robert is a

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote: How is the web browser's SVG renderer even relevant? I have absolutely no idea how this 'example' (or almost anything in this thread) could be tied to the point I made way back at the start before it went way off the rails. Just stop, it's kil

Re: D GUI Framework (responsive grid teaser)

On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote: Oh, hey, wait a minute, Nick's dcompute could be exactly what you're want if you're only doing this to show a UI framework FWIW, OpenCL is deprecated on OS-X. You should use Metal for everything. GPU-APIs are not very future proof.

Re: D GUI Framework (responsive grid teaser)

On Sunday, 26 May 2019 at 11:09:52 UTC, NaN wrote: Chrome is still doing path rendering on the CPU for me. (I did make sure that the "use hardware acceleration when available" flag was set in the advanced settings.) *nods* Switching hardware acceleration on/off has very little impact on my ma

Re: D GUI Framework (responsive grid teaser)

On Saturday, 25 May 2019 at 23:23:31 UTC, Ethan wrote: But you shouldn't design a UI framework like a game engine. Wrong. Game engines excel at laying out high-fidelity data in sync with a monitor's default refresh rate. You are confusing rendering engine with UI API. A game engine is des

Re: D GUI Framework (responsive grid teaser)

On Saturday, 25 May 2019 at 19:35:35 UTC, user1234 wrote: Maybe at the beginning everybody will be happy but at the end people would start using slower scripting languages, less optimized, or more simply would use those existing to achieve more complex tasks and after a while the situation we k

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 Ho

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?): ht

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 s

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

Re: D GUI Framework (responsive grid teaser)

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 or

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 20:13:29 UTC, Nick Sabalausky (Abscissa) wrote: They want accuracy TO THE EXTENT THEY (and others) CAN PERCEIVE IT. That is the key. Human perception is far more limited than most people realize. Well, what I meant by "cutting corners" it that games reach efficienc

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 19:32:28 UTC, Nick Sabalausky (Abscissa) wrote: Game engines *MUST* be *EFFICIENT* in order facilitate the demands the games place on them. And "efficiency" *means* efficiency: it means minimizing wasted processing, and that *inherently* means *both* speed and batter

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 19:29:26 UTC, Ola Fosheim Grøstad wrote: 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. I meant «decent»! *grin* (But really, photographers and videographers use RAW

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 19:13:11 UTC, Nick Sabalausky (Abscissa) wrote: Serious photographers and videographers use things like JPEG and MPEG which are *fundamentally based* on cutting imperceptible corners and trading accuracy for other benefits. The idea of a desktop GUI absolutely requir

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 16:36:17 UTC, Robert M. Münch wrote: When doing the real-time resizing in the screencast, the CPU usage is around 5% - 6% Yeah, that leaves a lot of headroom to play with. Do you think there is a market for a x86 CPU software renderer though? Or do you plan on sup

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 01:22:20 UTC, Manu wrote: That's a different discussion. I don't actually endorse this. I'm a fan of instantaneous response from my productivity software... 'Instantaneous' being key, and running without delay means NOT waiting many cycles of the event pump to flow

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote: On 2019-05-22 17:01:39 +, Manu said: I mean, there are video games that render a complete screen full of zillions of high-detail things every frame! Show me a game that renders this with a CPU only approach into a memory buf

Re: D GUI Framework (responsive grid teaser)

On Thursday, 23 May 2019 at 00:23:50 UTC, Manu wrote: it's really just a style of software design that lends to efficiency. Our servers don't draw anything! Then it isn't specific to games, or particularly relevant to rendering. Might as well talk about people writing search engines or machin

Re: D GUI Framework (responsive grid teaser)

On Wednesday, 22 May 2019 at 21:18:58 UTC, Manu wrote: I couldn't possibly agree less; I think cool kids would design literally all computer software like a game engine, if they generally cared about fluid experience, perf, and battery life. A game engine is designed for full redraw on every

Re: D GUI Framework (responsive grid teaser)

On Wednesday, 22 May 2019 at 17:01:39 UTC, Manu wrote: You can make a UI run realtime ;) I mean, there are video games that render a complete screen full of zillions of high-detail things every frame! But you shouldn't design a UI framework like a game engine. Especially not if you also want

Re: D GUI Framework (responsive grid teaser)

On Tuesday, 21 May 2019 at 18:08:52 UTC, Robert M. Münch wrote: :-) For a pixel perfect full responsive GUI I need to think about it a bit more. But that's not high priority at the moment. Right, there is no point in making that part too complicated early on because you may find that you want

Re: D GUI Framework (responsive grid teaser)

On Tuesday, 21 May 2019 at 14:04:29 UTC, Robert M. Münch wrote: Here is a new screencast: https://www.dropbox.com/s/ywywr7dp5v8rfoz/Bildschirmaufnahme%202019-05-21%20um%2015.20.59.mov?dl=0 That looks better :-) So this gives us 36 FPS which is IMO pretty good for a desktop app target. There m

Re: D GUI Framework (responsive grid teaser)

On Sunday, 19 May 2019 at 21:01:33 UTC, Robert M. Münch wrote: Hi, we are currently build up our new technology stack and for this create a 2D GUI framework. https://www.dropbox.com/s/iu988snx2lqockb/Bildschirmaufnahme%202019-05-19%20um%2022.32.46.mov?dl=0 The screencast shows a responsive 40

Re: bool (was DConf 2019 AGM Livestream)

On Sunday, 12 May 2019 at 10:27:42 UTC, Isaac S. wrote: So mixing the concepts of true/false and numerical data is "reasonable". I'll have to remember that if I ever have a true/false test; 1's and 0's are quicker to write than T's and F's. I agree with you that bool should be kept separate f

Re: [OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections

On Sunday, 9 September 2018 at 09:34:31 UTC, Nick Sabalausky (Abscissa) wrote: I sincerely apologize for the OT, but AFAIK, I don't have anywhere else to post. Please rm/delete/ban/etc... as appropriate, I take full responsibility. This is a (potentially inappropriate) "CYA" (Covering my "A 55"

Re: The D Language Foundation at Open Collective

On Thursday, 15 March 2018 at 17:06:00 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 March 2018 at 14:13:10 UTC, Mike Parker wrote: At the current exchange rate, a venti-sized cup of drip coffee at Starbucks in Korea is $4.51. When I go to GA, it's cheaper. A venti Americano is $4.79.

Re: The D Language Foundation at Open Collective

On Thursday, 15 March 2018 at 14:13:10 UTC, Mike Parker wrote: At the current exchange rate, a venti-sized cup of drip coffee at Starbucks in Korea is $4.51. When I go to GA, it's cheaper. A venti Americano is $4.79. But I think when people talk about $5 coffees, they're referring to lattes and

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 20:37:24 UTC, bachmeier wrote: There's (almost) no such thing as bad publicity... Programming languages and operating systems have a long history of hot advocacy... not sure how it relates to adoption, but it affects perception. E.g. vocal mac users gave t

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 19:40:12 UTC, Seb wrote: https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d It is getting shot down…

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 18:33:33 UTC, Jacob Carlborg wrote: On 2018-02-14 19:00, Ola Fosheim Grøstad wrote: For a fair comparison Swift should only use libraries that are available both on macOS and Linux. Are any projects using Swift outside of the Mac eco system? Would it be more

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele wrote: But even then, I don't think you should discount or put off using std.csv as "cheating". Yes and no. The problem with all these exercises is that they say nothing about the language and a lot about some default library, whi

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 10:17:21 UTC, psychoticRabbit wrote: I believe the programming langauges of the future, and the ones people should invest their time learning, are those that can be best understood in the least amount of time. Yes, I would say so, unless they bring something n

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 09:28:48 UTC, psychoticRabbit wrote: yeah.. even the more modern C++ code still makes me want to stay clear of it...(perhaps even more so). I just never get the same feeling when I look at D programs. I get the same feeling from both languages, to be honest.

Re: The Expressive C++17 Coding Challenge in D

On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote: It's sadly that using most C++17 features fails to provide clean and compact solution... I don't usually use iostream, but this "challenge" was a reasonable fit for it. If you look over the 4 submissions then the iostream one provide

Re: The Expressive C++17 Coding Challenge in D

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressiv

Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack

But I also get this feeling that Intel do this as an anti-competitive monopolistic. Basically preventing ARM and AMD from partnering with Altera. So it could be more hostile than friendly… The buy up might not make sense business wise in terms of new products. But it could make a lot of sense

<    1   2   3   4   >