Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer wrote: For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you

Re: Fastest JSON parser in the world is a D project

2015-10-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 17 October 2015 at 16:27:08 UTC, Sean Kelly wrote: Oh absolutely. My issue with the benchmark is just that it claims to be a JSON parser benchmark but the bulk of CPU time is actually spent parsing floats. Well, most of such language-comparison benchmarks are just for

Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer wrote: And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it." That I don't understand. You can indeed build your executable from a

Re: Walter and I talk about D in Romania

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 06:18:18 UTC, Jacob Carlborg wrote: On 2015-10-15 23:27, Jack Stouffer wrote: Xcode supports D? And I thought that LDC was the only compiler that outputs info for LLDB? No, but it works as good as the underlying debugger that is used. Which in this case is

Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote: On Thursday, October 15, 2015 14:51:58 Johannes Pfau via Digitalmars-d-announce wrote: BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL

Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 15:07:17 UTC, Ola Fosheim Grøstad wrote: GPL, on the other hand, gives the same right to users of a service. Typo, "AGPL", not "GPL"...

Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer wrote: You certainly can link with it, and then your code becomes GPL. No, the code is code. It is an artifact. The GPL is a legal document. The legal document says what rights you have to the copy you received and what

Re: Fastest JSON parser in the world is a D project

2015-10-16 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 16 October 2015 at 14:09:13 UTC, Nick Sabalausky wrote: This is the real reason I'm not a huge fan of *GPL. Nobody can understand it! It is really simple!! The basic idea is that people shouldn't have to reverse engineer software they use in order to fix it/modify it, so when you

Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 17 October 2015 at 08:20:33 UTC, Daniel N wrote: On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak wrote: On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote: - Data size limited by available contiguous virtual memory Mmaping files for sequential reading

Re: Fastest JSON parser in the world is a D project

2015-10-17 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 17 October 2015 at 13:09:45 UTC, Marco Leise wrote: Am Sat, 17 Oct 2015 11:12:08 + schrieb Ola Fosheim Grøstad : […] you could try to construct a simple benchmark where you iterate over memory (M*cache 3 size) using a "realistic" pattern

Re: Beta D 2.069.0-b1

2015-10-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg wrote: In Ruby, no one will ever use empty parentheses for calling a method. That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.

Re: Beta D 2.069.0-b1

2015-10-11 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 11 October 2015 at 01:52:12 UTC, deadalnix wrote: On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad wrote: On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg wrote: In Ruby, no one will ever use empty parentheses for calling a method. That's actually the

Re: Beta D 2.069.0-b1

