Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 9 September 2015 at 07:04:05 UTC, Per Nordlöw wrote: - David's library and quantities use different interal representation. Davids 7-dimensional vector of rational integers (a la Boost) is hardcoded to represent SI units. You must be confusing the library with something else (or me with another David). I'm pretty sure that my original proof-of-concept is the most flexible of all of them, coming with support for composing arbitrary runtime conversion functions, affine quantities and so on. SI unit definitions are merely predefined in a second module because they are commonly used. That being said, my implementation is ages old and could probably be done much better today. - David
Re: RFC: Units of measurement for D (Phobos?)
On Wednesday, 9 September 2015 at 15:21:22 UTC, HaraldZealot wrote: One big problem is, that in SI base unit for mass is kilogram not gram. This is definitely not a "big problem". There is nothing that sets apart the "base" units in my old library from any other units, except for the fact that they happen to be defined using baseUnit!(), not by adding a prefix. Kilogram just happens to be defined as kilo!gram so that you don't get things like millikilogram. — David
Re: std.allocator ready for some abuse
On Friday, 1 November 2013 at 02:33:57 UTC, Andrei Alexandrescu wrote: Added SharedFreelist, a lock-free freelist. http://erdani.com/d/phobos-prerelease/std_allocator.html#.SharedFreelist Andrei Hi Andrei, Please check this bug fix for SharedFreelist https://github.com/andralex/phobos/pull/21 . I have found that source code for bounded `maxNodes` version of SharedFreelist is commented out. I understand that `maxNodes` can be only approximate bound for _shared_ free list. However, approximate `maxNodes` bound is very useful too. Can I create PR for this feature? Best Regards, --Ilya
Re: std.experimental.testing formal review
On Wednesday, 9 September 2015 at 18:54:30 UTC, Brian Schott wrote: On Wednesday, 9 September 2015 at 15:20:41 UTC, Robert burner Schadek wrote: This post marks the start of the two week review process of std.experimental.testing. PR: https://github.com/D-Programming-Language/phobos/pull/3207 Dub: http://code.dlang.org/packages/unit-threaded Doc: See CyberShadow/DAutoTest for up-to-date documentation build Previous Thread: http://forum.dlang.org/post/uzocokshugchescba...@forum.dlang.org Package-level documentation seems to be missing from the auto-generated documentation. I think I generated the docs before there were any, let me go see. The gen_ut_main link on the side bar is also a 404. Good catch, I'll take a look. I'm not looking forward to trying to recreate the site... it really should be easier. std.experimental.testing.options.Options and std.experimental.testing.reflection.TestData fields have no DDoc, so they don't show up in the generated documentation. I'll add DDoc. Is there going to be a shouldEqual that's specialized for floating point, or should shouldBeTrue(approxEqual(...)) be used instead? (If so, this should be documented) Good question. std.experimental.testing.testcase.TestCase.numTestsRun should be @property? Sure. Atila
Re: std.experimental.testing formal review
On 09-Sep-2015 18:20, Robert burner Schadek wrote: This post marks the start of the two week review process of std.experimental.testing. PR: https://github.com/D-Programming-Language/phobos/pull/3207 Dub: http://code.dlang.org/packages/unit-threaded Doc: See CyberShadow/DAutoTest for up-to-date documentation build Previous Thread: http://forum.dlang.org/post/uzocokshugchescba...@forum.dlang.org Where is the announce thread? -- Dmitry Olshansky
Re: std.experimental.testing formal review
On Thursday, 10 September 2015 at 14:03:31 UTC, Dmitry Olshansky wrote: On 09-Sep-2015 18:20, Robert burner Schadek wrote: This post marks the start of the two week review process of std.experimental.testing. PR: https://github.com/D-Programming-Language/phobos/pull/3207 Dub: http://code.dlang.org/packages/unit-threaded Doc: See CyberShadow/DAutoTest for up-to-date documentation build Previous Thread: http://forum.dlang.org/post/uzocokshugchescba...@forum.dlang.org Where is the announce thread? http://forum.dlang.org/post/tekjnfyvvmrozmqix...@forum.dlang.org
Re: What's the ETA for 2.068?
Am Wed, 17 Jun 2015 14:12:46 +0200 schrieb Marco Leise : > Am Sat, 13 Jun 2015 09:01:27 + > schrieb "Vladimir Panteleev" : > > > On Saturday, 13 June 2015 at 00:13:23 UTC, Marco Leise wrote: > > > Am Thu, 11 Jun 2015 06:26:29 + > > > schrieb "weaselcat" : > > > > > >> last I read was "after dconf," > > > > > > DMD 2.068 will have been released September 8th, 2015. > > > In other words: in 87 days. > > > > Where is this number from? > > I had to take a look into the future to acquire it. Damn it, off by 1 month, haha. -- Marco
Re: Member function pointers
On Thursday, 10 September 2015 at 01:52:17 UTC, digitalmars.D wrote: On 10 September 2015 at 04:55, Walter Bright via Digitalmars-d wrote: On 6/10/2013 7:33 AM, Manu wrote: [...] Sorry to say, your n.g. poster is back to its old tricks :-) We've resolved this issue since 6/10/2013 no? ;) In the web forum, this post shows up as having author "digitalmars.D", not even "Manu via Digitalmars-d" like your posts normally do and definitely not "Manu" like it should. CyberShadow?
Re: Member function pointers
On Thursday, 10 September 2015 at 16:18:13 UTC, John Colvin wrote: On Thursday, 10 September 2015 at 01:52:17 UTC, digitalmars.D wrote: On 10 September 2015 at 04:55, Walter Bright via Digitalmars-d wrote: On 6/10/2013 7:33 AM, Manu wrote: [...] Sorry to say, your n.g. poster is back to its old tricks :-) We've resolved this issue since 6/10/2013 no? ;) In the web forum, this post shows up as having author "digitalmars.D", not even "Manu via Digitalmars-d" like your posts normally do and definitely not "Manu" like it should. CyberShadow? Heh. My fault. Fixed (though it'll stick for that post in some views).
Better lambdas!!!!!!!!!!
How bout this:
void myfunc(double delegate(int i, int z, float f)) {}
myfunc((int i, int z, float f) { return i*z*f; } }
vs
myfunc({ return i*z*f; }) // Names of parameters are inferred
from signature.
by specifying the parameter names in the signature, we don't have
to specify them in the lamba creation. This doesn't replace the
original way, just adds the ability to infer the names if they
are not specified.
Of course, this hides the names outside the lambda, but a warning
could be issued(no different than if one does it explicitly.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
void myfunc(double delegate(int i, int z, float f)) {}
myfunc((int i, int z, float f) { return i*z*f; } }
You could also write `myfunc((i,z,f) => i*z*f);` right now. The
names are easy to do.
Re: Better lambdas!!!!!!!!!!
On 09/10/2015 10:55 AM, Prudence wrote:
> How bout this:
>
> void myfunc(double delegate(int i, int z, float f)) {}
>
>
> myfunc((int i, int z, float f) { return i*z*f; } }
>
> vs
>
> myfunc({ return i*z*f; }) // Names of parameters are inferred from
> signature.
Considering other features of the language, that's pretty much
impossible in D. What if there is another i in scope:
int i;
myfunc({ return i*z*f; });
Now, should it call another overload of myfunc that takes (int z, int f)
because i is something else?
Should the compiler analyze the body of the code and decide which
symbols could be parameters? And then go through all overloads of
myfunc? etc.?
Ali
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote: Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly. This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote: On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote: Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly. This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback. That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 18:23:52 UTC, Jonathan M Davis wrote: On Thursday, 10 September 2015 at 18:05:43 UTC, anonymous wrote: On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote: Of course, this hides the names outside the lambda, but a warning could be issued(no different than if one does it explicitly. This makes the parameter names part of the API. The author of a library is unable to rename parameter without breaking user code. I do not believe the benefit is large enough to accept such a drawback. That's one of the main reasons that I hate the idea of named arguments. It's more stuff that's part of the API, more public stuff that you have to name correctly and risk bikeshedding arguments over, and more stuff that can you can't change without breaking existing code. - Jonathan M Davis +1
Re: Member function pointers
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir Panteleev wrote: Heh. My fault. Fixed (though it'll stick for that post in some views). Now the main index says: "Unexpected end of input when converting from type string to type long".
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 17:55:06 UTC, Prudence wrote:
by specifying the parameter names in the signature, we don't
have to specify them in the lamba creation. This doesn't
replace the original way, just adds the ability to infer the
names if they are not specified.
Of course, this hides the names outside the lambda, but a
warning could be issued(no different than if one does it
explicitly.
How about just having numbered parameters like this:
{ $2 < ($1*$2) }
C# Proposal for Nullability Checking
https://github.com/dotnet/roslyn/issues/5032 There've always been rumblings here about removing nullable references from D, but that's a large break in backwards compatibility that we can't really afford at this point (outside some magic compiler switch). This C# proposal has some interesting ideas on how assisting the programmer in avoiding null pointer dereferencing can be balanced with backwards-compatibility concerns. I think there's some valuable stuff in here that could potentially be applied in D as well.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim
Grøstad wrote:
How about just having numbered parameters like this:
{ $2 < ($1*$2) }
What about this situation?
[[1, 2], [3, 4], [5, 6]].reduce!{
auto localMax = { $1 > $2 ? $1 : $2; }
auto first = $1.reduce!localMax;
auto second = $2.reduce!localMax;
return first > second ? first : second;
}
How can the compiler tell which $1 and $2 is which? What if one
wants to access both the outer $1 and the inner $1 in localMax?
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote:
On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim
Grøstad wrote:
How about just having numbered parameters like this:
{ $2 < ($1*$2) }
What about this situation?
[[1, 2], [3, 4], [5, 6]].reduce!{
auto localMax = { $1 > $2 ? $1 : $2; }
auto first = $1.reduce!localMax;
auto second = $2.reduce!localMax;
return first > second ? first : second;
}
How can the compiler tell which $1 and $2 is which? What if one
wants to access both the outer $1 and the inner $1 in localMax?
Should be `return first > second ? $1 : $2`, but you get the idea.
Re: Member function pointers
On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim Grøstad wrote: On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir Panteleev wrote: Heh. My fault. Fixed (though it'll stick for that post in some views). Now the main index says: "Unexpected end of input when converting from type string to type long". Doesn't happen here, so that's something local to you, almost surely unrelated to the above. Try clearing your cookies.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 19:37:53 UTC, Ola Fosheim
Grøstad wrote:
How about just having numbered parameters like this:
{ $2 < ($1*$2) }
The string lambdas Phobos supports basically does this:
`b < a*b`
would work in there. These are falling out of favor with the new
syntax in the language, but they are still supported by most the
library.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 20:51:18 UTC, Adam D. Ruppe wrote: The string lambdas Phobos supports basically does this: `b < a*b` would work in there. These are falling out of favor with the new syntax in the language, but they are still supported by most the library. Isn't that a string mixin? Or?
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 20:10:49 UTC, Meta wrote: How can the compiler tell which $1 and $2 is which? What if one wants to access both the outer $1 and the inner $1 in localMax? If there is a conflict you should use a regular lambda on the outer one?
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote: If there is a conflict you should use a regular lambda on the outer one? You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it.
Re: Member function pointers
On Thursday, 10 September 2015 at 20:15:15 UTC, Vladimir Panteleev wrote: On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim Grøstad wrote: On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir Panteleev wrote: Heh. My fault. Fixed (though it'll stick for that post in some views). Now the main index says: "Unexpected end of input when converting from type string to type long". Doesn't happen here, so that's something local to you, almost surely unrelated to the above. Try clearing your cookies. Request URL:http://forum.dlang.org/ Request Method:GET Status Code:500 Internal Server Error
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote: On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote: If there is a conflict you should use a regular lambda on the outer one? You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it. Yes, it is usually it is a bad idea to have many ways to do things. A numbered schema probably should only be used in an innermost scope as a single expression, so if you see "$1" you know the definition stops at the brackets. Apropos one way of doing things: http://www.ozonehouse.com/mark/periodic/ :D
Re: Member function pointers
On Thursday, 10 September 2015 at 21:24:17 UTC, Ola Fosheim Grøstad wrote: On Thursday, 10 September 2015 at 20:15:15 UTC, Vladimir Panteleev wrote: On Thursday, 10 September 2015 at 19:40:02 UTC, Ola Fosheim Grøstad wrote: On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir Panteleev wrote: Heh. My fault. Fixed (though it'll stick for that post in some views). Now the main index says: "Unexpected end of input when converting from type string to type long". Doesn't happen here, so that's something local to you, almost surely unrelated to the above. Try clearing your cookies. Request URL:http://forum.dlang.org/ Request Method:GET Status Code:500 Internal Server Error Doesn't happen here, so that's something local to you, almost surely unrelated to the above. Try clearing your cookies.
Re: Member function pointers
On Thursday, 10 September 2015 at 21:29:15 UTC, Vladimir Panteleev wrote: Doesn't happen here, so that's something local to you, almost surely unrelated to the above. Try clearing your cookies. Yes, it was caused by cookies, but it wasn't local since it returned a HTTP status 500. It happend on the web server.
Re: Better lambdas!!!!!!!!!!
On Thursday, 10 September 2015 at 21:03:12 UTC, Meta wrote: On Thursday, 10 September 2015 at 20:56:58 UTC, Ola Fosheim Grøstad wrote: If there is a conflict you should use a regular lambda on the outer one? You could, but then doesn't that defeat the point a bit? My example was off-the-cuff, but the point is that we already have a fairly concise lambda syntax, and adding a new type will mean that we have 4 different ways of expressing the same lambda function. It's just not really worth it. Clojure solved this by disallowing nesting lambdas-with-numbered-arguments: Clojure 1.7.0 user=> (#(+ %1 %2) 1 2) 3 user=> (#(#(+ %1 %2) %2 %1) 1 2) IllegalStateException Nested #()s are not allowed clojure.lang.LispReader$FnReader.invoke (LispReader.java:703) #object[clojure.core$_PLUS_ 0x10fde30a "clojure.core$_PLUS_@10fde30a"] CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %2 in this context, compiling:(NO_SOURCE_PATH:0:0) CompilerException java.lang.RuntimeException: Unable to resolve symbol: %1 in this context, compiling:(NO_SOURCE_PATH:0:0) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) 1 2 RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) Than again, Clojure never was a big advocate of the one-way-of-doing-things approach... At any rate, since string lambdas can usually be used in place of this syntax, and in the cases string lambdas can't be used(because you need something from the scope) it's not THAT hard to use proper lambdas - I see no reason to support it.
Re: Member function pointers
On Thursday, 10 September 2015 at 16:24:52 UTC, Vladimir Panteleev wrote: ... Heh. My fault. Fixed (though it'll stick for that post in some views). Correct a "D-Runtime" topic, please. It is not updated.
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess? You would be surprised at the number of folks who've made great enhancements, or contributions, to various open source projects over the decades that are not even 18. The beauty of open-source is that talent is no longer defined by your age, gender, or location, and is defined entirely by ability, and sometimes, the ability to conform to that open-sources' project standards / expectations. Age need no part in the equation ;)
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 18:21:32 UTC, NX wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... This might be true, however even small collections, run multiple times, can still sum to the total collection time, even if delayed. In video games, this becomes an issue: lag spikes every 5 seconds, or generally reduced frame-rate from 30 to 20 FPS. It does make a difference in the end game. In time sensitive trading data, there are scenarios in which a 1millisecond delay could cost a few penance, times however many shares you bought. The bottom line, is there's a reason even Java and C# aren't "widely" used in such time sensitive issues, because they're generally slower, than the old CBOL or newer technologies running on C or the likes. However, when once compares Java's or C#'s GC to D, the difference is so dramatic, it makes me say one thing: Is D's garbage collector really from the 90's? That's the level of thought and sophistication that went into it. That of the earliest GC from the 90's and early 2000's era. It's been almost 20 years. It's really time to catch up guys. There's really no excuse why D is still using a GC from an era almost 2 decades ago. The JDK has supported generational GC since 1.2 and parallel GC from (don't quote me) 1.4 or perhaps earlier. Parallel GC has been a feature of most modern languages for close to, if not exceeding, 10 years now. D is still using a basic GC that only saw light of day in Java a decade ago or longer. The more time that goes by, the better Java, C#, Pyhton, etc. get at Garbage Collection, and the changes in D have stalled. We are sinking in a boat fast. There was a lovely article by a fellow for his PhD on how D garbage collector was literally killing his JavaScript engine, using some 100X more GC time than Java would have, and he contemplated switching from D for that reason alone. That article, found on reddit, is what "made" the leadership for D consider a rewrite of the GC. Well one year on, and it still hasn't happened. That's very dismal progress for a very critical part of the puzzle. And @nogc is just a band-aid fix. Might as well go back to C or C++ and leave the silly @nogc behind with all it's weird integration rules when working around managed memory. ~Peace
Re: Looking for someone that could work on 32 bits support for SDC
On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote: All is in the title. ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are valuable targets IMO. I can provide support, but I just don't have the bandwidth to pull it by myself. If someone could step up, that'd be great. I'd love to see MIPS support myself. It may be against my better judgment, but I'm more than willing t assist you on this. Care to elaborate on the more precise drill-down?
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 20:42:35 UTC, Laeeth Isharc wrote: On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: D has zero use in anything time sensitive. You mean, for example, like dealing with data for a billion customers and responding in a few hundred microseconds? ;) https://www.sociomantic.com/technology/ Case closed. SOMEBODY SAVE ME! D's garbage collector is a FAIL, and that makes the rest of the language a FAIL until it get's fixed. Have you tried using EMSI's containers with Andrei's allocator ? They use them in production, I gather. http://www.economicmodeling.com/2015/08/20/nyt-uses-emsi-data-to-help-bust-the-myth-of-the-creative-class-apocalypse/ https://github.com/economicmodeling/containers That's really interesting ;)
Re: Looking for someone that could work on 32 bits support for SDC
On Friday, 11 September 2015 at 01:12:21 UTC, Brandon Ragland wrote: On Wednesday, 9 September 2015 at 20:33:43 UTC, deadalnix wrote: All is in the title. ARM/Mips/pNaCl/WebAssembly require 32bits to work. These are valuable targets IMO. I can provide support, but I just don't have the bandwidth to pull it by myself. If someone could step up, that'd be great. I'd love to see MIPS support myself. It may be against my better judgment, but I'm more than willing t assist you on this. Care to elaborate on the more precise drill-down? Sure. First thing first, try to checkout the project and get it to build and pass the tests (well, some tests will fail, but you should get 0 regressions). Step 2 would be to modify the test runner to be able to run in 64 or 32 bits. Some tests will have a different result in 32 bits, notably the ones that use the pointer size somewhere. (tests/runner.d) Step 3 add a m32/m64 flags to SDC. It is using the getopt from phobos and that should be fairly straightforward. (sdc/src/main.d) Step 4 go through the codegen (libd-llvm) and update it to take the flag into account. (that's the big chunk). There may be some places in the frontend that assume 64 bits pointers, but if so, not many. Step 5 go through the runtime and do the same. There shouldn't be many here as well, but I'm not sure. In a first instance, I guess the right move is to target x86 because it is fairly close to x64 so it should work with minimal changes in the runtime. You can jump in IRC if you want to talk more about the details.
Re: std.allocator ready for some abuse
On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote: Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html Am I the only one seeing dead links?
