Re: unusual bare metal target: Amazon Dash
On 19/08/2015 3:24 a.m., Laeeth Isharc wrote: On Tuesday, 18 August 2015 at 04:36:49 UTC, Rikki Cattermole wrote: On 18/08/2015 1:32 p.m., Laeeth Isharc wrote: I don't know whether D can run on one, but from a quick look perhaps feasible. Running D on something like this (perhaps it's underpowered, but looked to have similar spec to what people had been doing with related ARM cortex processors) would certainly make the point very vivid that it can be a bare metal programming language. Only 1Mb of flash RAM for the program - is that enough? https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/programming https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/overview The Amazon Dash button is a tiny device that orders products from Amazon.com at the press of a button. It's designed to be put wherever you store consumeables like paper towels, trash bags, etc. so that you can easily order more when they run out. The Dash is great at what it's designed to do, but did you know inside the Dash is a powerful ARM Cortex-M3 processor and WiFi module that are very similar to wireless development boards like the Particle Photon? You'll even find there are easily accessible test pads on the Dash which allow you to reprogram its CPU and turn it into your own $5 internet button! This guide will explore how to take apart the Dash and reprogram its CPU to run your own code. ... The CPU is a STM32F205RG6 processor which is an ARM Cortex-M3 that can run up to 120mhz and has 128 kilobytes of RAM and 1 megabyte of flash memory for program storage. The WiFi module is a BCM943362 module which in combination with the CPU make it a platform for Broadcom's WICED SDK. There's a 16 megabit SPI flash ROM which is typically used in conjunction with the WICED SDK for storing application data. An ADMP441 microphone is connected to the CPU and used by the Dash iOS application to configure the device using the speaker on a phone/tablet. There's a single RGB LED and a button. By what you are saying, I believe it should be doable. Although I'm a little worried for the WiFi support. Do you need to include the code to drive it beyond wrap up some communication to it? 1mb flash should be enough to run D code on it. If you strip out a good percentage of druntime and definitely no Phobos. Although you may be able to mark and use some of that 16mb flash rom as executable code storage. If that's so, you'll be in a good place to have more then 1mb. It would require some clever runtime linking tricks however. I'm probably not the best person to go more in depth about it or the specific chips. So I won't. Most of my knowledge comes from reading what others says and talking with Jens Bauer. I think its doable too. Nobody seems to have figured out the wifi yet - more at LED flashing stage. It's funny these wifi devices have microphones in them ! I was thinking about that. Maybe for speech recognition? Of course there is no way that device could actually analyze it.
Promises/A+ spec implementations?
Hi, folks. Over ten years ago I had some interest in the D language. I'm starting to think about it again... I've been using Mozilla's Promises implementations for quite a while, now, and they're surprisingly nice to work with. They are the next generation beyond the callback function patterns I learned in JavaScript. I've been thinking that writing a Promises/A+ library for D would be a good task for a relatively inexperienced D programmer. I didn't see any Promises/A+ implementations in the standard library or on code.dlang.org. Now, whether I write that library or someone else beats me to it, I don't really care right now. I'm interested in doing it, but my time is extremely limited. I'm mainly posting this as a request to get a Promises/A+ library started, and for me to observe the process of crafting a library. If someone wants to be a mentor for me on this, answering direct questions, that'd be great. The spec for Promises/A+ is at https://promisesaplus.com/ . Mozilla's Bobby Holley recently wrote a good blog post about a "MozPromise" implementation which includes supporting multithreading (a concept I don't fully understand how to write for, yet) and cancelling a Promise (which isn't in the spec, but makes sense for Mozilla's purposes). That blog post is at http://bholley.net/blog/2015/mozpromise.html . Finally, I had an old login to this forum (kb7iuj), which I've long forgotten the password for. I did see that there's no password recovery support, so could someone just terminate that login for good?
Re: Starting a HTTPS session with D
On Thursday, 12 February 2015 at 12:34:21 UTC, Vladimir Panteleev wrote: On Windows, if you are using the curl library included with DMD 2.066.1, curl will use the Windows certificate store. Did this changed? I use 2.068.0 and still have problems with SSL. Sorry for necroposting.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 17:44:00 UTC, Xinok wrote: On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. ... What's wrong with just putting all the foreach statements on a single line? foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10) { writeln(i, j, k); } This. And it's more obvious what you're trying to do.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 16:51:01 UTC, ixid wrote: On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote: On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. ... What would you do with associative arrays? void main() { auto aa = [1:1, 2:2]; foreach (a, b ; aa, 1..10) foo(a, b); } Prevent both iterator count and associative value variables for foreach loops with nested loops. This behaviour of associative arrays is already an odd case as it clashes with the iterator behaviour for other arrays. It is not iterator count, it is key and value. And actually, it is pretty consistent. import std.stdio; void main () { foreach (index, value; [2, 4, 8]) writefln ("a[%s] = %s", index, value); foreach (index, value; ['x': 2, 'y': 4, 'z': 8]) writefln ("b[%s] = %s", index, value); } The output is: a[0] = 2 a[1] = 4 a[2] = 8 b[z] = 8 b[x] = 2 b[y] = 4
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. ... What's wrong with just putting all the foreach statements on a single line? foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10) { writeln(i, j, k); }
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 16:02:42 UTC, cym13 wrote: On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. ... What would you do with associative arrays? void main() { auto aa = [1:1, 2:2]; foreach (a, b ; aa, 1..10) foo(a, b); } Prevent both iterator count and associative value variables for foreach loops with nested loops. This behaviour of associative arrays is already an odd case as it clashes with the iterator behaviour for other arrays.
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. import std.algorithm, std.range, std.stdio; void main() { // Standard foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10) writeln(i, j, k); // Better foreach(k, j, i; cartesianProduct(10.iota, 10.iota, 10.iota)) writeln(i, j, k); // Sugar foreach(k, j, i; 0..10, 0..10, 0..10) writeln(i, j, k); //Following brace rules // Standard foreach(i; 0..10) { foreach(j; 0..10) { foreach(k; 0..10) { writeln(i, j, k); } } } // Sugar foreach(k, j, i; 0..10, 0..10, 0..10) { writeln(i, j, k); } You can create a multi-loop quite easily in template form for avoid the nesting. Essentially use an array for the the index instead of individual variables, e.g., mutliloop([0..10, 0..10, 0..10], (i)=> { writeln(i[0], i[1], i[2]); }); I'm not sure how efficient it is but essentially achieves what you are asking without too much overhead. Obviously having good language support is always nice...
Re: foreach multiple loop sugar
On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote: Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. ... What would you do with associative arrays? void main() { auto aa = [1:1, 2:2]; foreach (a, b ; aa, 1..10) foo(a, b); }
foreach multiple loop sugar
Though sugar seems to be somewhat looked down upon I thought I'd suggest this- having seen the cartesianProduct function from std.algorithm in another thread I thought it would be an excellent piece of sugar in the language. It's not an earth shattering change but it makes something very common more elegant and reduces indentation significantly for multiple nested loops. Braces make nested loops very messy and any significant quantity of code in the loop body benefits from not being in a messy nesting. import std.algorithm, std.range, std.stdio; void main() { // Standard foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10) writeln(i, j, k); // Better foreach(k, j, i; cartesianProduct(10.iota, 10.iota, 10.iota)) writeln(i, j, k); // Sugar foreach(k, j, i; 0..10, 0..10, 0..10) writeln(i, j, k); //Following brace rules // Standard foreach(i; 0..10) { foreach(j; 0..10) { foreach(k; 0..10) { writeln(i, j, k); } } } // Sugar foreach(k, j, i; 0..10, 0..10, 0..10) { writeln(i, j, k); } }
Re: ReturnType of lambda templates
On Tuesday, 18 August 2015 at 15:11:34 UTC, John Colvin wrote: for simple lambdas like that (i.e. function templates with one template arguments that corresponds to the type of the first and only argument), just add this template overload: auto apply( alias fun, T )( Nullable!T nullable ) if( !isSomeFunction!fun ) { return .apply!(fun!T, T)(nullable); } and it should work (give or a take a few typos on my part). That was quick - and it works :) Now, where is my thinking cap again?
Re: unusual bare metal target: Amazon Dash
On Tuesday, 18 August 2015 at 04:36:49 UTC, Rikki Cattermole wrote: On 18/08/2015 1:32 p.m., Laeeth Isharc wrote: I don't know whether D can run on one, but from a quick look perhaps feasible. Running D on something like this (perhaps it's underpowered, but looked to have similar spec to what people had been doing with related ARM cortex processors) would certainly make the point very vivid that it can be a bare metal programming language. Only 1Mb of flash RAM for the program - is that enough? https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/programming https://learn.adafruit.com/dash-hacking-bare-metal-stm32-programming/overview The Amazon Dash button is a tiny device that orders products from Amazon.com at the press of a button. It's designed to be put wherever you store consumeables like paper towels, trash bags, etc. so that you can easily order more when they run out. The Dash is great at what it's designed to do, but did you know inside the Dash is a powerful ARM Cortex-M3 processor and WiFi module that are very similar to wireless development boards like the Particle Photon? You'll even find there are easily accessible test pads on the Dash which allow you to reprogram its CPU and turn it into your own $5 internet button! This guide will explore how to take apart the Dash and reprogram its CPU to run your own code. ... The CPU is a STM32F205RG6 processor which is an ARM Cortex-M3 that can run up to 120mhz and has 128 kilobytes of RAM and 1 megabyte of flash memory for program storage. The WiFi module is a BCM943362 module which in combination with the CPU make it a platform for Broadcom's WICED SDK. There's a 16 megabit SPI flash ROM which is typically used in conjunction with the WICED SDK for storing application data. An ADMP441 microphone is connected to the CPU and used by the Dash iOS application to configure the device using the speaker on a phone/tablet. There's a single RGB LED and a button. By what you are saying, I believe it should be doable. Although I'm a little worried for the WiFi support. Do you need to include the code to drive it beyond wrap up some communication to it? 1mb flash should be enough to run D code on it. If you strip out a good percentage of druntime and definitely no Phobos. Although you may be able to mark and use some of that 16mb flash rom as executable code storage. If that's so, you'll be in a good place to have more then 1mb. It would require some clever runtime linking tricks however. I'm probably not the best person to go more in depth about it or the specific chips. So I won't. Most of my knowledge comes from reading what others says and talking with Jens Bauer. I think its doable too. Nobody seems to have figured out the wifi yet - more at LED flashing stage. It's funny these wifi devices have microphones in them !
Re: ReturnType of lambda templates
On Tuesday, 18 August 2015 at 14:25:34 UTC, Roland Hadinger wrote: Hi! Suppose I wanna do this (which already works, which is why D is pretty cool): import std.traits; import std.typecons : Nullable; // Retrofit Nullable to allow for monadic chaining // auto apply( alias fun, T )( Nullable!T nullable ) if( isSomeFunction!fun ) { enum returnsVoid = is( ReturnType!fun == void ); enum returnsNullable = is( ReturnType!fun : Nullable!X, X ); static if( returnsVoid ) { if( !nullable.isNull ) fun( nullable.get ); } else static if( returnsNullable ) { alias NR = ReturnType!fun; if( nullable.isNull ) return NR(); else return fun( nullable.get ); } else { alias NR = Nullable!( ReturnType!fun ); if( nullable.isNull ) return NR(); else return NR( fun( nullable.get ) ); } } void main() { Nullable!int a = 1; Nullable!int b = a.apply!( (int x) => 2 * x ); // .apply!( (double x) => foo( x, u ) ) // .apply!( (double x) => bar( x, v ) ) // .apply!( (string x) => baz( x, w ) ); } ...but without explicitly specifying the type of the lambda parameter: void main() { Nullable!int a = 1; Nullable!int b = a.apply!( x => 2 * x ); // .apply!( x => foo( x, u ) ) // .apply!( x => bar( x, v ) ) // .apply!( x => baz( x, w ) ); } Problem is, the shorter form involves lambda templates, and both 'isSomeFunction' and 'ReturnType' currently don't seem to work with those. No problems with the other version. Can I fix my 'apply' function to still allow for the less verbose form? If that's impossible, is it a theoretical possibility to improve D's type deduction to handle this? Or should I just not attempt to write code like this for the time being (after all, functional code like this incurs some overhead, but in this particular case, I'd prefer legibility over performance)? Thanks! for simple lambdas like that (i.e. function templates with one template arguments that corresponds to the type of the first and only argument), just add this template overload: auto apply( alias fun, T )( Nullable!T nullable ) if( !isSomeFunction!fun ) { return .apply!(fun!T, T)(nullable); } and it should work (give or a take a few typos on my part).
ReturnType of lambda templates
Hi! Suppose I wanna do this (which already works, which is why D is pretty cool): import std.traits; import std.typecons : Nullable; // Retrofit Nullable to allow for monadic chaining // auto apply( alias fun, T )( Nullable!T nullable ) if( isSomeFunction!fun ) { enum returnsVoid = is( ReturnType!fun == void ); enum returnsNullable = is( ReturnType!fun : Nullable!X, X ); static if( returnsVoid ) { if( !nullable.isNull ) fun( nullable.get ); } else static if( returnsNullable ) { alias NR = ReturnType!fun; if( nullable.isNull ) return NR(); else return fun( nullable.get ); } else { alias NR = Nullable!( ReturnType!fun ); if( nullable.isNull ) return NR(); else return NR( fun( nullable.get ) ); } } void main() { Nullable!int a = 1; Nullable!int b = a.apply!( (int x) => 2 * x ); // .apply!( (double x) => foo( x, u ) ) // .apply!( (double x) => bar( x, v ) ) // .apply!( (string x) => baz( x, w ) ); } ...but without explicitly specifying the type of the lambda parameter: void main() { Nullable!int a = 1; Nullable!int b = a.apply!( x => 2 * x ); // .apply!( x => foo( x, u ) ) // .apply!( x => bar( x, v ) ) // .apply!( x => baz( x, w ) ); } Problem is, the shorter form involves lambda templates, and both 'isSomeFunction' and 'ReturnType' currently don't seem to work with those. No problems with the other version. Can I fix my 'apply' function to still allow for the less verbose form? If that's impossible, is it a theoretical possibility to improve D's type deduction to handle this? Or should I just not attempt to write code like this for the time being (after all, functional code like this incurs some overhead, but in this particular case, I'd prefer legibility over performance)? Thanks!
Re: Getting a TypeTuple of a Template's Arguments
On Tuesday, 18 August 2015 at 07:41:00 UTC, thedeemon wrote: On Monday, 17 August 2015 at 21:23:49 UTC, Meta wrote: For functions, we have std.traits.ParameterTypeTuple. Is there any equivalent functionality for templates? I've recently searched for this thing and haven't found anything for uninstantiated templates, only for instantiated. As I'd thought. I can't think of a way to do it, either, so I guess that's a no-go for the time being.
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 14:43:35 UTC, D_Learner wrote: Hello everyone . I need advice on my first D-project . I have uploaded it at :- [...] I wouldn't compare benchmarks without optimisations turned on. Atila
Re: Weird error message.
Decided to do a fresh install of windows, and problem has one away. It seems no matter how careful you are to keep your system lean and clean windows eventually starts grinding gears. Thanks,
Re: Compiletime Vs Runtime bencmarks
On Tuesday, 18 August 2015 at 07:16:32 UTC, D_Learner wrote: On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D profiler's. Though am not searching for exact, but theyy must be comparable atleast. When you say D profiler, you mean dmd's built-in profiler, yes? That is an instrumenting profiler which adds a not insignificant cost to function calls, which means you have to be careful interpreting the results
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:03:09 UTC, Ozan wrote: I think that Adam's jsvar idea is a great way to bring more flexibility into D. The same in OOP would be also great. Looks like jsvar can invoke opCall method for wrapped object: https://github.com/adamdruppe/arsd/blob/master/jsvar.d#L729 you can extend it to support invocation of other methods.
Re: Real OOP with D
On Tuesday, 18 August 2015 at 07:19:02 UTC, BBasile wrote: On Tuesday, 18 August 2015 at 06:27:53 UTC, Ozan wrote: On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote: On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote: Hi [...] Is there any way to get real OOP with D? Regards, Ozan Can you name an OOP oriented language that allows this ? Your example is eroneous OOP. The 2 other answers you 've got (the first using an interface and the second using an abstract class) are valid OOP. One of the fundamental concept OOP is that a function defined in a class exists also in its subclasses. So how do you expect `greeting()` to exist in Family if it's only defined in its sub-classes ? You can verify that with the 'Liskov substitution principle' (https://en.wikipedia.org/wiki/Liskov_substitution_principle). Actually your sample violates this principle. Languages like Groovy or JavaScript (with the help of frameworks ;-) And I believe many more the newer ones. But that's not the point. And... This was not a criticism against D (... "bad D, has no understanding of OOP. Boahh" ;-) It was only a question about handling of a typical OOP problem in a class-typed implementation of OOP like D has. Thanks to every existing or new creative programming language, today we have so many other ways to solve our programming problems. Regards Ozan You example is not valid strongly-typed OOP. In D you could do something similar but not with the OO paradigm but rather with compile-time refexion (introspection): --- import std.stdio; static bool isFamilyMember(T)() { import std.traits: isCallable; return __traits(hasMember, T, "greeting"); } void FamilyMemberSayHello(T)(ref T t) { static if (isFamilyMember!T) t.greeting; } struct Dad{ void greeting(){"hello from a Dad".writeln;} } struct Boy{ void greeting(){"hello from a Boy".writeln;} } struct IdiotDuBled{} void main() { auto dad = new Dad; auto boy = new Boy; auto idiotDuBled = new IdiotDuBled; FamilyMemberSayHello(dad); FamilyMemberSayHello(boy); FamilyMemberSayHello(idiotDuBled); } --- The idea is rather to check at compile time if a variable will have the "trait" which characterizes a FamilyMember, without using inheritence. I believe D allows what you want to do using generic programming. Being a compiled and strongly typed language, the information about the type, needs to be available during compilation, but this makes no difference from a theoretic OOP view. BBasiles example can also be done without the trait. Then the check for greeting() will be done by the compiler. void FamilyMemberSayHello(T)(ref T t) { t.greeting; } struct Dad{ void greeting(){"hello from a Dad".writeln;} } struct Boy{ void greeting(){"hello from a Boy".writeln;} } struct IdiotDuBled{} void main() { auto dad = new Dad; auto boy = new Boy; auto idiotDuBled = new IdiotDuBled; FamilyMemberSayHello(dad); FamilyMemberSayHello(boy); FamilyMemberSayHello(idiotDuBled); //will not compile } The OOP Model of D is fairly close to that of Eiffel which I consider pretty pure Object Oriented. The only exception is multiple inheritance, which I do not miss at all. In my Opinion D is a great language for Object Oriented Design and Programming. It awesomely supports Contracts and Constraint Generics, which many languages lack. I never missed multiple inheritance, as I was able to cover all my use cases with mixins. The support for functional programming and CTFE allows to elegantly handle the cases, where inheritance based OOP feels awkward. Actually I urge all the people who say: "Smalltalk was the last (only) good OOP language!" to try out D.
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:03:09 UTC, Ozan wrote: I think that Adam's jsvar idea is a great way to bring more flexibility into D. The same in OOP would be also great. Dynamic typing in D can be emulated in the same way jsvar and Variant do it. If jsvar doesn't support it, you can look into libraries like luad, which AFAIK can generate dynamic wrappers for static types, I suppose there was something similar for IDispatch.
Re: Getting a TypeTuple of a Template's Arguments
On Monday, 17 August 2015 at 21:23:49 UTC, Meta wrote: For functions, we have std.traits.ParameterTypeTuple. Is there any equivalent functionality for templates? I've recently searched for this thing and haven't found anything for uninstantiated templates, only for instantiated.
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D profiler's. Though am not searching for exact, but theyy must be comparable atleast.
Re: Real OOP with D
On Tuesday, 18 August 2015 at 06:27:53 UTC, Ozan wrote: On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote: On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote: Hi [...] Is there any way to get real OOP with D? Regards, Ozan Can you name an OOP oriented language that allows this ? Your example is eroneous OOP. The 2 other answers you 've got (the first using an interface and the second using an abstract class) are valid OOP. One of the fundamental concept OOP is that a function defined in a class exists also in its subclasses. So how do you expect `greeting()` to exist in Family if it's only defined in its sub-classes ? You can verify that with the 'Liskov substitution principle' (https://en.wikipedia.org/wiki/Liskov_substitution_principle). Actually your sample violates this principle. Languages like Groovy or JavaScript (with the help of frameworks ;-) And I believe many more the newer ones. But that's not the point. And... This was not a criticism against D (... "bad D, has no understanding of OOP. Boahh" ;-) It was only a question about handling of a typical OOP problem in a class-typed implementation of OOP like D has. Thanks to every existing or new creative programming language, today we have so many other ways to solve our programming problems. Regards Ozan You example is not valid strongly-typed OOP. In D you could do something similar but not with the OO paradigm but rather with compile-time refexion (introspection): --- import std.stdio; static bool isFamilyMember(T)() { import std.traits: isCallable; return __traits(hasMember, T, "greeting"); } void FamilyMemberSayHello(T)(ref T t) { static if (isFamilyMember!T) t.greeting; } struct Dad{ void greeting(){"hello from a Dad".writeln;} } struct Boy{ void greeting(){"hello from a Boy".writeln;} } struct IdiotDuBled{} void main() { auto dad = new Dad; auto boy = new Boy; auto idiotDuBled = new IdiotDuBled; FamilyMemberSayHello(dad); FamilyMemberSayHello(boy); FamilyMemberSayHello(idiotDuBled); } --- The idea is rather to check at compile time if a variable will have the "trait" which characterizes a FamilyMember, without using inheritence.
Re: Compiletime Vs Runtime bencmarks
On Monday, 17 August 2015 at 22:01:32 UTC, John Colvin wrote: On Monday, 17 August 2015 at 17:48:22 UTC, D_Learner wrote: On Monday, 17 August 2015 at 14:52:18 UTC, Edwin van Leeuwen wrote: [...] The surprisingly, the D-profiler gives plausible results:- Algorithm1 2921 int rtime_pre.bm_rmatch (runtime ) 2122 int ctime_pre.bm_cmatch (compiletime ) 1317int rtime_pre.bmh_rmatch (runtime ) 1099int ctime_pre.bmh_cmatch (compiletime ) 3959 int rtime_pre.ag_rmatch (runtime ) 2688 pure int ctime_pre.ag_cmatch (compiletime ) This suggests that my timer design has some flaw ;) std.datetime.StopWatch is the easiest way to do timing manually, or just use std.datetime.benchmark My code already uses std.datetime.StopWatch , but I get results which are no match to the D compilers.