2015-10-11 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 11 October 2015 at 17:57:54 UTC, Meta wrote: Just a joke; I consider this a terrible aspect of D. :) I never know what is a joke or not in the forums these days. Anyway, a key difference is that a key inspiration for both BETA and also the actor model is modelling physical (or

Re: Beta D 2.069.0-b1

2015-10-11 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote: On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad wrote: That also means that BETA does not distinguish between a function call and an assignment. Hey, neither does D! writeln("Hello, World!"); writeln = "Hello, World!";

Re: Moving forward with work on the D language and foundation

2015-10-12 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 12 October 2015 at 06:07:16 UTC, Shriramana Sharma wrote: naah... [Is it even possible to write a Go/Rust compiler in Go/Rust? Or have they tried?] Go is implemented in Go. Rust is implemented in Rust + C++.

Re: Beta D 2.069.0-b1

2015-10-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote: To me the whole property discussion looks like one of those endless debates about an insignificant detail. Scala and Ruby seem to do well with sloppy parens. Strict typing and explicitness has a real effect on code legibility

Re: Go 1.5

2015-09-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 27 September 2015 at 16:54:52 UTC, Martin Nowak wrote: On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote: I haven't read the paper, but how does this solve collecting things like strings, or other "leaf types" when you use separate compilation units? We'd use runtime typeinfo.

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim Grøstad wrote: I'm not sure if the current collector scans all registers, or just scans the stack? According to the docs it scans all registers, but even then one must be careful and do addRoot before the pointer is set, otherwise

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote: No, collection could not occure if we speaking about current D GC implementation. So it safe to set pointer before addRoot. It can be triggered by another thread. Wrong: ptr = somestack.pop(); someglobalptr = ptr; // ptr

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim Grøstad wrote: On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote: No, collection could not occure if we speaking about current D GC implementation. So it safe to set pointer before addRoot. It can be triggered by

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 17:56:23 UTC, thedeemon wrote: Yes, good point. One should keep root ranges small too. If we carefully use addRoot() and addRange() for data directly pointing to GC heap I think we don't need to let GC scan everything that can lead to this data. This is

Re: cpp_binder, a not-yet-useful tool for generating C++ bindings

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote: I hope that this post will spur discussion / decisions / action binding C++ libraries into D. I think the language capabilities (e.g. extern(C++, namespace)) get really far and that the next big push needs to be on binding real

Re: cpp_binder, a not-yet-useful tool for generating C++ bindings

2015-09-22 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 22 September 2015 at 15:53:22 UTC, Kagamin wrote: Of course you didn't. In C you can mutate const object without cast. But it's not an issue because it's not what is usually done and usually const works as expected. No. Const objects are read only. Writing to read only objects

Re: Go 1.5

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote: I sometimes wonder - and please forgive me my ignorance, because I'm not a GC expert at all - if it would be possible to create a system where the created objects know their own life spans and destroy themselves, once they are no

Re: Go 1.5

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote: So I'm not completely nuts! Good to know. :) I wonder, if something like this is feasible in D. I am too. I'm toying with some ideas, but I think it would work mostly for shorter programs. Then again, I'm mostly interested in shorter

Re: cpp_binder, a not-yet-useful tool for generating C++ bindings

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote: I guess that the only thing that doesn't map directly to D is &&. The others look on the D side like this: C++ -> D T* -> T* T& -> ref T const T* -> const T* const T& -> const ref T I don't think D const and C++

Re: Go 1.5

2015-09-22 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 22 September 2015 at 09:01:07 UTC, Chris wrote: But that's very annoying to work with and more pain than gain. I don't know... unique_ptr in C++ is quite ok for managing resources, but it does not track "borrowed pointers". But as I point out one can: 1. do it in runtime in

Re: cpp_binder, a not-yet-useful tool for generating C++ bindings

2015-09-22 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 22 September 2015 at 14:46:24 UTC, Kagamin wrote: I believe I've seen const declarations in C incorrectly declared as head const when transitive const was really wanted, but it wasn't done because transitive const in C is so much PITA. So the only real concern here is mangling.

Re: cpp_binder, a not-yet-useful tool for generating C++ bindings

2015-09-22 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 22 September 2015 at 15:11:55 UTC, Kagamin wrote: Another C feature you didn't know about: the standard allows to create a mutable pointer to const data and mutate it. I didn't? Of course I did. In C++ other threads can write to const objects. The function receiving a const

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote: The new GC in Go 1.5 seems interesting. What they say about is certainly interesting. http://blog.golang.org/go15gc Go 1.6 GC roadmap: https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/preview

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 08:36:51 UTC, thedeemon wrote: full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low. Please, let's stop pretending you only have to scan the GC heap. You have to scan all pointers that

Re: Go 1.5

2015-09-19 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 19 September 2015 at 14:12:10 UTC, Rory McGuire wrote: The impression I got reading the article was that their GC was very much like our current one except that the marking part of the algorithm was run concurrently. It is quite different. As mentioned they also protect writes to

Re: Go 1.5

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 14:30:19 UTC, Chris wrote: What's the current state of D's GC. Will std.allocator improve things eventually? I don't understand the point of std.allocator. AFAIK the current GC has very limited compiler support. A smart compiler could move allocations to the

Re: Go 1.5

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote: My understanding is that the key benefit of Rust's system is that compile time checks don't have the runtime costs of smart pointers. + aliasing information. If the compiler can prove that two pointers point to non-overlapping

Re: Go 1.5

2015-09-21 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote: On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote: That's just bad excuses. Excuses? Sure. Bad excuses? Not nearly. The other things I listed are much more important (IMO) than making the GC faster. The most

Re: Go 1.5

2015-09-23 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak wrote: The key to a low latency/high throughput GC is being able to incrementally collect the heap. There is a very interesting paper that uses the type system to perform incremental collections.

Re: Graillon 1.0, VST effect fully made with D

2015-11-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 27 November 2015 at 16:54:11 UTC, Guillaume Piolat wrote: Exactly, that's like all the talk about "scaling" or "big data" on the Internet. Problems we wish we had. All commercial websites can benefit from automatic scaling, load balancing and fully managed systems: 1. You get rid

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 16:15:32 UTC, Guillaume Piolat wrote: There is also a sample-wise FFT I've came across, which is expensive but avoids chunking. Hm, I don't know what that is :). Looking for similar grains is the idea behind the popular auto-correlation pitch detection methods.

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 17:36:47 UTC, Guillaume Piolat wrote: On Sunday, 29 November 2015 at 17:23:20 UTC, Ola Fosheim Grøstad wrote: Yes, so that will generate sidebands in the frequency spectrum, like FM synthesis, right? It won't because the vibrato frequency is too low, around

