Re: MOOC course on Programming Languages taught by Dan Grossman
On Tuesday, 12 July 2016 at 22:21:46 UTC, bachmeier wrote: I took the first edition of this class, and it was the best MOOC I've taken (probably the only one for which I actually made it to the end). He is one of the few that does well with the format. Ditto. It was a great class. Note the statement "with a strong emphasis on functional programming" - as I recall, it was mostly a functional programming class, as you'd expect when the first two languages are Standard ML and Racket. Highly recommended for anyone that wants to go reasonably deep into functional programming. It's definitely NOT a beginning programming course. The functional aspect was the reason I took it. It was fun playing around with ML and Racket and I got lot out of it.
Re: MOOC course on Programming Languages taught by Dan Grossman
On Tuesday, 12 July 2016 at 20:47:12 UTC, Andrei Alexandrescu wrote: Dan Grossman, an exceptionally accomplished PL researcher from University of Washington, is teaching a MOOC on Coursera. The class starts on July 25 and is free unless you want accreditation. Highly recommended. https://www.coursera.org/learn/programming-languages Andrei I took the first edition of this class, and it was the best MOOC I've taken (probably the only one for which I actually made it to the end). He is one of the few that does well with the format. Note the statement "with a strong emphasis on functional programming" - as I recall, it was mostly a functional programming class, as you'd expect when the first two languages are Standard ML and Racket. Highly recommended for anyone that wants to go reasonably deep into functional programming. It's definitely NOT a beginning programming course.
MOOC course on Programming Languages taught by Dan Grossman
Dan Grossman, an exceptionally accomplished PL researcher from University of Washington, is teaching a MOOC on Coursera. The class starts on July 25 and is free unless you want accreditation. Highly recommended. https://www.coursera.org/learn/programming-languages Andrei
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid My report, Intel i5 6600K https://gist.github.com/cifvts/213a1e2ab564274b16a2294312cbd6f4
Re: new cpuid is ready for comments
On Tuesday, 12 July 2016 at 15:24:29 UTC, Guillaume Chatelet wrote: On Tuesday, 12 July 2016 at 13:23:46 UTC, Ilya Yaroshenko wrote: On Tuesday, 12 July 2016 at 12:46:26 UTC, Guillaume Chatelet wrote: On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are? Hello Guillaume, The data come from CPUID x86/x86_64 instruction. I have fixed bugs for AMD yesterday. Information for Intel and AMD processors should be reliable. But I am not sure about Cache and TLB information for virtual machines and other vendors. You can use cpuid.x86_any._cpuid [1] to get any information that is not presented. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#._cpuid Thx Ilya, I was discussing this a few colleagues. I'm quoting one of them here with his permission: "It doesn't seems that a userland library like this has any possibility to solve the root problem on Android/ARM. It's a twofold problem: 1. On ARM, the registers containing CPU identification and cache structure information, are privileged. See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html etc... (more such registers listed in the left pane on that page) Thus it is up to the operating system to expose this information to userspace. That takes us to the second part of the problem: 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 cpuid library code, it does not have an ARM implementation at the moment?" Thank you for the information, I have not know that registers are privileged on ARM! By "other vendors" I mean other x86 vendors listed in enum VendorIndex [1]. ARM is not supported, but API supports complex topology. So ARM direction is to receive approximate information from an OS, like from /proc/cpuinfo on Linux. Just CPU brand name with version is significant information for cache size. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#.VendorIndex
Re: new cpuid is ready for comments
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 cpuid library code, it does not have an ARM implementation at the moment?" According to docs: https://developer.android.com/ndk/guides/cpu-features.html Or, probably not recommended or supported: https://github.com/jooink/ndk-cpuid/blob/master/CPUIdApp/jni/com_jooink_experiments_android_ndk_cpuid_CPUIdApp.c
Re: new cpuid is ready for comments
On Tuesday, 12 July 2016 at 13:23:46 UTC, Ilya Yaroshenko wrote: On Tuesday, 12 July 2016 at 12:46:26 UTC, Guillaume Chatelet wrote: On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are? Hello Guillaume, The data come from CPUID x86/x86_64 instruction. I have fixed bugs for AMD yesterday. Information for Intel and AMD processors should be reliable. But I am not sure about Cache and TLB information for virtual machines and other vendors. You can use cpuid.x86_any._cpuid [1] to get any information that is not presented. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#._cpuid Thx Ilya, I was discussing this a few colleagues. I'm quoting one of them here with his permission: "It doesn't seems that a userland library like this has any possibility to solve the root problem on Android/ARM. It's a twofold problem: 1. On ARM, the registers containing CPU identification and cache structure information, are privileged. See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html etc... (more such registers listed in the left pane on that page) Thus it is up to the operating system to expose this information to userspace. That takes us to the second part of the problem: 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 cpuid library code, it does not have an ARM implementation at the moment?"
Re: new cpuid is ready for comments
On Tuesday, 12 July 2016 at 12:46:26 UTC, Guillaume Chatelet wrote: On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are? Hello Guillaume, The data come from CPUID x86/x86_64 instruction. I have fixed bugs for AMD yesterday. Information for Intel and AMD processors should be reliable. But I am not sure about Cache and TLB information for virtual machines and other vendors. You can use cpuid.x86_any._cpuid [1] to get any information that is not presented. [1] http://docs.cpuid.dlang.io/latest/cpuid_x86_any.html#._cpuid
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Hey Ilya, Quick question: where do the data come from/how reliable do you think they are?
Re: new cpuid is ready for comments
On Monday, 11 July 2016 at 16:30:44 UTC, Ilya Yaroshenko wrote: Hello :-) `cpuid` package is core.cpuid analog. It would be used by future D BLAS implementation. Why it is better? See https://github.com/libmir/cpuid#api-features https://github.com/libmir/cpuid#implementation-features https://issues.dlang.org/show_bug.cgi?id=16028 Please report your CPU (GitHub/Gist): ``` dub fetch cpuid dub test cpuid ``` ... AMD was not tested at all and I hope to see your reports. ARM contributors are wanted! Destroy! Best regards, Ilya Docs: http://docs.cpuid.dlang.io GitHub: https://github.com/libmir/cpuid Dub: cpuid Looks good! Here are my results (I added a `cat /proc/cpuinfo` for the record) https://gist.github.com/gchatelet/31a8cf41ba1d888c1efaef314d6a0c97
Re: DIP: Tail call optimization
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. In contrast to what many folks expect, TCO is affecting program semantics in a way that changes stack overflow to normal execution. Therefore it's not an optimization but part of semantics, and there should be a way to mark a call as a tail-call in any optimization level. It was a big road block for me when I tried to implement threaded-code interpreter, because it will stack overflow in debug mode. The proposal it's ready for merge on the new [DIPs repo](https://github.com/dlang/DIPs/pull/6) -- Dietrich
Re: DIP: Tail call optimization
On Monday, 11 July 2016 at 11:19:59 UTC, Dicebot wrote: D language authors don't want to enforce any code of conduct or moderation in the newsgroup which means certain personas have to be simply ignored. This is not a policy that will scale well. Ketmar's behaviour was badly out of line. People need to save the scathing pseudo-Linus stuff for the inner-circle rather than new comers.