Re: Moving forward with work on the D language and foundation

2015-12-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 9 December 2015 at 10:33:33 UTC, Tony wrote: On Wednesday, 9 December 2015 at 09:27:55 UTC, deadalnix wrote: Later in life, either you were not talented and most likely not made it, or you were talented and busy capitalizing and what you made younger. That's a very good

Re: Moving forward with work on the D language and foundation

2015-12-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 9 December 2015 at 07:49:58 UTC, Rory McGuire wrote: The number of scarily intelligent people aged over 60 is most likely a lot higher than the number of 25 year olds that are so. Its just the way our brains work, your brain optimises its thought processes continually, and

Re: Moving forward with work on the D language and foundation

2015-12-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 9 December 2015 at 11:04:46 UTC, Tony wrote: How are you defining "capitalizing"? Climbing the ladder. Many researchers don't want to climb the ladder (e.g. become head of department or even group leader) because it means that they spend 100% of their time on administration

Re: Moving forward with work on the D language and foundation

2015-12-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 9 December 2015 at 10:26:03 UTC, Tony wrote: I'd be swayed if you could link to interviews with older scientists, mathematicians or computer scientists who said their work declined with age because they became disillusioned or they ran into social conditioning issues. They are

Re: Better docs for D (WIP)

2016-01-05 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 5 January 2016 at 18:09:57 UTC, Andrei Alexandrescu wrote: Again this goes back to Adam. Let's say we had a contributor Eve who'd gladly take emailed questions and suggestions and integrate them. Would that be as nice? Ohoh... Keep Eve out of it, she's got an Apple.

Re: Graillon 1.0, VST effect fully made with D

2015-11-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 28 November 2015 at 21:05:24 UTC, Adam D. Ruppe wrote: On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote: It's kind of like saying you can climb a mountain on a bycicle if you get of an carry it on the bits that are too steep. *snip* The real story is how easy D makes

Re: Graillon 1.0, VST effect fully made with D

2015-11-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 28 November 2015 at 21:39:06 UTC, Adam D. Ruppe wrote: On Saturday, 28 November 2015 at 21:30:38 UTC, Ola Fosheim Grøstad wrote: What is the better tool to bring to the top of a mountain? Only maniacs go down mountains. The fun part is the ascent... the descent is an exceedingly

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote: While, this doesn't prove you don't have a clue about jitter, my guess is, you don't. Yes, jitter is bad and worse than latency, but OS-X AudioUnits run at a high priority thread where you cannot do system calls, malloc or run a GC.

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote: I see that if that RT music thing doesn't pan out for you, you can always become a psychiatrist. You are a man a many talents, congrats. Maybe you and Guillaume Piolat should try to tone down your french rhetorics? I don't think

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 11:58:20 UTC, Guillaume Piolat wrote: I've never said the GC is compatible with real-time, it isn't. I said, we can avoid it in a small part of an application and be real-time. So D can do real-time (audio). Yes, but why say it if you don't use it after init?

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 12:40:30 UTC, Guillaume Piolat wrote: On Sunday, 29 November 2015 at 12:28:49 UTC, Ola Fosheim Grøstad wrote: The sound samples sound quite a bit like the classic vocal sound of Infected Mushroom to my ears, which is cool. Infected Mushroom released another

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 11:15:41 UTC, Guillaume Piolat wrote: On Sunday, 29 November 2015 at 09:55:43 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 November 2015 at 09:12:42 UTC, deadalnix wrote: I see that if that RT music thing doesn't pan out for you, you can always become a

Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 29 November 2015 at 15:13:41 UTC, Guillaume Piolat wrote: The hard thing about live pitch-tracking is getting the minimal latency keeping reliability. It's not that simple. You also want "voicedness", which is more challenging than pitch. I think they developed it for a specific

Re: Project Highlight: The PowerNex Kernel

2016-06-24 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 24 June 2016 at 15:27:14 UTC, Wild wrote: Ya, I did borrow some code, mostly because my 64-bit code didn't play nice in the beginning. But I think I have rewritten all the code that I borrowed from you. Be careful with that. A rewrite may still be considered a translation, and

Re: 4x faster strlen with 4 char sentinel

2016-06-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 June 2016 at 16:22:56 UTC, Jay Norwood wrote: This strlen2 doesn't require special alignment or casting of char pointer types to some larger type. That keeps the strlen2 implementation fairly simple. Yes, and the idea of speeding up strings by padding out with zeros is not new.

Re: 4x faster strlen with 4 char sentinel

2016-06-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 June 2016 at 19:51:48 UTC, Jay Norwood wrote: Your link's use of padding pads out with a variable number of zeros, so that a larger data type can be used for the compare operations. This isn't the same as my example, which is simpler due to not having to fiddle with alignment

Re: 4x faster strlen with 4 char sentinel

2016-06-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 June 2016 at 06:31:49 UTC, Ola Fosheim Grøstad wrote: On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote: Ending strings with a single null byte/char is to save space. It was critical in the 70´s when C was created and memory space was very limited. That's not the case anymore

Re: 4x faster strlen with 4 char sentinel

2016-06-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 June 2016 at 05:27:12 UTC, chmike wrote: Ending strings with a single null byte/char is to save space. It was critical in the 70´s when C was created and memory space was very limited. That's not the case anymore and I guess the Not only to save space, some CPUs also had cheap

Re: 4x faster strlen with 4 char sentinel

2016-06-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 27 June 2016 at 21:41:57 UTC, Jay Norwood wrote: measurements. I'm using a 100KB char array terminated by four zeros, and doing strlen on substring pointers into it incremented by 1 for 100K times. But this is a rather atypical use case for zero terminated strings? It would make

Re: Vision for the first semester of 2016

2016-01-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 28 January 2016 at 16:12:44 UTC, jmh530 wrote: the standard library or not. As discussed elsewhere, there are clearly benefits to putting some things in phobos (if only for providing a framework for others), and there are costs as it gets too large. That's the maintenance costs,

Re: Vision for the first semester of 2016

2016-01-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote: A good criteria is whether some area has an established and hard to debate solution, then it can go into the standard library. But if there are many different ways around the same topic you should leave the decision to the

Re: Vision for the first semester of 2016

2016-01-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 27 January 2016 at 16:52:53 UTC, Laeeth Isharc wrote: your own argument. Of course there will be lots there that one doesn't need and can't use. But over time things that were once cutting edge become bog standard, and it makes sense to have coherence and convenience rather

Re: Vision for the first semester of 2016

2016-01-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote: I do like the building-block idea you suggest, but one must think about the deeper reasons for why things are owned by which people. It is much easier to get motivated if you have a certain level autonomy. Clearly, the "D

Re: Vision for the first semester of 2016

2016-01-28 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
This is what a good system programming standard library should provide: 1. Types needed to specify library APIs. 2. Functionality for accessing hardware in a non-emulated fashion. 3. Functionality that most _libraries_ need to build on (like arrays/iterators/ranges). 4. Functionality that

Re: Better docs for D (WIP)

2016-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 1 February 2016 at 20:14:42 UTC, Ola Fosheim Grøstad wrote: On Monday, 1 February 2016 at 20:01:11 UTC, Chris Wright wrote: What I would actually expect, instead of a C letter, is a set of guidelines for using the D logo and other trademarked material. That's pretty standard for

Re: Better docs for D (WIP)

2016-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 1 February 2016 at 20:01:11 UTC, Chris Wright wrote: What I would actually expect, instead of a C letter, is a set of guidelines for using the D logo and other trademarked material. That's pretty standard for open source projects. And if those guidelines forbad using the D logo for

Re: Vision for the first semester of 2016

2016-01-29 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote: In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. I've noticed that curated lists of

Re: Better docs for D (WIP)

2016-01-30 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 30 January 2016 at 22:37:18 UTC, Adam D. Ruppe wrote: I know quite a few css tricks... but I don't think I can actually do this without adding a script or something, so I just put an arbitrary fixed width on hover for now. One trick is to set the width and clipping on "dt > *"

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote: Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place. I found GoF underwhelming when I

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote: It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff. My impression is that the majority of the contributors to Phobos are capable D programmers. DMD is implemented in D now,

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote: Also, you skipped past the "uninterested" part - this is a volunteer project, remember? I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote: 1) The prospect of getting something into the standard library is a huge motivator for (at least some) potential contributors. I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote: This is why requiring modules to spend some time on DUB and/or in `std.experimental` before freezing the API is important. Well, there aren't enough D applications written to ensure the usefulness of the API. Just take a look at

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
Or let me put it this way. If the standard library requires POSIX, then it isn't really a standard library, but a POSIX abstraction library...

Re: Vision for the first semester of 2016

2016-01-26 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote: Ouch yes, seen that before. I just would prefer the base library to be exactly that a base. I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...

Re: Vision for the first semester of 2016

2016-01-27 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc wrote: On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad wrote: I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many

Re: DigitalWhip

2016-02-14 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 14 February 2016 at 19:29:54 UTC, Vladimir Panteleev wrote: I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits. But nobody would

Re: DigitalWhip

2016-02-14 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote: Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. If you do, then you should use bounds checks in C++ too. (STL container.at(index) )

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

2016-03-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 9 March 2016 at 22:17:39 UTC, H. S. Teoh wrote: system for my personal projects), I can totally sympathize with the annoyances of using a dynamically-typed language, as well as dodgy iterator designs like __next__. (I've not had to deal with __next__ in Python so far, but *have*

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

2016-03-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 10 March 2016 at 00:29:46 UTC, Jack Stouffer wrote: It's a pretty straight forward standard iterator design and quite different from the table pointers C++ uses. I explain my grievances in the article. They didn't make all that much sense to me, so I wondered what Theo's issues

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

2016-03-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
Just pointing out the obvious: For the simple iterators/generators that run on a non-changing source you can basically break it up into: 1. iterators without lookahead 2. iterators with lookahead Which is basically the same issues you deal with when implementing a lexer. Python-style

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

2016-03-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 10 March 2016 at 17:59:21 UTC, Chris Wright wrote: It's a little easier to write iterators in the Python style: you don't have to cache the current value, and you don't have to have a separate check for end-of-iteration. It's a little easier to use them in the D style: you get

Re: Battle-plan for CTFE

2016-05-15 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the

Re: Battle-plan for CTFE

2016-05-15 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 15 May 2016 at 12:00:43 UTC, Martin Nowak wrote: On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: If you are going to have fast evaluation of loops/recursion then you need to use a solver. And well, doing worse than O(log N) at compile time is a very bad idea. Why not start with

Re: Battle-plan for CTFE

2016-05-15 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 15 May 2016 at 13:44:45 UTC, Martin Nowak wrote: 2^^15 | 3.7s | 4.8G | 0.13s | 10.0M 2^^16 | 5:30m | 15G | 0.13s | 10.8M D's CTFE grows O(N^2) b/c it leaks for almost every operation. We don't currently need a superfast interpreter, even the simplest possible interpreter will

Re: Battle-plan for CTFE

2016-05-15 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 15 May 2016 at 15:09:17 UTC, Stefan Koch wrote: You want it ? Write it. I don't «want» anything.

Re: new cpuid is ready for comments

2016-07-12 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 12 July 2016 at 15:24:29 UTC, Guillaume Chatelet wrote: 2. As far as I know, Android does not expose either CPU identification or cache structure information to userspace. Please do correct me if I'm wrong and this library found a way around that --- but from a cursory look at the

Re: DIP: Tail call optimization

2016-07-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 10 July 2016 at 17:10:32 UTC, Dietrich Daroch wrote: Annotating every callsite seems uncomfortable, being able to perform TCO is a property of the function and not something that might look call-site dependant. You only need to annotate the location where the function calls

Re: DIP: Tail call optimization

2016-07-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 10 July 2016 at 17:32:32 UTC, Dietrich Daroch wrote: It might be interesting to have proof that the stack is bounded (and won't overflow). Yes, a stack depth guarantee would be useful for D fibers.

Re: DIP: Tail call optimization

2016-07-10 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote: Hi everyone (= I've just added a new proposal to add a new attribute to ensure TCO is applied. The proposal is really simple, but I'm clueless on how to implement it and also interested on getting feedback on it. Why should

Re: Battle-plan for CTFE

2016-07-05 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote: so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got What is «bug6498»?

Re: DIP: Tail call optimization

2016-07-11 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 11 July 2016 at 16:18:47 UTC, Dietrich Daroch wrote: Previous discussion seems to favour @unboundedStack as it can become a requirement to go beyond the stack-size-safe operations effectibly tracking where stack overflow may happen and encourage detailed review of those functions.

Re: DIP: Tail call optimization

2016-07-11 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote: I've been thinking about changing @tco for @boundedStack, as it'll really reflect guarantees on functions while implicitly asking for TCO on functions that require it. But the fact that most functions should be marked as

Re: Ocean preview finally open sourced

2016-07-01 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Friday, 1 July 2016 at 10:31:59 UTC, Leandro Lucarella wrote: Oh, well. Sorting out the license(s) were one of the major pains and time consuming tasks we had to do to opensource this, and apparently despite our best efforts there are stuff that we didn't see. *nods* I was only looking at

Re: Ocean preview finally open sourced

2016-07-01 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: (although please have a look at the licensing terms, even when all our code is Boost, there is code inherited from Tango that isn't), criticize it, and if you are really nice, fill issues and make pull requests! I find the

Re: Ocean preview finally open sourced

2016-07-04 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 4 July 2016 at 08:34:15 UTC, Andrea Fontana wrote: On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: Hello again Dland! I'm happy to finally announce the open sourcing of our Ocean base library, just it time to keep our word and make it in June ;-)

Re: SmartRef: The Smart Pointer In D

2017-01-23 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 14 January 2017 at 15:41:01 UTC, Dmitry Olshansky wrote: That is C++ smart_ptr has to be atomic, while its D counter part may safely be non-atomic because everything is TLS be default. I assume you mean std::shared_ptr. The reference counting semantics are atomic, but the I

Re: Questionnaire

2017-02-09 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote: * "Minimal Runtime" is the building block of systems programming. If this is not a core feature of a language, it will never compete with C. Systems programmers in my field need to incrementally opt-in to features in a pay-as-you-go

Re: BLAS implementation for D

2017-04-20 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Saturday, 15 April 2017 at 20:20:01 UTC, Bill Baxter wrote: And more than that, companies that are serious about avoiding litigation will make sure that everyone working on this new project has not even seen the source code for the library with the other license. If someone who has seen

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

2017-04-24 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote: Swift allows raw pointer manipulation. I didn't know that Swift had that as a language construct. Link? I know that it provides library solutions for raw pointers, but that can be said for most languages. Java implementations

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

2017-04-24 Thread Ola Fosheim Grøstad via Digitalmars-d-announce
On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as

  1   2   >