Re: D reaches 1000 questions on stackoverflow
On Saturday, 17 August 2013 at 01:05:18 UTC, Tyler Jameson Little wrote: [..] It's true though that there are much better answers (and questions) here than on SO, and I'm beginning to shift my search from Google to the forum search, but this isn't something a newcomer will know to do, especially since many other languages put more emphasis on SO. Speaking of searching on this forum: in Chrome, the search box in top right corner of this page has a peculiar feature of being mostly a clickable link item to forum.dlang.org. Only a small fragment (about 25%) shows a text cursor. Sorry for posting this issue here, but I didn't find a suitable category in forum index. Maybe one could be created - Forum use issues?
Re: D reaches 1000 questions on stackoverflow
On Saturday, 17 August 2013 at 09:21:27 UTC, Paul Jurczak wrote: On Saturday, 17 August 2013 at 01:05:18 UTC, Tyler Jameson Little wrote: [..] It's true though that there are much better answers (and questions) here than on SO, and I'm beginning to shift my search from Google to the forum search, but this isn't something a newcomer will know to do, especially since many other languages put more emphasis on SO. Speaking of searching on this forum: in Chrome, the search box in top right corner of this page has a peculiar feature of being mostly a clickable link item to forum.dlang.org. Only a small fragment (about 25%) shows a text cursor. Sorry for posting this issue here, but I didn't find a suitable category in forum index. Maybe one could be created - Forum use issues? This is dependant on the size of your window. If your window is so narrow that the title is overlapping the search box then the title takes precedence, which is not desirable. You could create an issue here to report it: https://github.com/CyberShadow/DFeed
Re: DDT 0.7.0 released
On 16/08/2013 12:08, Jacob Carlborg wrote: On 2013-08-15 21:20, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. I downloaded the standard version of Kepler. Then I followed the installation instructions. But after the restart I don't see anything related to DDT/D in the preferences. Someone else had a similar problem, a good guess is that you're running with a 1.6 JVM, you need a 1.7 JVM. -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 16/08/2013 22:05, Piotr Szturmaj wrote: I've pointed path to the DMD compiler executable but the library paths weren't filled automatically. Maybe it's a bug? (eclipse CDT Kepler) Yeah, it is a bug. It was a new feature in this release, but I made a mistake creating the test case (and then the implementation too) http://code.google.com/p/ddt/issues/detail?id=3can=1 -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 16/08/2013 20:22, Andrei Alexandrescu wrote: On 8/16/13 12:14 PM, Bruno Medeiros wrote: I've updated the Features wiki with new screenshots, and revised the text to be more clear: http://code.google.com/p/ddt/wiki/Features (like removing the A JDT-like project model references which actually doesn't mean anything to people who are not familiar with JDT) Looking good! Should I shoot a post to reddit on Monday? Andrei Sure. -- Bruno Medeiros - Software Engineer
What's the $(D) macro? WAS: Re: DDT 0.7.0 released
On 16/08/2013 20:14, Bruno Medeiros wrote: Found a bug in the meanwhile, the DDoc viewer is not rendering $(D) DDoc macros. Speaking of which, where does that macro come from? Seems similar to the D_CODE macro, but it's not documented as one of the default DDoc macros, nor could I find it as a custom defined macro. -- Bruno Medeiros - Software Engineer
Re: D at University of Minnesota
What happened is that I unclear what the state of play is; I am not asserting the wrongness of TDPL. Still, I am reassured by your responses. Hi Carl -- TDPL is for the most part in good shape. There are a few inaccuracies, but I'd say most concern corner cases that are unlike to deter the learning process. You may want to encourage students to interact with us here, or write me email directly if they have any questions. I'd be very glad to help them. Hello Andrei, Ali, Well, CS2 in D is over, and grades are in. Being a summer course it was conducted at twice the speed as in a regular semester. Being the U of M there's enormous variation in background, current experience and ability, potential, etcetera etcetera, among students in the course. In the end registration had stabilized at 55 before the course started and (unusually) all of them finished it. There were a number of exceptional students of little experience in the class. There were also a number of students in the class with C++ experience that was more than beginner level. A majority of the students had come from the CS1 course here which is Scheme based, and so they had experience mainly with functions, recursion and singly-linked lists. My main observation is that there was a significantly greater level of inspiration engendered by using D as opposed to the usual alternatives. I and my TA saw a lot of the students in the lab and in office hours, and I made an effort to find out their reactions to using D, and they were very positive, especially so among those in about the top 2/3 or so of the class. In our abstract data type implementations we made good use of D's superb dynamic arrays, and associative arrays, and we used both classes and structs; we made prolific use of operator overloading including signature constraints, and in an extra credit exercise we even had them write a simple opApply. We used classes to implement linked structures except at the end of the course. When I say we I mean that while I discussed topics on all scales and from abstract to concrete in lecture, the TA and I had them actively learn everything done via a long sequence of problems to solve in D, and some things were left to the lab. At the end of the course I introduced pointers (to structs or to C-style arrays), and I discussed the connection between D and C. I also explained in detail how they could cripple their use of D and with small changes find themselves writing Java, and I gave an introductory discussion of the relationship of D to C++. In doing this I was pointing at their future courses: Java is the default language for a course here; in the machine architecture course they will use C; in the Program Development course they will use C++. Language related issues that caught a significant minority of students out when solving the course's problems, despite explanation in lecture and lab, include the following. First up, no default constructor for structs, and what to do about it. This was complicated by the fact that in the Windows implementation of DMD it was possible to assign e.g. a new array directly to a struct variable, apparently contradicting the dictum of a fixed .init for structs. This lead to some writing code that needed non-trivial changes to run on the lab's Ubuntu machines. Second, the complexities of opCmp for classes, where a cast from Object is needed. We'd covered inheritance, but the need for this cast struck some as an unexpected deficiency in D, and we had to explain this many times to individual students struggling to make their code compile. Overall, a significant number of students made this class a game-changing one for themselves, and were inspired and stimulated to learn more about algorithms and data structures, and to learn more about D. For example, we had them implement associative arrays as linked lists of pairs, then as hash tables using the previous implementation to do the work, and quite separately as a binary search trees. They had already implemented binary search trees with a single type parameter, and now having that type be a struct parameterized by a pair of types they could use the earlier solution to do the work. The result was a lot of very natural data abstraction, and, most exciting, types that looked built-in. This was very gratifying to many students. And, I should mention that the presence of operator overloading via opIndexAssign kept the associative array solutions simple enough for all students at this level, unlike what C++ would necessitate. Ali Çehreli's tutorial played a central role supporting students especially during the first half of the course --- without it the course simply would not have worked, so many thanks Ali --- and an important part of that is its linearity --- it can be read with only backward dependencies. This meant that with hard work even students of little experience and only moderate
Re: D at University of Minnesota
On Saturday, 17 August 2013 at 15:22:26 UTC, Carl Sturtivant wrote: Hello Andrei, Ali, Well, CS2 in D is over, and grades are in. Being a summer course it was conducted at twice the speed as in a regular semester. [...] That is truly awesome news !
SIMD implementation of dot-product. Benchmarks
http://spiceandmath.blogspot.ru/2013/08/simd-implementation-of-dot-product_17.html Ilya
Re: SIMD implementation of dot-product. Benchmarks
On Saturday, 17 August 2013 at 18:50:15 UTC, Ilya Yaroshenko wrote: http://spiceandmath.blogspot.ru/2013/08/simd-implementation-of-dot-product_17.html Ilya Nice, that's a good speedup. BTW: -march=native automatically implies -mtune=native
Re: SIMD implementation of dot-product. Benchmarks
BTW: -march=native automatically implies -mtune=native Thanks, I`ll remove mtune)
Re: SIMD implementation of dot-product. Benchmarks
On Saturday, 17 August 2013 at 19:24:52 UTC, Ilya Yaroshenko wrote: BTW: -march=native automatically implies -mtune=native Thanks, I`ll remove mtune) It would be really interesting if you could try writing the same code in c, both a scalar version and a version using gcc's vector instrinsics, to allow us to compare performance and identify areas for D to improve.
Re: D reaches 1000 questions on stackoverflow
On Saturday, 17 August 2013 at 11:00:20 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 09:21:27 UTC, Paul Jurczak wrote: On Saturday, 17 August 2013 at 01:05:18 UTC, Tyler Jameson Little wrote: [..] It's true though that there are much better answers (and questions) here than on SO, and I'm beginning to shift my search from Google to the forum search, but this isn't something a newcomer will know to do, especially since many other languages put more emphasis on SO. Speaking of searching on this forum: in Chrome, the search box in top right corner of this page has a peculiar feature of being mostly a clickable link item to forum.dlang.org. Only a small fragment (about 25%) shows a text cursor. Sorry for posting this issue here, but I didn't find a suitable category in forum index. Maybe one could be created - Forum use issues? This is dependant on the size of your window. If your window is so narrow that the title is overlapping the search box then the title takes precedence, which is not desirable. You could create an issue here to report it: https://github.com/CyberShadow/DFeed Thanks, that's exactly what is happening, except I wouldn't call my window narrow - it is 1200 pixels wide, but 1600 pixels high. I will report this issue.
Re: SIMD implementation of dot-product. Benchmarks
Ilya Yaroshenko: http://spiceandmath.blogspot.ru/2013/08/simd-implementation-of-dot-product_17.html From the blog post: Compile fast_math code from other program separately and then link it. This is easy solution. However this is a step back to C. To introduce a @fast_math attribute. This is hard to realize. But I hope this will be done for future compilers. One solution is to copy one of the features of Lisp, that is offer an annotation to specify different compilation switches for functions. Since some time it's present in GNU-C too: http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas Bye, bearophile
Re: D reaches 1000 questions on stackoverflow
On Saturday, 17 August 2013 at 20:12:49 UTC, Paul Jurczak wrote: On Saturday, 17 August 2013 at 11:00:20 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 09:21:27 UTC, Paul Jurczak wrote: On Saturday, 17 August 2013 at 01:05:18 UTC, Tyler Jameson Little wrote: [..] It's true though that there are much better answers (and questions) here than on SO, and I'm beginning to shift my search from Google to the forum search, but this isn't something a newcomer will know to do, especially since many other languages put more emphasis on SO. Speaking of searching on this forum: in Chrome, the search box in top right corner of this page has a peculiar feature of being mostly a clickable link item to forum.dlang.org. Only a small fragment (about 25%) shows a text cursor. Sorry for posting this issue here, but I didn't find a suitable category in forum index. Maybe one could be created - Forum use issues? This is dependant on the size of your window. If your window is so narrow that the title is overlapping the search box then the title takes precedence, which is not desirable. You could create an issue here to report it: https://github.com/CyberShadow/DFeed Thanks, that's exactly what is happening, except I wouldn't call my window narrow - it is 1200 pixels wide, but 1600 pixels high. I will report this issue. https://github.com/CyberShadow/DFeed/pull/15
Re: SIMD implementation of dot-product. Benchmarks
It doesn't look like you account for alignment. This is basically not-portable (I doubt unaligned loads in this context are faster than performing scalar operations), and possibly inefficient on x86 too. To make it account for potentially random alignment will be awkward, but it might be possible to do efficiently. On 18 August 2013 04:50, Ilya Yaroshenko ilyayaroshe...@gmail.com wrote: http://spiceandmath.blogspot.**ru/2013/08/simd-** implementation-of-dot-product_**17.htmlhttp://spiceandmath.blogspot.ru/2013/08/simd-implementation-of-dot-product_17.html Ilya
Re: Rust vs Dlang
On Saturday, 16 March 2013 at 14:42:58 UTC, Suliman wrote:
Hi folks! I had wrote small article about Rust vs D. I hope
that you will like it!
http://versusit.org/rust-vs-d
I don't know if you still follow this, but there's a typo here:
Now, let’s see, how the code, outputting the word Hello 10
times, will look. In Rust it will look like this:
fn main() {
for 100.times {
...
Should be:
...
for 10.times {
...
Also, the formatting still sucks and imports are missing for the
D code, whereas imports are verbosely stated in Rust. FWIW,
std::io::println can be stated as just println, since it's
available by default. Don't know if this was the case when you
wrote the post though...
Also, you don't mention the difference between D and Rust in
switch statements (FWIW, Rust doesn't have switch statements,
they're now match statements, which are closer to haskell's
case statements than D's switch, because D's switch has optional
fallthrough (goto case;) and Rust has no fallthrough.
Also, I second the objection to your exception example. D does
have exceptions and there are some very important differences
between them and Rust's exception handling (which is more like
Go's recover() than D's catch).
Re: SIMD implementation of dot-product. Benchmarks
On Sunday, 18 August 2013 at 01:53:53 UTC, Manu wrote: It doesn't look like you account for alignment. This is basically not-portable (I doubt unaligned loads in this context are faster than performing scalar operations), and possibly inefficient on x86 too. dotProduct uses unaligned loads (__builtin_ia32_loadups256, __builtin_ia32_loadupd256) and it up to 21 times faster then trivial scalar version. Why unaligned loads is not-portable and inefficient? To make it account for potentially random alignment will be awkward, but it might be possible to do efficiently. Did you mean use unaligned loads or prepare data for alignment loads at the beginning of function?
Re: SIMD implementation of dot-product. Benchmarks
On Saturday, 17 August 2013 at 19:38:52 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 19:24:52 UTC, Ilya Yaroshenko wrote: BTW: -march=native automatically implies -mtune=native Thanks, I`ll remove mtune) It would be really interesting if you could try writing the same code in c, both a scalar version and a version using gcc's vector instrinsics, to allow us to compare performance and identify areas for D to improve. I am lazy ) I have looked at assembler code: float, scalar (main loop): .L191: vmovss xmm1, DWORD PTR [rsi+rax*4] vfmadd231ss xmm0, xmm1, DWORD PTR [rcx+rax*4] add rax, 1 cmp rax, rdi jne .L191 float, vector (main loop): .L2448: vmovups ymm5, YMMWORD PTR [rax] sub rax, -128 sub r11, -128 vmovups ymm4, YMMWORD PTR [r11-128] vmovups ymm6, YMMWORD PTR [rax-96] vmovups ymm7, YMMWORD PTR [r11-96] vfmadd231ps ymm3, ymm5, ymm4 vmovups ymm8, YMMWORD PTR [rax-64] vmovups ymm9, YMMWORD PTR [r11-64] vfmadd231ps ymm0, ymm6, ymm7 vmovups ymm10, YMMWORD PTR [rax-32] vmovups ymm11, YMMWORD PTR [r11-32] cmp rdi, rax vfmadd231ps ymm2, ymm8, ymm9 vfmadd231ps ymm1, ymm10, ymm11 ja .L2448 float, vector (full): https://gist.github.com/9il/6258443 It is pretty optimized) Best regards Ilya
Re: SIMD implementation of dot-product. Benchmarks
On 18 August 2013 14:39, Ilya Yaroshenko ilyayaroshe...@gmail.com wrote: On Sunday, 18 August 2013 at 01:53:53 UTC, Manu wrote: It doesn't look like you account for alignment. This is basically not-portable (I doubt unaligned loads in this context are faster than performing scalar operations), and possibly inefficient on x86 too. dotProduct uses unaligned loads (__builtin_ia32_loadups256, __builtin_ia32_loadupd256) and it up to 21 times faster then trivial scalar version. Why unaligned loads is not-portable and inefficient? x86 is the only arch that can perform an unaligned load. And even on x86 (many implementations) it's not very efficient. To make it account for potentially random alignment will be awkward, but it might be possible to do efficiently. Did you mean use unaligned loads or prepare data for alignment loads at the beginning of function? I mean to only use aligned loads, in whatever way that happens to work out. The hard case is when the 2 arrays have different start offsets. Otherwise you need to wrap your code in a version(x86) block.
Re: SIMD implementation of dot-product. Benchmarks
On Sunday, 18 August 2013 at 05:07:12 UTC, Manu wrote: On 18 August 2013 14:39, Ilya Yaroshenko ilyayaroshe...@gmail.com wrote: On Sunday, 18 August 2013 at 01:53:53 UTC, Manu wrote: It doesn't look like you account for alignment. This is basically not-portable (I doubt unaligned loads in this context are faster than performing scalar operations), and possibly inefficient on x86 too. dotProduct uses unaligned loads (__builtin_ia32_loadups256, __builtin_ia32_loadupd256) and it up to 21 times faster then trivial scalar version. Why unaligned loads is not-portable and inefficient? x86 is the only arch that can perform an unaligned load. And even on x86 (many implementations) it's not very efficient. :( To make it account for potentially random alignment will be awkward, but it might be possible to do efficiently. Did you mean use unaligned loads or prepare data for alignment loads at the beginning of function? I mean to only use aligned loads, in whatever way that happens to work out. The hard case is when the 2 arrays have different start offsets. Otherwise you need to wrap your code in a version(x86) block. Thanks!
Re: SIMD implementation of dot-product. Benchmarks
movups is not good. It'll be a lot faster (and portable) if you use movaps. Process looks something like: * do the first few from a[0] until a's alignment interval as scalar * load the left of b's aligned pair * loop for each aligned vector in a - load a[n..n+4] aligned - load the right of b's pair - combine left~right and shift left to match elements against a - left = right * perform stragglers as scalar Your benchmark is probably misleading too, because I suspect you are passing directly alloc-ed arrays into the function (which are 16 byte aligned). movups will be significantly slower if the pointers supplied are not 16 byte aligned. Also, results vary significantly between chip manufacturers and revisions. On 18 August 2013 14:55, Ilya Yaroshenko ilyayaroshe...@gmail.com wrote: On Saturday, 17 August 2013 at 19:38:52 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 19:24:52 UTC, Ilya Yaroshenko wrote: BTW: -march=native automatically implies -mtune=native Thanks, I`ll remove mtune) It would be really interesting if you could try writing the same code in c, both a scalar version and a version using gcc's vector instrinsics, to allow us to compare performance and identify areas for D to improve. I am lazy ) I have looked at assembler code: float, scalar (main loop): .L191: vmovss xmm1, DWORD PTR [rsi+rax*4] vfmadd231ss xmm0, xmm1, DWORD PTR [rcx+rax*4] add rax, 1 cmp rax, rdi jne .L191 float, vector (main loop): .L2448: vmovups ymm5, YMMWORD PTR [rax] sub rax, -128 sub r11, -128 vmovups ymm4, YMMWORD PTR [r11-128] vmovups ymm6, YMMWORD PTR [rax-96] vmovups ymm7, YMMWORD PTR [r11-96] vfmadd231ps ymm3, ymm5, ymm4 vmovups ymm8, YMMWORD PTR [rax-64] vmovups ymm9, YMMWORD PTR [r11-64] vfmadd231ps ymm0, ymm6, ymm7 vmovups ymm10, YMMWORD PTR [rax-32] vmovups ymm11, YMMWORD PTR [r11-32] cmp rdi, rax vfmadd231ps ymm2, ymm8, ymm9 vfmadd231ps ymm1, ymm10, ymm11 ja .L2448 float, vector (full): https://gist.github.com/9il/**6258443https://gist.github.com/9il/6258443 It is pretty optimized) Best regards Ilya
Re: SIMD implementation of dot-product. Benchmarks
On Sunday, 18 August 2013 at 05:26:00 UTC, Manu wrote: movups is not good. It'll be a lot faster (and portable) if you use movaps. Process looks something like: * do the first few from a[0] until a's alignment interval as scalar * load the left of b's aligned pair * loop for each aligned vector in a - load a[n..n+4] aligned - load the right of b's pair - combine left~right and shift left to match elements against a - left = right * perform stragglers as scalar Your benchmark is probably misleading too, because I suspect you are passing directly alloc-ed arrays into the function (which are 16 byte aligned). movups will be significantly slower if the pointers supplied are not 16 byte aligned. Also, results vary significantly between chip manufacturers and revisions. I`ll try =). Thanks you very math!
Re: GPGPUs
On Saturday, 17 August 2013 at 00:53:39 UTC, luminousone wrote:
You can't mix cpu and gpu code, they must be separate.
H'okay, let's be clear here. When you say 'mix CPU and GPU code',
you mean you can't mix them physically in the compiled executable
for all currently extant cases. They aren't the same. I agree
with that. That said, this doesn't preclude having CUDA-like
behavior where small functions could be written that don't
violate the constraints of GPU code and simultaneously has
semantics that could be executed on the CPU, and where such small
functions are then allowed to be called from both CPU and GPU
code.
However this still has problems of the cpu having to generate
CPU code from the contents of gpu{} code blocks, as the GPU is
unable to allocate memory, so for example ,
gpu{
auto resultGPU = dot(c, cGPU);
}
likely either won't work, or generates an array allocation in
cpu code before the gpu block is otherwise ran.
I wouldn't be so negative with the 'won't work' bit, 'cuz frankly
the 'or' you wrote there is semantically like what OpenCL and
CUDA do anyway.
Also how does that dot product function know the correct index
range to run on?, are we assuming it knows based on the length
of a?, while the syntax,
c[] = a[] * b[];
is safe for this sort of call, a function is less safe todo
this with, with function calls the range needs to be told to
the function, and you would call this function without the
gpu{} block as the function itself is marked.
auto resultGPU = dot$(0 ..
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);
I think it was mentioned earlier that there should be, much like
in OpenCL or CUDA, builtins or otherwise available symbols for
getting the global identifier of each work-item, the work-group
size, global size, etc.
Remember with gpu's you don't send instructions, you send whole
programs, and the whole program must finish before you can move
onto the next cpu instruction.
I disagree with the assumption that the CPU must wait for the GPU
while the GPU is executing. Perhaps by default the behavior could
be helpful for sequencing global memory in the GPU with CPU
operations, but it's not a necessary behavior (see OpenCL and
it's, in my opinion, really nice queuing mechanism).
=== Another thing...
I'm with luminousone's suggestion for some manner of function
attribute, to the tune of several metric tonnes of chimes. Wind
chimes. I'm supporting this suggestion with at least a metric
tonne of wind chimes.
*This* (and some small number of helpers), rather than
straight-up dumping a new keyword and block type into the
language. I really don't think D *needs* to have this any lower
level than a library based solution, because it already has the
tools to make it ridiculously more convenient than C/C++ (not
necessarily as much as CUDA's totally separate program nvcc does,
but a huge amount).
ex.
@kernel auto myFun(BufferT)(BufferT glbmem)
{
// brings in the kernel keywords and whatnot depending
__FUNCTION__
// (because mixins eval where they're mixed in)
mixin KernelDefs;
// ^ and that's just about all the syntactic noise, the rest
uses mixed-in
// keywords and the glbmem object to define several
expressions that
// effectively record the operations to be performed into the
return type
// assignment into global memory recovers the expression type
in the glbmem.
glbmem[glbid] += 4;
// This assigns the *expression* glbmem[glbid] to val.
auto val = glbmem[glbid];
// Ignoring that this has a data race, this exemplifies
recapturing the
// expression 'val' (glbmem[glbid]) in glbmem[glbid+1].
glbmem[glbid+1] = val;
return glbmem; /// I lied about the syntactic noise. This is
the last bit.
}
Now if you want to, you can at runtime create an OpenCL-code
string (for example) by passing a heavily metaprogrammed type in
as BufferT. The call ends up looking like this:
auto promisedFutureResult = Gpu.call!myFun(buffer);
The kernel compilation (assuming OpenCL) is memoized, and the
promisedFutureResult is some asynchronous object that implements
concurrent programming's future (or something to that extent).
For convenience, let's say that it blocks on any read other than
some special poll/checking mechanism.
The constraints imposed on the kernel functions is generalizable
to even execute the code on the CPU, as the launching call (
Gpu.call!myFun(buffer) ) can, instead of using an
expression-buffer, just pass a normal array in and have the
proper result pop out given some interaction between the
identifiers mixed in by KernelDefs and the launching caller (ex.
using a loop).
With CTFE, this method *I think* can also generate the code at
compile time given the proper kind of
expression-type-recording-BufferT.
Again, though, this requires a significant amount of
metaprogramming, heavy abuse of auto, and... did i mention a
significant amount of
[Somewhat Off-Topic] A Phobos Wallpaper
I took a break from doing useful things, and made this: http://imgur.com/Bro0DYT Infer what you will from the frequencies of certain keywords and identifiers.
Re: GPGPUs
On Saturday, 17 August 2013 at 00:53:39 UTC, luminousone wrote:
You can't mix cpu and gpu code, they must be separate.
H'okay, let's be clear here. When you say 'mix CPU and GPU code',
you mean you can't mix them physically in the compiled executable
for all currently extant cases. They aren't the same. I agree
with that.
That said, this doesn't preclude having CUDA-like behavior where
small functions could be written that don't violate the
constraints of GPU code and simultaneously has semantics that
could be executed on the CPU, and where such small functions are
then allowed to be called from both CPU and GPU code.
However this still has problems of the cpu having to generate
CPU code from the contents of gpu{} code blocks, as the GPU is
unable to allocate memory, so for example ,
gpu{
auto resultGPU = dot(c, cGPU);
}
likely either won't work, or generates an array allocation in
cpu code before the gpu block is otherwise ran.
I'm fine with an array allocation. I'd 'prolly have to do it
anyway.
Also how does that dot product function know the correct index
range to run on?, are we assuming it knows based on the length
of a?, while the syntax,
c[] = a[] * b[];
is safe for this sort of call, a function is less safe todo
this with, with function calls the range needs to be told to
the function, and you would call this function without the
gpu{} block as the function itself is marked.
auto resultGPU = dot$(0 ..
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);
'Dat's a point.
Remember with gpu's you don't send instructions, you send whole
programs, and the whole program must finish before you can move
onto the next cpu instruction.
I disagree with the assumption that the CPU must wait for the GPU
while the GPU is executing. Perhaps by default the behavior could
be helpful for sequencing global memory in the GPU with CPU
operations, but it's not a *necessary* behavior.
Well, I disagree with the assumption assuming said assumption is
being made and I'm not just misreading that bit. :-P
=== Another thing...
I'm with luminousone's suggestion for some manner of function
attribute, to the tune of several metric tonnes of chimes. Wind
chimes. I'm supporting this suggestion with at least a metric
tonne of wind chimes.
I'd prefer this (and some small number of helpers) rather than
straight-up dumping a new keyword and block type into the
language. I really don't think D *needs* to have this any lower
level than a library based solution, because it already has the
tools to make it ridiculously more convenient than C/C++ (not
necessarily as much as CUDA's totally separate program nvcc does,
but a huge amount).
ex.
@kernel auto myFun(BufferT)(BufferT glbmem)
{
// brings in the kernel keywords and whatnot depending
__FUNCTION__
// (because mixins eval where they're mixed in)
mixin KernelDefs;
// ^ and that's just about all the syntactic noise, the rest
uses mixed-in
// keywords and the glbmem object to define several
expressions that
// effectively record the operations to be performed into the
return type
// assignment into global memory recovers the expression type
in the glbmem.
glbmem[glbid] += 4;
// This assigns the *expression* glbmem[glbid] to val.
auto val = glbmem[glbid];
// Ignoring that this has a data race, this exemplifies
recapturing the
// expression 'val' (glbmem[glbid]) in glbmem[glbid+1].
glbmem[glbid+1] = val;
return glbmem; /// I lied about the syntactic noise. This is
the last bit.
}
Now if you want to, you can at runtime create an OpenCL-code
string (for example) by passing a heavily metaprogrammed type in
as BufferT. The call ends up looking like this:
auto promisedFutureResult = Gpu.call!myFun(buffer);
The kernel compilation (assuming OpenCL) is memoized, and the
promisedFutureResult is some asynchronous object that implements
concurrent programming's future (or something to that extent).
For convenience, let's say that it blocks on any read other than
some special poll/checking mechanism.
The constraints imposed on the kernel functions is generalizable
to even execute the code on the CPU, as the launching call (
Gpu.call!myFun(buffer) ) can, instead of using an
expression-buffer, just pass a normal array in and have the
proper result pop out given some interaction between the
identifiers mixed in by KernelDefs and the launching caller (ex.
using a loop).
Alternatively to returning the captured expressions, the argument
glbmem could have been passed ref, and the same sort of
expression capturing could occur. Heck, more arguments could've
been passed, too, this doesn't require there to be one single
argument representing global memory.
With CTFE, this method *I think* can also generate the code at
compile time given the proper kind of
expression-type-recording-BufferT.
Again, though, all this requires a significant amount of
metaprogramming,
Re: A Discussion of Tuple Syntax
On Saturday, 17 August 2013 at 05:48:47 UTC, captaindet wrote: not sure what we are talking about here, new syntax for a) TypeTuple (that would be my best guess but i am not sure) b) std.typecons.Tuple c) both, a unified syntax the DIP is not completely clear about this either. First and foremost, a new syntax for std.typecons.Tuple. Creating tuple literals - #(1, a, false), pattern matching on tuples - switch (#(1, 2)), and destructuring of tuples - #(a, b) = #(1, 2). A good question is whether this syntax can (and more importantly, should) be used for TypeTuples as well. TypeTuples are poorly named and not at all similar to Tuple, so it doesn't make much sense to give them both the same syntax. Also, I can't see TypeTuple seeing nearly as much use as Tuple, so it may be better to introduce the new syntax for Tuple, and keep TypeTuple as-is. only case (a) is hot at the moment and i fell into some related pits recently myself. so i'd love to have a better syntax, one that makes the dirty hack (status quo) a proper part of the language - as it is widely used already and very powerful. What TypeTuple gives you access to is the compiler tuple type that it uses for function argument lists and other things. I wouldn't really call it a dirty hack. The two most confusing things about TypeTuple, I think, is the auto-expansion, and the fact that it can contain both types and values. i am curious too if ..(..) constructs are completely out of the question. if not, i would suggest as shorthand: !(a,b) this reminds of template instantiation and is exactly how the awkwardly/confusingly named TypeTuple is realized now, as an alias to its own template arguments. Unfortunately, that won't work, as the value of this expression is already well-defined in the current language. A list of comma-separated expressions means that each is evaluated from left to right, and then the result of the entire expression is the result of the rightmost expression, e.g.: auto a = true; auto b = false; //Evaluate a, then b. The result of the expression //in the brackets is b. Then the ! gets applied to b auto x = !(a, b); assert(x == true); //Passes if we need a name for it, it should not remind at all of 'tuple' - since there is also the completely unrelated std.typecons.Tuple. a more verbose/explicit suggestion would be symbols(a,b) I 100% agree that TypeTuple needs a better name. A couple other suggestions were put forward as well in the other tuple thread currently active.
Re: [Somewhat Off-Topic] A Phobos Wallpaper
On Saturday, 17 August 2013 at 05:57:08 UTC, Brian Schott wrote: I took a break from doing useful things, and made this: http://imgur.com/Bro0DYT Infer what you will from the frequencies of certain keywords and identifiers. Cool. What is the input data? Phobos? I find it *awesome* that assert is one of the most used keywords.
Re: [Somewhat Off-Topic] A Phobos Wallpaper
Am 17.08.2013 07:57, schrieb Brian Schott: I took a break from doing useful things, and made this: http://imgur.com/Bro0DYT Infer what you will from the frequencies of certain keywords and identifiers. Cool idea! But even considering that std.datetime is a monster module, can it really be true that Date is as frequent as assert throughout the code base? It somehow looks like _only_ std.datetime made it into the final statistic.
Re: [Somewhat Off-Topic] A Phobos Wallpaper
On Saturday, August 17, 2013 09:25:41 Sönke Ludwig wrote: Am 17.08.2013 07:57, schrieb Brian Schott: I took a break from doing useful things, and made this: http://imgur.com/Bro0DYT Infer what you will from the frequencies of certain keywords and identifiers. Cool idea! But even considering that std.datetime is a monster module, can it really be true that Date is as frequent as assert throughout the code base? It somehow looks like _only_ std.datetime made it into the final statistic. It's due to how many unit tests std.datetime has. There are a _lot_ of assertions in there. I reworked some of them to loop more rather than just be a straight set of tests, but I still have a long way to go, so assert and assertPred are used a _lot_ in that module (and even after that refactoring is done, there will still be plenty of assertions - just not quite so many). If the unit tests weren't counted, std.datetime would probably be a much, much smaller portion of the count (something like 3/4 of that module is unit tests). - Jonathan M Davis
Re: [Somewhat Off-Topic] A Phobos Wallpaper
On Saturday, 17 August 2013 at 07:25:53 UTC, Sönke Ludwig wrote: Am 17.08.2013 07:57, schrieb Brian Schott: I took a break from doing useful things, and made this: http://imgur.com/Bro0DYT Infer what you will from the frequencies of certain keywords and identifiers. Cool idea! But even considering that std.datetime is a monster module, can it really be true that Date is as frequent as assert throughout the code base? It somehow looks like _only_ std.datetime made it into the final statistic. I ran through my code again, increasing the number of words that made it to the final list by quite a bit. (For a minute or two I thought you were right and that I had a bug) This is actually all of Phobos. EmailStatusCode and CodePointSet aren't in datetime.
proposal: better stack trace support could advantageously replace implicit __FILE__/__LINE__ parameters
Currently a number of functions in phobos have a syntax such as: 'T enforce(T, Dg, string file = __FILE__, size_t line = __LINE__)' so as to show informative messages when an exception is raised, etc. There's a number of issues with this: 1) impossible to have variadic arguments with an extra file/line parameters at the end (unless one makes those file/line as compile time parameters but that makes template code bloat), which would be very useful for debugging 2) the context is limited to the calling function (ie top-most stack frame only) 3) the code is more complex than needs to be, especially when we need to forward those arguments (again, due to the stack trace being limited to top-most frame), as every intermediate function is involved in passing around those arguments, whereas ideally these should only occur in 1 location (eg, at the place responsible to handle an assert failure). Furthermore, if we later want to add more information to the context (eg __MODULE__,__FUNCTION__, __COLUMN__ or __ARGUMENTS__), we would have to refactor a lot of code. 4) this is possibly inefficient, as we're passing around potentially more parameters than needed. What about the following instead: A) implicit context parameters (eg: string file = __FILE__, size_t line = __LINE__) are no longer needed B) whenever a stack trace is requested (eg upon an assertion failure, program crash or signal handler), call a unique getStackTrace function (that doesn't use the GC). This allows to show full stack trace (more depth), with potentially more info (eg showing module, function name, stringified arguments, etc). C) when an exception is thrown (which may be caught later), we need to save the stack-trace as efficiently as possible (ie saving the stringified stack trace would be wasteful). On possibility would be to store an array of return addresses (given by C backtrace function), memoized using std.function.memoize. Another would be using a trie data structure, with the assumption that there's only a limited number of such execution paths whose stacktrace will be requested; this should be very efficient D) For a simple implementation, getStackTrace can be based on C functions backtrace/backtrace_symbols but these are not very reliable depending on compiler/operating system/compile options: inlining, off-by-1, missing debug symbols, file base name but no full name, etc. There's also __builtin_return_address and 'llvm.returnaddress' Intrinsics that could be used. So this could be improved with compiler support, introducing backtraceD / backtrace_symbolsD (D's equivalent of the existing backtrace / backtrace_symbols) that should work irrespective of OS/D compiler/inlining/compiler flags. In particular, when the compiler inlines: 'main funInlined fun' to 'main fun', it should still be possible to keep track of the intermediate source level function calls with proper book-keeping in the object file.
Re: GPGPUs
On Saturday, 17 August 2013 at 06:09:53 UTC, Atash wrote:
On Saturday, 17 August 2013 at 00:53:39 UTC, luminousone wrote:
You can't mix cpu and gpu code, they must be separate.
H'okay, let's be clear here. When you say 'mix CPU and GPU
code', you mean you can't mix them physically in the compiled
executable for all currently extant cases. They aren't the
same. I agree with that.
That said, this doesn't preclude having CUDA-like behavior
where small functions could be written that don't violate the
constraints of GPU code and simultaneously has semantics that
could be executed on the CPU, and where such small functions
are then allowed to be called from both CPU and GPU code.
However this still has problems of the cpu having to generate
CPU code from the contents of gpu{} code blocks, as the GPU is
unable to allocate memory, so for example ,
gpu{
auto resultGPU = dot(c, cGPU);
}
likely either won't work, or generates an array allocation in
cpu code before the gpu block is otherwise ran.
I'm fine with an array allocation. I'd 'prolly have to do it
anyway.
Also how does that dot product function know the correct index
range to run on?, are we assuming it knows based on the length
of a?, while the syntax,
c[] = a[] * b[];
is safe for this sort of call, a function is less safe todo
this with, with function calls the range needs to be told to
the function, and you would call this function without the
gpu{} block as the function itself is marked.
auto resultGPU = dot$(0 ..
returnLesser(cGPU.length,dGPU.length))(cGPU, dGPU);
'Dat's a point.
Remember with gpu's you don't send instructions, you send
whole programs, and the whole program must finish before you
can move onto the next cpu instruction.
I disagree with the assumption that the CPU must wait for the
GPU while the GPU is executing. Perhaps by default the behavior
could be helpful for sequencing global memory in the GPU with
CPU operations, but it's not a *necessary* behavior.
Well, I disagree with the assumption assuming said assumption
is being made and I'm not just misreading that bit. :-P
=== Another thing...
I'm with luminousone's suggestion for some manner of function
attribute, to the tune of several metric tonnes of chimes. Wind
chimes. I'm supporting this suggestion with at least a metric
tonne of wind chimes.
I'd prefer this (and some small number of helpers) rather than
straight-up dumping a new keyword and block type into the
language. I really don't think D *needs* to have this any lower
level than a library based solution, because it already has the
tools to make it ridiculously more convenient than C/C++ (not
necessarily as much as CUDA's totally separate program nvcc
does, but a huge amount).
ex.
@kernel auto myFun(BufferT)(BufferT glbmem)
{
// brings in the kernel keywords and whatnot depending
__FUNCTION__
// (because mixins eval where they're mixed in)
mixin KernelDefs;
// ^ and that's just about all the syntactic noise, the rest
uses mixed-in
// keywords and the glbmem object to define several
expressions that
// effectively record the operations to be performed into
the return type
// assignment into global memory recovers the expression type
in the glbmem.
glbmem[glbid] += 4;
// This assigns the *expression* glbmem[glbid] to val.
auto val = glbmem[glbid];
// Ignoring that this has a data race, this exemplifies
recapturing the
// expression 'val' (glbmem[glbid]) in glbmem[glbid+1].
glbmem[glbid+1] = val;
return glbmem; /// I lied about the syntactic noise. This is
the last bit.
}
Now if you want to, you can at runtime create an OpenCL-code
string (for example) by passing a heavily metaprogrammed type
in as BufferT. The call ends up looking like this:
auto promisedFutureResult = Gpu.call!myFun(buffer);
The kernel compilation (assuming OpenCL) is memoized, and the
promisedFutureResult is some asynchronous object that
implements concurrent programming's future (or something to
that extent). For convenience, let's say that it blocks on any
read other than some special poll/checking mechanism.
The constraints imposed on the kernel functions is
generalizable to even execute the code on the CPU, as the
launching call ( Gpu.call!myFun(buffer) ) can, instead of using
an expression-buffer, just pass a normal array in and have the
proper result pop out given some interaction between the
identifiers mixed in by KernelDefs and the launching caller
(ex. using a loop).
Alternatively to returning the captured expressions, the
argument glbmem could have been passed ref, and the same sort
of expression capturing could occur. Heck, more arguments
could've been passed, too, this doesn't require there to be one
single argument representing global memory.
With CTFE, this method *I think* can also generate the code at
compile time given the proper kind of
expression-type-recording-BufferT.
Again, though, all
Re: std.serialization: pre-voting review / discussion
On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote: On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote: Wishful thinking aside, they are competitors. They are not. `std.serialization` does not and should not compete in Thrift domain. Huh? Do you know what thrift does? Summary: Everything that Orange/std.serialization does and more. To the point: Thrift provides data versioning, std.serialization does not. In my book: end of story, game over. Thrift is preffered choice. If you are going to standardize something, standardize the Thrift bindings so that the compiler doesn't introduce regressions that break them, like happened from dmd 2.062 - present. You don't provide any rationale for your assertion, so I can't really respond more constructively until you do. Please familiarize yourself with D's Thrift bindings, which work well with dmd 2.061. Then provide a rationale for your conjecture.
Re: proposal: better stack trace support could advantageously replace implicit __FILE__/__LINE__ parameters
On 8/17/13, Timothee Cour thelastmamm...@gmail.com wrote: 1) impossible to have variadic arguments with an extra file/line parameters at the end (unless one makes those file/line as compile time parameters but that makes template code bloat), which would be very useful for debugging This is a more general problem, I hope we can solve this one day. http://d.puremagic.com/issues/show_bug.cgi?id=8687 Furthermore, if we later want to add more information to the context (eg __MODULE__,__FUNCTION__, __COLUMN__ or __ARGUMENTS__), we would have to refactor a lot of code. P.S. __MODULE__, __FUNCTION__ and __PRETTY_FUNCTION__ were added in 2.063. Anywho, I agree it's a bit tedious having to explicitly use these as parameters. I once suggested to have a single __CONTEXT__ parameter which held various caller information inside of a struct (e.g. a struct with a file, line, function fields), it would at least make it easier to use since it would be just one parameter instead of several, but I didn't get a positive response for the feature.
Re: proposal: better stack trace support could advantageously replace implicit __FILE__/__LINE__ parameters
On Sat, Aug 17, 2013 at 1:54 AM, Andrej Mitrovic andrej.mitrov...@gmail.com
wrote:
On 8/17/13, Timothee Cour thelastmamm...@gmail.com wrote:
1) impossible to have variadic arguments with an extra file/line
parameters
at the end (unless one makes those file/line as compile time parameters
but
that makes template code bloat), which would be very useful for debugging
This is a more general problem, I hope we can solve this one day.
http://d.puremagic.com/issues/show_bug.cgi?id=8687
That would be a partial fix only, as it would be impossible to override the
file/line parameters in case of forwarding. WRT 8687, a better solution
would be named parameters arguments (as I've suggested many times before):
void fun(T...)(T args, string file : __FILE__, int line : __LINE__ ){}
called with:
fun(1,2,3) = file =__FILE__,line=__LINE__
fun(1,2,3,file:fun.d) = file =fun.d,line=__LINE__
fun(1,2,3, line :24) = file =__FILE__,line=24
fun(1,2,3, line :24 , file:fun.d) = file =fun.d,line=24
This results in no ambiguity and still gives flexibility to override the
defaults. Parameters marked with : *have* to be named at call site.
Optionally, no default may be provided: void fun(T...)(T args, string file:
, int nb_cols:){}
Furthermore, if we later want to add more information to the context (eg
__MODULE__,__FUNCTION__, __COLUMN__ or __ARGUMENTS__), we would have to
refactor a lot of code.
P.S. __MODULE__, __FUNCTION__ and __PRETTY_FUNCTION__ were added in 2.063.
Anywho, I agree it's a bit tedious having to explicitly use these as
parameters.
I once suggested to have a single __CONTEXT__ parameter which held
various caller information inside of a struct (e.g. a struct with a
file, line, function fields), it would at least make it easier to use
since it would be just one parameter instead of several, but I didn't
get a positive response for the feature.
I was also in favor of this (better than having to list explicitly each of
LINE,FILE...) but somehow if I remember andrei was against it to keep
things simple. I disagree with the 'keep it simple' argument (really it
doesn't add much to the compiler but simplifies user code), however it may
be a bit inefficient to pass around everything in context.
Which is why I am proposing instead proper stacktrace support for maximum
efficiency and ease of user code.
Re: std.serialization: pre-voting review / discussion
On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote: On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote: On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote: Wishful thinking aside, they are competitors. They are not. `std.serialization` does not and should not compete in Thrift domain. Huh? Do you know what thrift does? Summary: Everything that Orange/std.serialization does and more. To the point: Thrift provides data versioning, std.serialization does not. In my book: end of story, game over. Thrift is preffered choice. If you are going to standardize something, standardize the Thrift bindings so that the compiler doesn't introduce regressions that break them, like happened from dmd 2.062 - present. You don't provide any rationale for your assertion, so I can't really respond more constructively until you do. Please familiarize yourself with D's Thrift bindings, which work well with dmd 2.061. Then provide a rationale for your conjecture. I agree built in version support is important. As for your other issues you mention: a) do one thing, do it well. b) modular is better than monolithic. c) std.serialization is for serialization, no more no less. d) Thrift is for scalable cross-language services development. (and much more http://thrift.apache.org/) Just because Thrift can serialize classes/structs doesn't mean std.serialization should support RPC services or transport of serialized data. I'd rather that was left for a separate module (or two or three) built on top of std.serialization.
[dox] DDOX (was Re: Can we get a forum section devoted to documentation?)
On Friday, 16 August 2013 at 19:32:41 UTC, Mr. Anonymous wrote: On Friday, 16 August 2013 at 19:27:58 UTC, Andre Artus wrote: On Friday, 16 August 2013 at 19:12:46 UTC, Mr. Anonymous wrote: On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html I have not yet had the time to look into it, but I fear that it would be of little use if it's not the official way of doing docs. Although it may be the preferred option for private projects or projects not directly connected to the main D ecosystem. There is already quite a lot of fragmentation making it quite an effort to find out what the one true path[1] is. 1. I realize that there isn't truly such a thing, but an opinionated starting point is of great help to noobs. The major feature to popularize Ruby on Rails when it first kicked off was, in my opinion, the on rails part. You had a very clear indication of where to start, and what the best/accepted/expected practices are. Once you have accustomed yourself to the language and framework you can find ways to go crashing through the bushes if you feel the need to do so. It's planned as the official way of doing docs. There are pull request for it, but it's going nowhere for the past several months. A related thread: http://forum.dlang.org/thread/dsnpggjmndaxiusfq...@forum.dlang.org I have looked at it now, and it seems to me to be a great improvement but the content needs to be updated. If this is going to be the new official way, and all that is needed is someone to start porting/updating the content then I'll sign up for that. I think it wise to first get it up to date before doing major new additions. Who is working on this at the moment?
Re: std.serialization: pre-voting review / discussion
On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote: On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote: On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote: Wishful thinking aside, they are competitors. They are not. `std.serialization` does not and should not compete in Thrift domain. Huh? Do you know what thrift does? Summary: Everything that Orange/std.serialization does and more. To the point: Thrift provides data versioning, std.serialization does not. In my book: end of story, game over. Thrift is preffered choice. If you are going to standardize something, standardize the Thrift bindings so that the compiler doesn't introduce regressions that break them, like happened from dmd 2.062 - present. You don't provide any rationale for your assertion, so I can't really respond more constructively until you do. Please familiarize yourself with D's Thrift bindings, which work well with dmd 2.061. Then provide a rationale for your conjecture. Yes I know what Thrift does and that is not what it is needed here. Important things to consider: 1) Having bindings in standard library is discouraged, we have Deimos for that. There is only curl stuff and it is considered a bad solution as far as I am aware of. 2) Thrift covers very wide domain of tasks - protocol descriptions, inter-operation between different versions, cross-language operation. `std.serialization` is about one simple task - taking care of D type reflection to load/store them in some way. 3) UNIX-way. Standard library must provide small self-sufficient components that focus on doing one job and doing it good. It is up to user to combine those components to build behavior he needs in actual application. In that sense core of std.serialization must be evaluated from the point of view does it allow me to add feature X? instead of does it have feature X? 4) There are lot of different serialization use cases and often having something like Thrift is a huge overkill. Good standard library allows user to chose only functionality he actually needs, no more. There is nothing wrong with your choice of Thrift - it just does not belong to std.serialization
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote: Currently it is not the case. typeof(tuple(1,2)) is Tuple!(int,int), not TypeTuple!(int, int). But typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :) Whu? There is no such type as TypeTuple!(int, int), it is completely aliased away to a builtin tuple. Also, printing out types is actually rather misleading, as it chooses when to use or not use tuple() in annoying ways e.g. TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3) is tuple(int, 3) Either they are both tuples, or neither is. To the best of my knowledge, there is only this: 1) collections of items, called tuples. They can contain pretty much anything you want, as long it's available at compile-time. They are ***not types***. If and only if a tuple contains only types, the tuple itself is a type. This is often referred to as a type-tuple. In current D, tuples of all varieties are created by variadic template parameters.* 2) instantiations of type-tuples. These are a collection of runtime values, individually accessible by indexing or foreach iteration. std.typecons.Tuple is a wrapper around one of these providing some extra functionality. *std.typetuple.TypeTuple only exists to provide convenient syntax for this.
Re: std.serialization: pre-voting review / discussion
On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote: On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote: On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote: Wishful thinking aside, they are competitors. They are not. `std.serialization` does not and should not compete in Thrift domain. Huh? Do you know what thrift does? Summary: Everything that Orange/std.serialization does and more. To the point: Thrift provides data versioning, std.serialization does not. In my book: end of story, game over. Thrift is preffered choice. Thrift is the preferred choice when choosing a library for ALL your possible serialization needs and more. However, standard library modules are not about including every possible convenience, it's about providing solid building blocks for creating larger frameworks. What you're suggesting leads directly to the clearly idiotic like std.stdio sucks because it's doesn't have a printRainbows feature
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 11:43:09 UTC, John Colvin wrote:
On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:
Currently it is not the case. typeof(tuple(1,2)) is
Tuple!(int,int), not TypeTuple!(int, int). But
typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)
Whu?
There is no such type as TypeTuple!(int, int), it is completely
aliased away to a builtin tuple.
Yeah but there is no syntax for them so I am using TypeTuple for
unambiguity. pragma(msg) will print (int, int) for it.
Also, printing out types is actually rather misleading, as it
chooses when to use or not use tuple() in annoying ways e.g.
TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3)
is tuple(int, 3) Either they are both tuples, or neither is.
They are two types of built-in tuples - pure type tuples and
expression/mixed tuples. typeof expression tuple is type tuple.
Those have same syntax but slightly different semantics.
To the best of my knowledge, there is only this:
1) collections of items, called tuples. They can contain pretty
much anything you want, as long it's available at compile-time.
They are ***not types***. If and only if a tuple contains only
types, the tuple itself is a type. This is often referred to as
a type-tuple. In current D, tuples of all varieties are created
by variadic template parameters.*
All true but last statement. They are not created anywhere,
this is simply most convenient way to capture built-in tuple in a
form usable by user code.
2) instantiations of type-tuples. These are a collection of
runtime values, individually accessible by indexing or foreach
iteration. std.typecons.Tuple is a wrapper around one of these
providing some extra functionality.
As far as I can observe, instantiations of type tuples are
expression tuples. And std.typecons.Tuple is completely different
beast, it simply a template struct.
See example:
import std.typetuple;
import std.typecons;
import std.stdio;
void main()
{
alias TT = TypeTuple!(int, string);
enum ET = TypeTuple!(2, 2);
TT twoVars; twoVars[0] = 2; twoVars[1] = 2;
writeln(typeid(typeof(twoVars)));
writeln(twoVars);
writeln(typeid(typeof(ET)));
writeln(ET);
auto different = tuple(2, 2);
writeln(typeid(typeof(different)));
writeln(different);
writeln(__traits(allMembers, typeof(different)));
}
(int,immutable(char)[])
22
(int,immutable(char)[])
22
std.typecons.Tuple!(int, string).Tuple
Tuple!(int, string)(2, 2)
parseSpecsFieldSpecfieldSpecsextractTypeextractNameinjectNamedFieldssliceSpecsexpandSpecisCompatibleTuplesTypesexpand_0_1fieldat__ctoropEqualsopCmpopAssign_workaround4424slicelengthtoString_expand_field_0_expand_field_1
http://dpaste.dzfl.pl/b98d8537
Re: GPGPUs
On 8/13/2013 12:27 PM, Russel Winder wrote: The era of GPGPUs for Bitcoin mining are now over, they moved to ASICs. The new market for GPGPUs is likely the banks, and other Big Data folk. True many of the banks are already doing some GPGPU usage, but it is not big as yet. But it is coming. Most of the banks are either reinforcing their JVM commitment, via Scala, or are re-architecting to C++ and Python. True there is some C#/F# but it is all for terminals not for strategic computing, and it is diminishing (despite what you might hear from .NET oriented training companies). Currently GPGPU tooling means C. There is some interesting work in that regards in .NET: http://research.microsoft.com/en-us/projects/Accelerator/ Obviously, it uses DirectX, but what's nice about it that it is normal C# that doesn't look like it is written by aliens.
Re: Static unittests?
monarch_dodra got my point. So a static unittest is just like a normal one, but it will be executed in compile time. And every assert in it is a static assert. They will be only used to test CTFE's results and to insure that all constants are initialized correctly. I really think that this should be added to the language, because it doesn't break stuff and it is useful. And the 'static' keyword is already used in many places like module imports and ifs.
Re: Guys, what have I done xD
On Saturday, 10 August 2013 at 18:28:26 UTC, H. S. Teoh wrote: On Wed, Aug 07, 2013 at 09:52:10PM +0200, Borislav Kosharov wrote: I played around and used D's flexible syntax and I managed to create this: https://gist.github.com/nikibobi/6169035 It prints the song's lyrics and I have used aliases, templates, constants, the fact that f(a) == a.f() == a.f and many more small things. I tough that it was funny and strange and I decided to show it to you. Also if you change the enum Word it changes everything :D Oh dear. Is this the beginning of the IODCC? ;-) T What is IODCC?
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 12:37:23 UTC, Dicebot wrote: On Saturday, 17 August 2013 at 11:43:09 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote: Currently it is not the case. typeof(tuple(1,2)) is Tuple!(int,int), not TypeTuple!(int, int). But typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :) Whu? There is no such type as TypeTuple!(int, int), it is completely aliased away to a builtin tuple. Yeah but there is no syntax for them so I am using TypeTuple for unambiguity. pragma(msg) will print (int, int) for it. ok, fair enough. Also, printing out types is actually rather misleading, as it chooses when to use or not use tuple() in annoying ways e.g. TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3) is tuple(int, 3) Either they are both tuples, or neither is. They are two types of built-in tuples - pure type tuples and expression/mixed tuples. typeof expression tuple is type tuple. Those have same syntax but slightly different semantics. Not quite, there are pure type-tuples (can be used as a type), pure expression-tuples (can be assigned to) and mixed tuples. But then there's also aliases... int a; auto b = TypeTuple!(a); b[0] = 3; assert(a == 0); //passes clearly b is an instantiation of a typetuple (or an expression-tuple, as you point out), but what is actually going on in it's initialisation? To the best of my knowledge, there is only this: 1) collections of items, called tuples. They can contain pretty much anything you want, as long it's available at compile-time. They are ***not types***. If and only if a tuple contains only types, the tuple itself is a type. This is often referred to as a type-tuple. In current D, tuples of all varieties are created by variadic template parameters.* All true but last statement. They are not created anywhere, this is simply most convenient way to capture built-in tuple in a form usable by user code. That's what i mean by created. I deliberated over what word to use there for quite a while, but perhaps capture is better. Either way, you've got some ct stuff and you want to group it together in to a tuple, variadic template parameters is the way to do it. 2) instantiations of type-tuples. These are a collection of runtime values, individually accessible by indexing or foreach iteration. std.typecons.Tuple is a wrapper around one of these providing some extra functionality. As far as I can observe, instantiations of type tuples are expression tuples. That's an interesting way of looking at it. I didn't realise one could do this: auto ET = TypeTuple!(2, 2); ET[0] = 5; //perfectly fine And std.typecons.Tuple is completely different beast, it simply a template struct. Yes, as I said: It's a wrapper around an instantiation of a type-tuple. Every time I think I understand this, there's more...
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote: And std.typecons.Tuple is completely different beast, it simply a template struct. Yes, as I said: It's a wrapper around an instantiation of a type-tuple. By that logic every single possible template with variadic parameters is wrapper around instantiation of type tuple. std.typecons.Tuple does not store expression tuple inside so I don't think it is legal to call it a wrapper. Simply pseudo-anonymous struct with pseudo-anonymous fields.
Re: Tuple/TypeTuple etc.
On 08/17/2013 02:37 PM, Dicebot wrote: 1) collections of items, called tuples. They can contain pretty much anything you want, as long it's available at compile-time. They are ***not types***. If and only if a tuple contains only types, the tuple itself is a type. This is often referred to as a type-tuple. In current D, tuples of all varieties are created by variadic template parameters.* All true but last statement. They are not created anywhere, this is simply most convenient way to capture built-in tuple in a form usable by user code. Actually, they are created like this: Foo!(int,hello,2) ^~~ std.typetuple.TypeTuple is the identity function on template argument lists.
Re: Tuple/TypeTuple etc.
On 08/17/2013 04:04 PM, Dicebot wrote: On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote: And std.typecons.Tuple is completely different beast, it simply a template struct. Yes, as I said: It's a wrapper around an instantiation of a type-tuple. By that logic every single possible template with variadic parameters is wrapper around instantiation of type tuple. std.typecons.Tuple does not store expression tuple inside so I don't think it is legal to call it a wrapper. Simply pseudo-anonymous struct with pseudo-anonymous fields. std.typecons.Tuple!(...).field is an expression tuple.
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 14:04:21 UTC, Dicebot wrote: On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote: And std.typecons.Tuple is completely different beast, it simply a template struct. Yes, as I said: It's a wrapper around an instantiation of a type-tuple. By that logic every single possible template with variadic parameters is wrapper around instantiation of type tuple. std.typecons.Tuple does not store expression tuple inside so I don't think it is legal to call it a wrapper. Simply pseudo-anonymous struct with pseudo-anonymous fields. I'm afraid if you look at the implementation of std.typecons.Tuple, it does exactly what you say it doesn't do. The struct-like aspects (e.g. named access) are simulated using aliases.
Re: Experiments with emscripten and D
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
bearophile:
Piotr Szturmaj:
I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
Once your work is more more completed, the dlang site could show (in a
sub-page) the compiler that compiles the online examples of the docs
that's able to produce html+JS on the fly from the D code written in the
browser.
Yes, and it could be used to write rich web applications (which is the
reason I'm working on it). JavaScript certainly wasn't created for big
codebases...
Never understood the excitement about things like these. Yes, it's
somewhat interesting and technically impressive, but in the end, the
only language that benefits here *is* JavaScript. And it's already
spreading like cancer. Why help it if you don't like it?
If even 1/10th of the effort spent on compile-everything-to-JS projects
was directed towards properly bringing other languages into the browser
land, the web would be a much better place now.
The other big advantage would having one codebase shared between server,
browser (including mobile) and desktop apps.
Yes, in theory. In practice, this is just something Node.JS people came
up with for advocacy of their platform. It's false. In-browser
JavaScript has so many constraints imposed on it that it will never
behave exactly like server-side code. (For example, your gist doesn't
work in IE. Not that I use IE normally, but you get my point.)
Worse, no one took time to actually design a sensible model of
interaction between server and the client for a shared codebase. It's
all a jumbled mess of ad-hoc implementations and subverted web
technologies that were originally meant for an entirely different
purpose. I sometimes see JS examples like this:
if (imOnTheServer){
//do one thing
} eles {
//do another thing
} //Yay, shared code!!!
Every time I do, I get the urge to abandon programming and change my
occupation.
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 14:19:06 UTC, John Colvin wrote: I'm afraid if you look at the implementation of std.typecons.Tuple, it does exactly what you say it doesn't do. The struct-like aspects (e.g. named access) are simulated using aliases. Checked once more and I stand corrected. At first glance at implementation I had impression that is exactly the other way around. That makes situation even more fun.
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote: Every time I do, I get the urge to abandon programming and change my occupation. My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most personal computers are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. --rt
Re: GPGPUs
On Friday, 16 August 2013 at 19:53:44 UTC, Atash wrote: I'm iffy on the assumption that the future holds unified memory for heterogeneous devices. Even relatively recent products such as the Intel Xeon Phi have totally separate memory. I'm not aware of any general-computation-oriented products that don't have separate memory. Many laptop and mobile devices (they have it in the hardware, but the API don't permit to make use of it most of the time), next gen consoles (PS4, Xbox one). nVidia is pushing against it, AMD/ATI is pushing for it, and they are right on that one. I'm also of the opinion that as long as people want to have devices that can scale in size, there will be modular devices. Because they're modular, there's some sort of a spacing between them and the machine, ex. PCIe (and, somewhat importantly, a physical distance between the added device and the CPU-stuff). Because of that, they're likely to have their own memory. Therefore, I'm personally not willing to bank on anything short of targeting the least common denominator here (non-uniform access memory) specifically because it looks like a necessity for scaling a physical collection of heterogeneous devices up in size, which in turn I *think* is a necessity for people trying to deal with growing data sets in the real world. You can have 2 sockets on the motherboard. Add because heterogeneous compute devices aren't *just* GPUs (ex. Intel Xeon Phi), I'd strongly suggest picking a more general name, like 'accelerators' or 'apu' (except AMD totally ran away with that acronym in marketing and I sort of hate them for it) or 'something-I-can't-think-of-because-words-are-hard'. That said, I'm no expert, so go ahead and rip 'mah opinions apart. :-D Unified memory have too much benefice for it to be ignored. The open questions are about cache coherency, direct communication between chips, identical performances through the address space, and so on. But the unified memory will remains. Even when memory is physically separated, you'll see an unified memory model emerge, with disparate performances depending on address space.
Re: Tuple/TypeTuple etc.
http://wiki.dlang.org/The_D_Programming_Language/Seq
Re: Tuple/TypeTuple etc.
On Saturday, 17 August 2013 at 15:50:51 UTC, Timon Gehr wrote: http://wiki.dlang.org/The_D_Programming_Language/Seq I added a little bit on multiple return values.
Re: Guys, what have I done xD
On Sat, Aug 17, 2013 at 03:47:06PM +0200, Borislav Kosharov wrote: On Saturday, 10 August 2013 at 18:28:26 UTC, H. S. Teoh wrote: On Wed, Aug 07, 2013 at 09:52:10PM +0200, Borislav Kosharov wrote: I played around and used D's flexible syntax and I managed to create this: https://gist.github.com/nikibobi/6169035 It prints the song's lyrics and I have used aliases, templates, constants, the fact that f(a) == a.f() == a.f and many more small things. I tough that it was funny and strange and I decided to show it to you. Also if you change the enum Word it changes everything :D Oh dear. Is this the beginning of the IODCC? ;-) T What is IODCC? The International Obfuscated D Code Contest. It's a pun on the IOCCC (International Obfuscated C Code Contest -- see ioccc.org), which is a contest where you try to write the most unreadable, unmaintainable, and horrible C code you can. :) T -- The richest man is not he who has the most, but he who needs the least.
Re: Experiments with emscripten and D
On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote: On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote: Every time I do, I get the urge to abandon programming and change my occupation. My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most personal computers are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: [dox] Fixing the lexical rule for BinaryInteger
On Sat, Aug 17, 2013 at 04:02:40AM +0200, Andre Artus wrote: On Saturday, 17 August 2013 at 00:51:57 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 01:03:35AM +0200, Brian Schott wrote: On Friday, 16 August 2013 at 22:43:13 UTC, Andre Artus wrote: [...] 2. Your BinaryInteger and HexadecimalInteger only allow for one of the following (reduced) cases: 0b1__ : works 0b_1_ : fails 0b__1 : fails It's my opinion that the compiler should reject all of these because I think of the underscore as a separator between digits, but I'm constantly fighting the spec, dmd, and idiom all disagree issue. [...] I remember reading this part of the spec on dlang.org, and I wonder if it was worded the way it is just for simplicity, because to specify something like _ must appear between digits involves some complicated BNF rules, which maybe seems like overkill for a single literal. But sometimes it is good to be precise, if we want to enforce proper conventions for underscores: binaryLiteral ::= 0b binaryDigits underscoreBinaryDigits binaryDigits ::= binaryDigit binaryDigits | binaryDigit underscoreBinaryDigits ::= | _ binaryDigits | _ binaryDigits underscoreBinaryDigits binaryDigit ::= 0 | 1 This BNF spec forces _ to only appear between two binary digits, and never more than a single _ in a row. Yup, that's the issue. Coding the actual behaviour by hand, or doing it with a regular expression, is close to trivial. You can also make your parser only pick up binaryDigit when performing semantic on binary literals, so the other stuff is ignored and only serves to enforce syntax. Pushing it up to the parser is an option in implementation, but I don't see that making the specification easier (it's 3:40 in the morning here, so I am very likely not thinking too clearly about this). I didn't mean to push it up to the parser. I was just using BNF to show that it's possible to specify the behaviour precisely. And also that it's rather convoluted just for something as intuitively straightforward as an integer literal. Which is a likely reason why the current specs are a bit blurry about what should/shouldn't be allowed. I'd be surprised if there's any D code out there that doesn't fit this spec, to be honest. It's not what I would call best practice, but the following is possible in the current compiler: auto myBin1 = 0b0011_1101; // Sane auto myBin2 = 0b___1; // Trouble, myBin2 == 1 auto myBin3 = 0b1___; // Trouble, myBin3 == 1 Which means a tools built against the documented spec are going to choke on these weird cases. Personally I would prefer if the more questionable options were not allowed as they potentially defeat the goal of improving clarity. But, that's a breaking change. I know that, but I'm saying that hardly *any* code would break if we made DMD reject things like this. I don't think anybody in their right mind would write code like that. (Unless they were competing in the IODCC... :-P) The issue here is that when specs / DMD / TDPL don't agree, then it's not always clear which among the three are wrong. Perhaps *all* of them are wrong. Just because DMD accepts invalid code doesn't mean it should be part of the specs, for example. It could constitute a DMD bug. But if you want to accept strange literals like 0b__1__, you could do something like: binaryLiteral ::= 0b underscoreBinaryDigits binaryDigit underscoreBinaryDigits underscoreBinaryDigits ::= _ | _ underscoreBinaryDigits | binaryDigit | binaryDigit underscoreBinaryDigits | binaryDigit ::= 0 | 1 The odd form of the rule for binaryLiteral is to ensure that there's at least one binary digit in the string, whereas underscoreBinaryDigits is just a wildcard anything-goes rule that takes any combination of 0, 1, and _, including the empty string. The rule that matches the DMD compiler is actually very easy to do in ANTLR4, i.e. BinaryLiteral : '0b' [_01]* [01] [_01]* ; I'm a bit too tired to fully pay attention, but it seems you are saying that 0b (no additional numbers) should match, which I believe it should not (although I admit to not testing this). If it does then I would consider that a bug. No, the BNF rules I wrote are equivalent to your ANTLR4 spec. Which is equivalent to the regex I posted later. It's not a problem implementing the rule, I am more concerned with documenting it in a clear and unambiguous way so that people building tools from it can get it right. BNF isn't always the easiest way to do so, but it's what being used. Well, you could bug Walter about what *should* be accepted, and if he agrees to restrict it to having _ only between two digits, then you'd file a bug against DMD. Again, I seriously doubt that such a change would cause any code breakage, because writing 0b1 as
Re: Experiments with emscripten and D
W dniu 17.08.2013 16:42, Gambler pisze:
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
bearophile:
Piotr Szturmaj:
I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
Once your work is more more completed, the dlang site could show (in a
sub-page) the compiler that compiles the online examples of the docs
that's able to produce html+JS on the fly from the D code written in the
browser.
Yes, and it could be used to write rich web applications (which is the
reason I'm working on it). JavaScript certainly wasn't created for big
codebases...
Never understood the excitement about things like these. Yes, it's
somewhat interesting and technically impressive, but in the end, the
only language that benefits here *is* JavaScript. And it's already
spreading like cancer. Why help it if you don't like it?
If even 1/10th of the effort spent on compile-everything-to-JS projects
was directed towards properly bringing other languages into the browser
land, the web would be a much better place now.
It's not about helping JavaScript. It's about using another language to
do client side scripting. I hate JS, I really don't like to write bigger
applications in it.
What happens when you forget a semicolon or a comma? Or make some typos?
It silently breaks. I don't care if there are tools to help with it.
It's still a mess. Did you see WAT
(https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
are some examples of JS additions which WAT demonstrated:
[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN
Seriously, WTF!
And again, I don't want to write in it, but I _must_ use it. I just want
to use another language that translates to JS. There are many of them
already. Still, no one is even close to D in its usefulness.
The whole problem is that you need to write a web applications _now_,
when the only supported languages for the web is JS. You really don't
have a choice. Even if other languages could be widely supported from
today, you'd still have to support older browsers. This means JS will
stay in for another couple of years.
The other big advantage would having one codebase shared between server,
browser (including mobile) and desktop apps.
Yes, in theory. In practice, this is just something Node.JS people came
up with for advocacy of their platform. It's false. In-browser
JavaScript has so many constraints imposed on it that it will never
behave exactly like server-side code. (For example, your gist doesn't
work in IE. Not that I use IE normally, but you get my point.)
Obviously, you can't share every possible code. It's about sharing the
cross cutting parts. Imagine an application with a server, web frontend
and desktop frontend. With shared codebases, you could write one client
code. Just use the same abstractions for the web and for the desktop.
Then you can create similar interfaces from the same codebase. It's a
huge win. Duplicating efforts is tiresome, error prone and obviously
takes time.
Worse, no one took time to actually design a sensible model of
interaction between server and the client for a shared codebase. It's
all a jumbled mess of ad-hoc implementations and subverted web
technologies that were originally meant for an entirely different
purpose. I sometimes see JS examples like this:
if (imOnTheServer){
//do one thing
} eles {
//do another thing
} //Yay, shared code!!!
Every time I do, I get the urge to abandon programming and change my
occupation.
This is not a new idea. Morfik is a webdev tool that automatically
splits your code to the server and JS. I remember it was available in
2005. Also, there is Opa language.
I don't see anything wrong with cross platform code. For D example, I'd
imagine it could look like this:
void showMsg(string s) {
version (JS)
js.alert(s);
else
YourDesktopWidgetToolkit.showMessageDialog(s);
}
void main() {
showMsg(hello world);
}
Compiled with a regular compiler and GTK, will show a dialog.
Compiled with emscripten-like compiler will show a message in the browser.
Re: [OT] Bret Victor's Talk at DBX, The Future of Programming
On Friday, 16 August 2013 at 07:20:05 UTC, Paulo Pinto wrote: A very interesting talk done as if we were in the mid-70's discussing the future of programming in 40 years time (meaning today). http://vimeo.com/71278954 The main message is how fast technology changes and how developers resist to change specially in the presence of dogmas. -- Paulo I highly recommend to watch it. Entertaining and informative. Vimeo is still a huge piece of shit, I wish it was published somewhere else :(
Re: Experiments with emscripten and D
W dniu 17.08.2013 16:42, Gambler pisze: (For example, your gist doesn't work in IE. Not that I use IE normally, but you get my point.) This is because the code was compiled with typed arrays support. It's possible to compile without TA support and then it will work in IE.
Re: Static unittests?
On 8/17/13, Borislav Kosharov boby_...@abv.bg wrote:
I really think that this should be added to the language, because
it doesn't break stuff and it is useful. And the 'static' keyword
is already used in many places like module imports and ifs.
Have you tried using the new getUnitTests trait in the git-head
version? If not it will be in the 2.064 release.
Btw such a 'static unittest' feature is certainly going to break code
because static can be applied as a label, for example:
class C
{
static:
void foo() { }
unittest { /* Test the foo method. */ } // suddenly evaluated at
compile-time
}
Re: Request for editor scripting help
On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote: I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. How do the existing plugins handle completion of non-saved parts of the file? Currently I'm just saving the file on every completion request. However that is a usability nightmare. Would saving to a temporary do without confusing DCD?
Re: Guys, what have I done xD
On 7 August 2013 20:52, Borislav Kosharov bo...@gmail.com wrote: I played around and used D's flexible syntax and I managed to create this: https://gist.github.com/nikibobi/6169035 It prints the song's lyrics and I have used aliases, templates, constants, the fact that f(a) == a.f() == a.f and many more small things. I tough that it was funny and strange and I decided to show it to you. Also if you change the enum Word it changes everything :D One is not amused. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote: On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote: Every time I do, I get the urge to abandon programming and change my occupation. My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most personal computers are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T How do we fix it? We have a great language here, let's revolutionise the web :p
Re: Experiments with emscripten and D
On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote: On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote: Every time I do, I get the urge to abandon programming and change my occupation. My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most personal computers are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T How do we fix it? We have a great language here, let's revolutionise the web :p Yeah! vibe.d FTW! :) And the client-side version thereof. :) T -- Bomb technician: If I'm running, try to keep up.
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote: On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote: Every time I do, I get the urge to abandon programming and change my occupation. My thoughts too, The Internet is ripe for another revolution, but the old ways need to be abandoned rather than continually propped up with duct tape and thread. You can barely create simple applications using current html+js tools, and Flash and so forth consume vast amounts of memory and cpu power which can stress out even a full blown desktop computer if you are a heavy browser user like I am, yet most personal computers are now low powered mobile devices which makes the situation really bad. IMO the current direction leads to a dead end. The big boys like Google, Mozilla and MS seem more interested in fighting each other over world domination rather than come up with viable alternatives that can lead the way out of this mess. [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. T How do we fix it? We have a great language here, let's revolutionise the web :p Yeah! vibe.d FTW! :) And the client-side version thereof. :) T Yeah the server-side is relatively easy to pull off, seeing as you're completely in control there. The client side is an eensy little bit harder haha. It would probably require heavily modifying/creating a new web-browser and then convincing people to use it. I wonder how powerful browser extensions can be these days...
Re: GPGPUs
On Saturday, 17 August 2013 at 15:37:58 UTC, deadalnix wrote: Unified memory have too much benefice for it to be ignored. The open questions are about cache coherency, direct communication between chips, identical performances through the address space, and so on. But the unified memory will remains. Even when memory is physically separated, you'll see an unified memory model emerge, with disparate performances depending on address space. I'm not saying 'ignore it', I'm saying that it's not the least common denominator among popular devices, and that in all likelihood it won't be the least common denominator among compute devices ever. AMD/ATi being 'right' doesn't mean that they'll dominate the whole market. Having two slots on your mobo is more limiting than having the ability to just chuck more computers in a line hidden behind some thin wrapper around some code built to deal with non-uniform memory access. Additionally, in another post, I tried to demonstrate a way for it to target the least common denominator, and in my (obviously biased) opinion, it didn't look half bad. Unlike uniform memory access, non-uniform memory access will *always* be a thing. Uniform memory access is cool n'all, but it isn't popular enough to be here now, and it isn't like non-uniform memory access which has a long history of being here and looks like it has a permanent stay in computing. Pragmatism dictates to me here that any tool we want to be 'awesome', eliciting 'wowzers' from all the folk of the land, should target the widest variety of devices while still being pleasant to work with. *That* tells me that it is paramount to *not* brush off non-uniform access, and that because non-uniform access is the least common denominator, that should be what is targeted. On the other hand, if we want to start up some sort of thing where one lib handles the paradigm of uniform memory access in as convenient a way as possible, and another lib handles non-uniform memory access, that's fine too. Except that the first lib really would just be a specialization of the second alongside some more 'convenience'-functions.
Re: Request for editor scripting help
On Saturday, 17 August 2013 at 18:25:50 UTC, Tobias Pankrath wrote: How do the existing plugins handle completion of non-saved parts of the file? Currently I'm just saving the file on every completion request. However that is a usability nightmare. Would saving to a temporary do without confusing DCD? There are several ways that you can solve this, depending on the implementation of whatever function you use to launch the client. The client supports reading from a file (which should be a temporary file to avoid the UI issues you mentioned), or from standard input. It writes to standard output. 1. Write the buffer to a temporary file, run the client on this file and redirect to another temporary. Then read this file and display the completions 2. popen dcd-client output.txt and read the completions. This is what I use with Lua because its implementation of popen doesn't allow reading and writing to the same process. (I know the implementation in git at the moment does this backwards. I'm going to fix it this evening) 3. popen the client and handle everything in memory. This is probably the best way to handle it.
Re: Experiments with emscripten and D
On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote: [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. [...] How do we fix it? We have a great language here, let's revolutionise the web :p Yeah! vibe.d FTW! :) And the client-side version thereof. :) [...] Yeah the server-side is relatively easy to pull off, seeing as you're completely in control there. The client side is an eensy little bit harder haha. It would probably require heavily modifying/creating a new web-browser and then convincing people to use it. I wonder how powerful browser extensions can be these days... Hmm. That's an idea, write an extension that can run code through rdmd. (You have to deliver the source rather than the object code, since you don't know what OS your client is running on.) Requiring an extension puts it in the same boat as Flash, though. :-( And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote: And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. You are getting pretty close to NaCl idea :)
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote: On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote: On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote: [...] It's just like Nick Sabalausky always likes to rant about. In 1975, we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our applications ran rather slowly. Then processor speed increased exponentially, RAM increased exponentially, and today we have 64-bit computers with 4GHz CPUs (and multicore!) and who knows how many GBs of RAM, and our (web) applications run at about the same speed as in 1975. Clearly, *something* is very, very wrong with this picture. [...] How do we fix it? We have a great language here, let's revolutionise the web :p Yeah! vibe.d FTW! :) And the client-side version thereof. :) [...] Yeah the server-side is relatively easy to pull off, seeing as you're completely in control there. The client side is an eensy little bit harder haha. It would probably require heavily modifying/creating a new web-browser and then convincing people to use it. I wonder how powerful browser extensions can be these days... Hmm. That's an idea, write an extension that can run code through rdmd. (You have to deliver the source rather than the object code, since you don't know what OS your client is running on.) not necessarily. The extension would know and could tell the server which version to send (with an optional fallback to code for systems that you don't have a binary ready for). It could also query shared library / dll versions. Also, you could just send llvm IR... Requiring an extension puts it in the same boat as Flash, though. :-( An extension today, built-in to the browser tomorrow? And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. T most, if not all operating systems have good sandboxing, don't they? iOS sandboxes the hell out of everything and I presume android does something similar. on linux you can use selinux utility sandbox or similar.
Re: Experiments with emscripten and D
On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:
W dniu 17.08.2013 16:42, Gambler pisze:
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
bearophile:
Piotr Szturmaj:
I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
Once your work is more more completed, the dlang site could show (in a
sub-page) the compiler that compiles the online examples of the docs
that's able to produce html+JS on the fly from the D code written in
the
browser.
Yes, and it could be used to write rich web applications (which is the
reason I'm working on it). JavaScript certainly wasn't created for big
codebases...
Never understood the excitement about things like these. Yes, it's
somewhat interesting and technically impressive, but in the end, the
only language that benefits here *is* JavaScript. And it's already
spreading like cancer. Why help it if you don't like it?
If even 1/10th of the effort spent on compile-everything-to-JS projects
was directed towards properly bringing other languages into the browser
land, the web would be a much better place now.
It's not about helping JavaScript. It's about using another language to
do client side scripting. I hate JS, I really don't like to write bigger
applications in it.
What happens when you forget a semicolon or a comma? Or make some typos?
It silently breaks. I don't care if there are tools to help with it.
It's still a mess. Did you see WAT
(https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
are some examples of JS additions which WAT demonstrated:
[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN
Seriously, WTF!
WAT is one of my favorite language talks of all times. So we're on the
same page here. But I don't think compiling D to JavaScript is a viable
long-term solution.
1. The more languages compile to JS, the more powerful it becomes and
the harder it will be to replace JS with something better. People will
spend more money on optimizing its (not D's) performance, developing its
(not D's) APIs for stuff like sound and graphics. This is already
happening. I recently interviewed a junior developer for a position that
had nothing to do with JavaScript. At some point during the interview he
said: JavaScript is the future of everything. Yeah, it's the actual
phrasing he used. That's what some people believe in.
2. Compiling things to an intermediate language creates a whole host of
new problems you don't have originally. How do you debug? How do you
print an accurate stack trace? Etc.
3. Even if the tool-chain is perfect, a lot of real work in the browser
is done by calling APIs. If those APIs are designed for JavaScript,
their usage will not be idiomatic inside translated code unless you
manually create wrappers.
It would still be fine if the whole thing hand some kind of gradual
upgrade path that led to using pure D, but I don't see such path.
And again, I don't want to write in it, but I _must_ use it. I just want
to use another language that translates to JS. There are many of them
already. Still, no one is even close to D in its usefulness.
My personal strategy to mitigate the horrors of JavaScript is to use
progressive enhancement and write small, targeted JS libraries that are
invoked declaratively (i.e. you include them, but then it's all about
HTML markup and there is no application-specific JS). Contrary to
popular opinion, this approach is capable of creating very efficient and
very dynamic websites.
The whole problem is that you need to write a web applications _now_,
when the only supported languages for the web is JS. You really don't
have a choice. Even if other languages could be widely supported from
today, you'd still have to support older browsers. This means JS will
stay in for another couple of years.
If things don't change trajectory, I'm afraid JS will not just stay for
a couple of years. It will become de-facto standard for server-side web
computing and displace all other languages in that domain. In the
company I work for, there is already a number of people calling to
rewrite all the web app for Node. I don't see a single tangible benefit
coming out of it if, though. It would be a maintainability nightmare.
The other big advantage would having one codebase shared between server,
browser (including mobile) and desktop apps.
Yes, in theory. In practice, this is just something Node.JS people came
up with for advocacy of their platform. It's false. In-browser
JavaScript has so many constraints imposed on it that it will never
behave exactly like server-side code. (For example, your gist doesn't
work in IE. Not that I use IE normally, but you get my point.)
Obviously, you can't share every possible code. It's about sharing the
cross cutting parts. Imagine an
Re: GPGPUs
On Saturday, 17 August 2013 at 20:17:17 UTC, Atash wrote: On Saturday, 17 August 2013 at 15:37:58 UTC, deadalnix wrote: Unified memory have too much benefice for it to be ignored. The open questions are about cache coherency, direct communication between chips, identical performances through the address space, and so on. But the unified memory will remains. Even when memory is physically separated, you'll see an unified memory model emerge, with disparate performances depending on address space. I'm not saying 'ignore it', I'm saying that it's not the least common denominator among popular devices, and that in all likelihood it won't be the least common denominator among compute devices ever. AMD/ATi being 'right' doesn't mean that they'll dominate the whole market. Having two slots on your mobo is more limiting than having the ability to just chuck more computers in a line hidden behind some thin wrapper around some code built to deal with non-uniform memory access. Additionally, in another post, I tried to demonstrate a way for it to target the least common denominator, and in my (obviously biased) opinion, it didn't look half bad. Unlike uniform memory access, non-uniform memory access will *always* be a thing. Uniform memory access is cool n'all, but it isn't popular enough to be here now, and it isn't like non-uniform memory access which has a long history of being here and looks like it has a permanent stay in computing. Pragmatism dictates to me here that any tool we want to be 'awesome', eliciting 'wowzers' from all the folk of the land, should target the widest variety of devices while still being pleasant to work with. *That* tells me that it is paramount to *not* brush off non-uniform access, and that because non-uniform access is the least common denominator, that should be what is targeted. On the other hand, if we want to start up some sort of thing where one lib handles the paradigm of uniform memory access in as convenient a way as possible, and another lib handles non-uniform memory access, that's fine too. Except that the first lib really would just be a specialization of the second alongside some more 'convenience'-functions. There are two major things, unified memory, and unified virtual address space. Unified virtual address will be universal within a few years, and the user space application will no longer manage the cpu/gpu copies anymore, this instead will be handled by the gpu system library, hMMU, and operating system. Even non-uniform memory will be uniform from the perspective of the application writer.
Possible codegen bug when using Tcl/Tk (related to DMC and DMD)
I was first reducing a strange behavior bug in D, but then realized
the behavior can be recreated with a C code sample built with DMC as
well. I cannot reproduce it when using GCC, so I'm left to believe it
could be a codegen bug.
I'm on Windows 7, 64bit, and I'm using Tcl's Tk library, v8.6 (x86).
First, here is the C code:
-
#include windows.h
#include tcl.h
typedef Tcl_Interp* (* Tcl_CreateInterp_Type)(void);
typedef int (* Tcl_Init_Type)(Tcl_Interp*);
typedef int (* Tk_Init_Type)(Tcl_Interp*);
typedef int (* Tcl_Eval_Type)(Tcl_Interp*, const char *);
typedef void (* Tk_MainLoop_Type)(void);
int main()
{
HMODULE hTcl = LoadLibraryA(tcl86.dll);
HMODULE hTk = LoadLibraryA(tk86.dll);
Tcl_CreateInterp_Type Tcl_CreateInterp;
Tcl_CreateInterp = (Tcl_CreateInterp_Type)GetProcAddress(hTcl,
Tcl_CreateInterp);
Tcl_Init_Type Tcl_Init;
Tcl_Init = (Tcl_Init_Type)GetProcAddress(hTcl, Tcl_Init);
Tk_Init_Type Tk_Init;
Tk_Init = (Tk_Init_Type)GetProcAddress(hTk, Tk_Init);
Tcl_Eval_Type Tcl_Eval;
Tcl_Eval = (Tcl_Eval_Type)GetProcAddress(hTcl, Tcl_Eval);
Tk_MainLoop_Type Tk_MainLoop;
Tk_MainLoop = (Tk_MainLoop_Type)GetProcAddress(hTk, Tk_MainLoop);
Tcl_Interp* _interp = Tcl_CreateInterp();
Tcl_Init(_interp);
Tk_Init(_interp);
Tcl_Eval(_interp, tkwait visibility .);
Tcl_Eval(_interp, tk::toplevel .mywin);
Tcl_Eval(_interp, wm resizable .mywin false false);
Tk_MainLoop();
return 0;
}
-
Then, the dependency is Tcl v8.6 x86, grab it from here:
http://www.activestate.com/activetcl/downloads/thank-you?dl=http://downloads.activestate.com/ActiveTcl/releases/8.6.0.0/ActiveTcl8.6.0.0.296563-win32-ix86-threaded.exe
To compile with both DMC and GCC I use this build.bat script:
-
@echo off
set include_dir=C:\Tcl\include
dmc test_tk.c -I%include_dir% -otest_dmc.exe
g++ test_tk.c -m32 -I%include_dir% -o test_gcc.exe
-
You can run the build script now (but make sure the include dir is set
to wherever you've installed Tcl)
Since the sample app loads the Tcl and Tk DLLs, you need to have them
in your PATH variable. You can do this through command-line and try
out the built apps:
-
set PATH=C:\Tcl\bin;%PATH%
test_gcc.exe
test_dmc.exe
-
Here's the behavior problem:
When running test_gcc.exe, when I try to move the window labeled
mywin with the mouse, the window is moved normally and there's
nothing problematic.
But when doing the same when running test_dmc.exe, the window starts
shrinking in size horizontally until it reaches some minimal width.
I'm using DMC v8.42n, and GCC v4.8.0.
Initially this was D code and I thought I had a bug in my D code, but
now I've ported this sample into C and it seems like it could be a
backend-related bug (since DMD and DMC share the same backend).
Anyway I'm not an ASM expert so I'm hoping to get some more people who
can reproduce this and possibly know what's going on.
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote: On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote: And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. You are getting pretty close to NaCl idea :) Yeah, I was thinking that :p NaCl seems designed mostly as native extensions for the html/js/css world. I was thinking bigger: The browser as a (transient, if appropriate) application delivery system. I really dislike html and css for anything other than simple documents, it quickly feels like one big patchily supported corner-case. Anything other than simple uses ends up requiring significant abuses, even if you're lucky enough to be working in a hypothetical totally standards compliant environment. Even something as simple as a drop-down menu with persistence means either: massively abuse css OR use JS. What I'm imagining is a truly dynamic web-delivered UI with native speed and processing capability, not just a faster web-app.
Re: [dox] Fixing the lexical rule for BinaryInteger
Andre Artus wrote: 2. Your BinaryInteger and HexadecimalInteger only allow for one of the following (reduced) cases: 0b1__ : works 0b_1_ : fails 0b__1 : fails Brian Schott wrote: It's my opinion that the compiler should reject all of these because I think of the underscore as a separator between digits, but I'm constantly fighting the spec, dmd, and idiom all disagree issue. I agree with you, Brian, all three of these constructions go contrary to the goal of making the code clearer. I would not be too surprised if a significant number of programmers would see those as different numbers, at least until they paused to take it in. [...] H. S. Teoh wrote: I remember reading this part of the spec on dlang.org, and I wonder if it was worded the way it is just for simplicity, because to specify something like _ must appear between digits involves some complicated BNF rules, which maybe seems like overkill for a single literal. I think that you are right. H. S. Teoh wrote: But sometimes it is good to be precise, if we want to enforce proper conventions for underscores: binaryLiteral ::= 0b binaryDigits underscoreBinaryDigits binaryDigits ::= binaryDigit binaryDigits | binaryDigit underscoreBinaryDigits ::= | _ binaryDigits | _ binaryDigits underscoreBinaryDigits binaryDigit::= 0 | 1 This BNF spec forces _ to only appear between two binary digits, and never more than a single _ in a row. Andre Artus wrote: Yup, that's the issue. Coding the actual behaviour by hand, or doing it with a regular expression, is close to trivial. H. S. Teoh wrote: You can also make your parser only pick up binaryDigit when performing semantic on binary literals, so the other stuff is ignored and only serves to enforce syntax. Andre Artus wrote: Pushing it up to the parser is an option in implementation, but I don't see that making the specification easier (it's 3:40 in the morning here, so I am very likely not thinking too clearly about this). H. S. Teoh wrote: I didn't mean to push it up to the parser. Sorry I misunderstood, I had been up for over 21 hours at the time I wrote, so it was getting a bit difficult for me to concentrate. I got the impression you were saying that the parser would be responsible for extracting the binary digits. H. S. Teoh wrote: I was just using BNF to show that it's possible to specify the behaviour precisely. And also that it's rather convoluted just for something as intuitively straightforward as an integer literal. Which is a likely reason why the current specs are a bit blurry about what should/shouldn't be allowed. I don't think I've seen lexemes defined using (a variant of) BNF before, most often a form of regular expressions are used. One could cut down and clarify the page describing the lexical syntax significantly employing simple regular expressions. H. S. Teoh wrote: I'd be surprised if there's any D code out there that doesn't fit this spec, to be honest. Andre Artus wrote: It's not what I would call best practice, but the following is possible in the current compiler: auto myBin1 = 0b0011_1101; // Sane auto myBin2 = 0b___1; // Trouble, myBin2 == 1 auto myBin3 = 0b1___; // Trouble, myBin3 == 1 Which means a tools built against the documented spec are going to choke on these weird cases. Personally I would prefer if the more questionable options were not allowed as they potentially defeat the goal of improving clarity. But, that's a breaking change. H. S. Teoh wrote: I know that, but I'm saying that hardly *any* code would break if we made DMD reject things like this. I don't think anybody in their right mind would write code like that. (Unless they were competing in the IODCC... :-P) I agree that the compiler should probably break that code, I believe some breaking changes are good when they help the programmer fix potential bugs. But I am also someone who compiles with Treat warnings as errors. H. S. Teoh wrote: The issue here is that when specs / DMD / TDPL don't agree, then it's not always clear which among the three are wrong. Perhaps *all* of them are wrong. Just because DMD accepts invalid code doesn't mean it should be part of the specs, for example. It could constitute a DMD bug. It would be good to get some clarification on this. H. S. Teoh wrote: But if you want to accept strange literals like 0b__1__, you could do something like: binaryLiteral ::= 0b underscoreBinaryDigits binaryDigit underscoreBinaryDigits underscoreBinaryDigits ::= _ | _ underscoreBinaryDigits | binaryDigit | binaryDigit underscoreBinaryDigits | binaryDigit::= 0
Re: Possible codegen bug when using Tcl/Tk (related to DMC and DMD)
On 8/17/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
First, here is the C code:
Btw, here's the D equivalent where I can also recreate the bug:
-
import core.sys.windows.windows;
import std.stdio;
alias extern(C) void* function() Tcl_CreateInterp_Type;
alias extern(C) int function(void*) Tcl_Init_Type;
alias extern(C) int function(void*) Tk_Init_Type;
alias extern(C) int function(void*, const(char)*) Tcl_Eval_Type;
alias extern(C) void function() Tk_MainLoop_Type;
int main()
{
HMODULE hTcl = LoadLibraryA(tcl86.dll);
HMODULE hTk = LoadLibraryA(tk86.dll);
Tcl_CreateInterp_Type Tcl_CreateInterp;
Tcl_CreateInterp = cast(Tcl_CreateInterp_Type)GetProcAddress(hTcl,
Tcl_CreateInterp);
Tcl_Init_Type Tcl_Init;
Tcl_Init = cast(Tcl_Init_Type)GetProcAddress(hTcl, Tcl_Init);
Tk_Init_Type Tk_Init;
Tk_Init = cast(Tk_Init_Type)GetProcAddress(hTk, Tk_Init);
Tcl_Eval_Type Tcl_Eval;
Tcl_Eval = cast(Tcl_Eval_Type)GetProcAddress(hTcl, Tcl_Eval);
Tk_MainLoop_Type Tk_MainLoop;
Tk_MainLoop = cast(Tk_MainLoop_Type)GetProcAddress(hTk, Tk_MainLoop);
void* _interp = Tcl_CreateInterp();
Tcl_Init(_interp);
Tk_Init(_interp);
Tcl_Eval(_interp, tkwait visibility .);
Tcl_Eval(_interp, tk::toplevel .mywin);
Tcl_Eval(_interp, wm resizable .mywin false false);
Tk_MainLoop();
return 0;
}
-
I've also tried the C sample with various DMC versions such as 857,
846, 837, 830, but I still haven't found a version that doesn't have
this bug.
Maybe the issue is with something else.. I can't tell what DMC and GCC
are doing differently here.
Tool changed intended as part of release? (Requires libcurl.dll on Win)
In the GitHub tools repo, is the tool changed intended to be included as part the DMD release zips? I ask because it uses libcurl, so on windows that would require either: A) the user already has libcurl.dll (and possibly the other dlls included with libcurl) installed. or B) including the libcurl dlls in the DMD release. I don't see B as a problem, but I wanted to ask what the intention is with changed.
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 21:16:59 UTC, John Colvin wrote: On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote: On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote: And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). Which runs into GC-related issues when your client is a low-memory handheld device. Though arguably this would still be an improvement over JS, since an interpreted language necessarily uses more resources. You are getting pretty close to NaCl idea :) Yeah, I was thinking that :p NaCl seems designed mostly as native extensions for the html/js/css world. I was thinking bigger: The browser as a (transient, if appropriate) application delivery system. I really dislike html and css for anything other than simple documents, it quickly feels like one big patchily supported corner-case. Anything other than simple uses ends up requiring significant abuses, even if you're lucky enough to be working in a hypothetical totally standards compliant environment. Even something as simple as a drop-down menu with persistence means either: massively abuse css OR use JS. What I'm imagining is a truly dynamic web-delivered UI with native speed and processing capability, not just a faster web-app. This would still be working - to some extent, in the browser: the end user experience can be as seamless or as seperated as the developer wants. Your D app could look just like a webpage and behave just like a webpage, or it could be a totally separate window that appears to have no relation to the web as we know it. For an increasing number of users these days, the browser *is* the computer. They barely touch anything else. Nobody wants to install another program to do every little task, but they'll happily click a link to a specialised web-app. Native apps took off on mobile, but at the same time they were dying on the desktop. Now the view seems to be to want to kill them on mobile too and make everything a web-app. Perhaps we can get the best of both worlds. What I want is a true way out from the current obsession with trying to shoe-horn every possible use-case in to html/css/js with the associated necessary over-reliance on js, which is by all accounts a horrible language.
Re: Tool changed intended as part of release? (Requires libcurl.dll on Win)
On Saturday, 17 August 2013 at 21:49:06 UTC, Nick Sabalausky wrote: I don't see B as a problem, but I wanted to ask what the intention is with changed. It's only used by the core dev team to help create the change log, I don't think it should be distributed with the zipped release.
Re: [dox] Fixing the lexical rule for BinaryInteger
On Sat, Aug 17, 2013 at 11:29:03PM +0200, Andre Artus wrote: [...] H. S. Teoh wrote: I was just using BNF to show that it's possible to specify the behaviour precisely. And also that it's rather convoluted just for something as intuitively straightforward as an integer literal. Which is a likely reason why the current specs are a bit blurry about what should/shouldn't be allowed. I don't think I've seen lexemes defined using (a variant of) BNF before, most often a form of regular expressions are used. One could cut down and clarify the page describing the lexical syntax significantly employing simple regular expressions. You're right, I think the D specs page on literals using BNF is a bit of an overkill. Maybe it should be rewritten using regexen. It would be easier to understand, for one thing. [...] H. S. Teoh wrote: I know that, but I'm saying that hardly *any* code would break if we made DMD reject things like this. I don't think anybody in their right mind would write code like that. (Unless they were competing in the IODCC... :-P) I agree that the compiler should probably break that code, I believe some breaking changes are good when they help the programmer fix potential bugs. But I am also someone who compiles with Treat warnings as errors. Walter is someone who believes that compilers should only have errors, not warnings. :) [...] Andre Artus wrote: It's not a problem implementing the rule, I am more concerned with documenting it in a clear and unambiguous way so that people building tools from it can get it right. BNF isn't always the easiest way to do so, but it's what being used. H. S. Teoh wrote: Well, you could bug Walter about what *should* be accepted, I'm not sure how to go about that. Email him and ask? :) H. S. Teoh wrote: and if he agrees to restrict it to having _ only between two digits, then you'd file a bug against DMD. Well if we could get a ruling on this then we could include HexadecimalInteger in the ruling as it has similar behaviour in DMD. The current specification for DecimalInteger also allows a trailing sequence of underscores. It also does not include the sign as part of the token value. Yeah that sounds like a bug in the specs. Possible regex alternatives (note I do not include the sign, as per current spec). (0|[1-9]([_]*[0-9])*) or arguably better (0|[1-9]([_]?[0-9])*) [...] I think it should be: (0|[1-9]([0-9]*(_[0-9]+)*)?) That is, either it's a 0, or a single digit from 1-9, or 1-9 followed by (zero or more digits 0-9 followed by zero or more (underscore followed by one or more digits 0-9)). This enforces only a single underscore between digits, and no preceding/trailing underscores. So it would exclude things like 12_34, which is just as ridiculous as 123___, and only allow 12_34. T -- Blunt statements really don't have a point.
Re: Experiments with emscripten and D
W dniu 17.08.2013 23:05, Gambler pisze:
On 8/17/2013 12:43 PM, Piotr Szturmaj wrote:
W dniu 17.08.2013 16:42, Gambler pisze:
On 8/15/2013 5:55 PM, Piotr Szturmaj wrote:
bearophile:
Piotr Szturmaj:
I have found some related activity from Rust people:
https://github.com/mozilla/rust/issues/2235
https://github.com/Yoric/Mozilla-Student-Projects/issues/33
https://mail.mozilla.org/pipermail/rust-dev/2012-April/001607.html
Once your work is more more completed, the dlang site could show (in a
sub-page) the compiler that compiles the online examples of the docs
that's able to produce html+JS on the fly from the D code written in
the
browser.
Yes, and it could be used to write rich web applications (which is the
reason I'm working on it). JavaScript certainly wasn't created for big
codebases...
Never understood the excitement about things like these. Yes, it's
somewhat interesting and technically impressive, but in the end, the
only language that benefits here *is* JavaScript. And it's already
spreading like cancer. Why help it if you don't like it?
If even 1/10th of the effort spent on compile-everything-to-JS projects
was directed towards properly bringing other languages into the browser
land, the web would be a much better place now.
It's not about helping JavaScript. It's about using another language to
do client side scripting. I hate JS, I really don't like to write bigger
applications in it.
What happens when you forget a semicolon or a comma? Or make some typos?
It silently breaks. I don't care if there are tools to help with it.
It's still a mess. Did you see WAT
(https://www.destroyallsoftware.com/talks/wat) ? If not, please do. Here
are some examples of JS additions which WAT demonstrated:
[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN
Seriously, WTF!
WAT is one of my favorite language talks of all times. So we're on the
same page here. But I don't think compiling D to JavaScript is a viable
long-term solution.
1. The more languages compile to JS, the more powerful it becomes and
the harder it will be to replace JS with something better. People will
spend more money on optimizing its (not D's) performance, developing its
(not D's) APIs for stuff like sound and graphics. This is already
happening. I recently interviewed a junior developer for a position that
had nothing to do with JavaScript. At some point during the interview he
said: JavaScript is the future of everything. Yeah, it's the actual
phrasing he used. That's what some people believe in.
2. Compiling things to an intermediate language creates a whole host of
new problems you don't have originally. How do you debug? How do you
print an accurate stack trace? Etc.
This is known problem and many JS-like languages use source maps to
solve it.
3. Even if the tool-chain is perfect, a lot of real work in the browser
is done by calling APIs. If those APIs are designed for JavaScript,
their usage will not be idiomatic inside translated code unless you
manually create wrappers.
Yes, but we don't want to be strictly idiomatic. We just want to call JS
code (modify the DOM, enable a button, or interface to JS widget
toolkit). Idiomatic JS code more or less boils down to creating objects
and calling functions. GWT is another example of such effort. It
translates Java code to JS. GWT is used by many products at Google,
including AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet,
Blogger. - from GWT website.
It would still be fine if the whole thing hand some kind of gradual
upgrade path that led to using pure D, but I don't see such path.
There must be a first step :-)
And again, I don't want to write in it, but I _must_ use it. I just want
to use another language that translates to JS. There are many of them
already. Still, no one is even close to D in its usefulness.
My personal strategy to mitigate the horrors of JavaScript is to use
progressive enhancement and write small, targeted JS libraries that are
invoked declaratively (i.e. you include them, but then it's all about
HTML markup and there is no application-specific JS). Contrary to
popular opinion, this approach is capable of creating very efficient and
very dynamic websites.
This approach is limiting in some scenarios. Think about RIAs and
interfacing to existing JS libraries.
The whole problem is that you need to write a web applications _now_,
when the only supported languages for the web is JS. You really don't
have a choice. Even if other languages could be widely supported from
today, you'd still have to support older browsers. This means JS will
stay in for another couple of years.
If things don't change trajectory, I'm afraid JS will not just stay for
a couple of years. It will become de-facto standard for server-side web
computing and displace all other languages in that domain. In the
company I work for, there is already a number of people calling to
rewrite all the web app for Node. I don't
Re: std.serialization: pre-voting review / discussion
I'd like to start off by saying I don't really know what I want from a std.serialize module. I've done some work with a C# JSON serializer and dealt with Protocol Buffers. This library looks to be providing a means to serialize any D data structure. It deals with pointers/class/struct/arrays... It is export format agnostic, while currently only XML is available, allowing for export to JSON or some binary form. Afterwards the data can return to the program through deserialization. This is a use-case I don't think I've needed. Though I do see the value in it and would expect Phobos to provide such functionality. What I'm not finding in this library is a way to support a 3rd party protocol. Such as those used in Thrift or Protocol Buffers. These specify some aspects of data layout, for example in Protocol Buffers arrays of primitives can be laid out in two forms [ID][value][ID][value] or [ID][Length][value][value]. Thrift and Protocol Buffers use code generation to create the language data type, and at least for Protocol Buffers a method contains all the logic for deserializing a collection of bytes, and one for serializing. I'm not seeing how std.serialize would make this easier or more usable. When looking at the Archive module, I see that all the specific types get their own void function. I'm unclear on where these functions are supposed to archive to, and container types take a delegate which I suppose is a means for the archiver to place output around the field data. In conclusion, I don't feel like I've said very much. I don't think std.serialize is applicable to Protocol Buffers or Thrift, and I don't know what benefit there would be if it was.
Re: [dox] Fixing the lexical rule for BinaryInteger
[...] H. S. Teoh wrote: I was just using BNF to show that it's possible to specify the behaviour precisely. And also that it's rather convoluted just for something as intuitively straightforward as an integer literal. Which is a likely reason why the current specs are a bit blurry about what should/shouldn't be allowed. Andre Artus wrote: I don't think I've seen lexemes defined using (a variant of) BNF before, most often a form of regular expressions are used. One could cut down and clarify the page describing the lexical syntax significantly employing simple regular expressions. H. S. Teoh wrote: You're right, I think the D specs page on literals using BNF is a bit of an overkill. Maybe it should be rewritten using regexen. It would be easier to understand, for one thing. I would not mind doing this, I'll see what Walter says. It would also be quite easy to generate syntax diagrams from a reg-expr. [...] H. S. Teoh wrote: I know that, but I'm saying that hardly *any* code would break if we made DMD reject things like this. I don't think anybody in their right mind would write code like that. (Unless they were competing in the IODCC... :-P) I agree that the compiler should probably break that code, I believe some breaking changes are good when they help the programmer fix potential bugs. But I am also someone who compiles with Treat warnings as errors. H. S. Teoh wrote: Walter is someone who believes that compilers should only have errors, not warnings. :) That can go both ways, but I suspect you mean that in the good way. [...] Andre Artus wrote: It's not a problem implementing the rule, I am more concerned with documenting it in a clear and unambiguous way so that people building tools from it can get it right. BNF isn't always the easiest way to do so, but it's what being used. H. S. Teoh wrote: Well, you could bug Walter about what *should* be accepted, I'm not sure how to go about that. H. S. Teoh wrote: Email him and ask? :) I'll try that. H. S. Teoh wrote: and if he agrees to restrict it to having _ only between two digits, then you'd file a bug against DMD. Well if we could get a ruling on this then we could include HexadecimalInteger in the ruling as it has similar behaviour in DMD. The current specification for DecimalInteger also allows a trailing sequence of underscores. It also does not include the sign as part of the token value. H. S. Teoh wrote: Yeah that sounds like a bug in the specs. Yes, I believe so. The same issues are under Floating Point Literals. Should be easy to fix. Possible regex alternatives (note I do not include the sign, as per current spec). (0|[1-9]([_]*[0-9])*) or arguably better (0|[1-9]([_]?[0-9])*) [...] I think it should be: (0|[1-9]([0-9]*(_[0-9]+)*)?) That is, either it's a 0, or a single digit from 1-9, or 1-9 followed by (zero or more digits 0-9 followed by zero or more (underscore followed by one or more digits 0-9)). This enforces only a single underscore between digits, and no preceding/trailing underscores. So it would exclude things like 12_34, which is just as ridiculous as 123___, and only allow 12_34. I concur with your assessment. I believe my second reg-ex is functionally equivalent to the one you propose (test results below). Although I would concede that yours may be easier to grok. The following match my regex (assuming it's whitespace delimited) 1 1_1 1_2_3_4_5_6_7_8_9_0 1234_45_15 1234567_8_90 123456789_0 1_234567890 12_34567890 123_4567890 1234_567890 12345_67890 123456_7890 1234567_890 12345678_90 123456789_0 123_45_6_789012345_67890 Whereas these do not _1 1_ _1_ 1__1 -12_34 -1234 123_45_6__789012345_67890 1234567890_ _1234567890_ _1234567890 1234567890_
Re: [dox] Fixing the lexical rule for BinaryInteger
[...] For fun I made a scanner rule that forces BinaryInteger to conform to a power of 2 grouping of nibbles. I think it loses it's clarity after 16 bits. I made the underscore optional between nibbles, but required for groups of 2 bytes and above. Some passing cases from my test inputs. 0b00010001 0b0001_0001 0b00010001_0001_0001 0b00010001_00010001 0b0001_0001_00010001 0b00010001_00010001 0b00010001_00010001_00010001_00010001 0b00010001_00010001_00010001_00010001_00010001_00010001_00010001_00010001 0b00010001_00010001_00010001_00010001_00010001_0001_0001_00010001_00010001_00010001_00010001_00010001_00010001_00010001_00010001_00010001_00010001 It loses some of the value of arbitrary grouping specifically the ability to group bits in a bitmask by function.
Re: GPGPUs
We basically have to follow these rules,
1. The range must be none prior to execution of a gpu code block
2. The range can not be changed during execution of a gpu code
block
3. Code blocks can only receive a single range, it can however be
multidimensional
4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many
instances in parallel each with their own unique key)
6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower then
on the cpu
11. separate running instances of the same code block on the gpu
can not have any interdependency on each other.
Now if we are talking about HSA, or other similar setup, then a
few of those rules don't apply or become fuzzy.
HSA, does have limited access to global state, HSA can call cpu
functions that are pure, and of course because in HSA the cpu and
gpu share the same virtual address space most of memory is open
for access.
HSA also manages memory, via the hMMU, and their is no need for
gpu memory management functions, as that is managed by the
operating system and video card drivers.
Basically, D would either need to opt out of legacy api's such as
openCL, CUDA, etc, these are mostly tied to c/c++ anyway, and
generally have ugly as sin syntax; or D would have go the route
of a full and safe gpu subset of features.
I don't think such a setup can be implemented as simply a
library, as the GPU needs compiled source.
If D where to implement gpgpu features, I would actually suggest
starting by simply adding a microthreading function syntax, for
example...
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
By adding an aggregate keyword to the function, we can assume the
range simply using the length of a[] without adding an extra set
of brackets or something similar.
This would make access to the gpu more generic, and more
importantly, because llvm will support HSA, removes the needs for
writing more complex support into dmd as openCL and CUDA would
require, a few hints for the llvm backend would be enough to
generate the dual bytecode ELF executables.
Re: GPGPUs
Unified virtual address-space I can accept, fine. Ignoring that
it is, in fact, in a totally different address-space where memory
latency is *entirely different*, I'm far *far* more iffy about.
We basically have to follow these rules,
1. The range must be none prior to execution of a gpu code block
2. The range can not be changed during execution of a gpu code
block
3. Code blocks can only receive a single range, it can however
be multidimensional
4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many
instances in parallel each with their own unique key)
6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower then
on the cpu
11. separate running instances of the same code block on the
gpu can not have any interdependency on each other.
Please explain point 1 (specifically the use of the word 'none'),
and why you added in point 3?
Additionally, point 11 doesn't make any sense to me. There is
research out there showing how to use cooperative warp-scans, for
example, to have multiple work-items cooperate over some local
block of memory and perform sorting in blocks. There are even
tutorials out there for OpenCL and CUDA that shows how to do
this, specifically to create better performing code. This
statement is in direct contradiction with what exists.
Now if we are talking about HSA, or other similar setup, then a
few of those rules don't apply or become fuzzy.
HSA, does have limited access to global state, HSA can call cpu
functions that are pure, and of course because in HSA the cpu
and gpu share the same virtual address space most of memory is
open for access.
HSA also manages memory, via the hMMU, and their is no need for
gpu memory management functions, as that is managed by the
operating system and video card drivers.
Good for HSA. Now why are we latching onto this particular
construction that, as far as I can tell, is missing the support
of at least two highly relevant giants (Intel and NVidia)?
Basically, D would either need to opt out of legacy api's such
as openCL, CUDA, etc, these are mostly tied to c/c++ anyway,
and generally have ugly as sin syntax; or D would have go the
route of a full and safe gpu subset of features.
Wrappers do a lot to change the appearance of a program. Raw
OpenCL may look ugly, but so do BLAS and LAPACK routines. The use
of wrappers and expression templates does a lot to clean up code
(ex. look at the way Eigen 3 or any other linear algebra library
does expression templates in C++; something D can do even better).
I don't think such a setup can be implemented as simply a
library, as the GPU needs compiled source.
This doesn't make sense. Your claim is contingent on opting out
of OpenCL or any other mechanism that provides for the
application to carry abstract instructions which are then
compiled on the fly. If you're okay with creating kernel code on
the fly, this can be implemented as a library, beyond any
reasonable doubt.
If D where to implement gpgpu features, I would actually
suggest starting by simply adding a microthreading function
syntax, for example...
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
By adding an aggregate keyword to the function, we can assume
the range simply using the length of a[] without adding an
extra set of brackets or something similar.
This would make access to the gpu more generic, and more
importantly, because llvm will support HSA, removes the needs
for writing more complex support into dmd as openCL and CUDA
would require, a few hints for the llvm backend would be enough
to generate the dual bytecode ELF executables.
1) If you wanted to have that 'key' nonsense in there, I'm
thinking you'd need to add several additional parameters: global
size, group size, group count, and maybe group-local memory
access (requires allowing multiple aggregates?). I mean, I get
the gist of what you're saying, this isn't me pointing out a
problem, just trying to get a clarification on it (maybe give
'key' some additional structure, or something).
2) ... I kind of like this idea. I disagree with how you led up
to it, but I like the idea.
3) How do you envision *calling* microthreaded code? Just the
usual syntax?
4) How would this handle working on subranges?
ex. Let's say I'm coding up a radix sort using something like
this:
https://sites.google.com/site/duanemerrill/PplGpuSortingPreprint.pdf?attredirects=0
What's the high-level program organization with this syntax if we
can only use one range at a time? How many work-items get fired
off? What's the gpu-code launch procedure?
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote: And you'd have to sandbox the code since arbitrary D code running wild on the user's computer is a Bad Thing(tm). You have to do that with javascript anyway, just in case your impl has a security flaw. Run it in a separate process with a restricted security token and you'll be in decent shape. ...though, you know, just thinking wildly here, I wonder how well it'd work if you used a virtual machine. They are pretty quick nowadays thanks to fancy hardware and such. What if your browser extension fired up a tiny little virtual machine, ran the one process and just mapped its video framebuffer to the browser window? Then the one program can just be a standard program using a special library (I've make small executables with an unmodified dmd that can run on bare metal), no need to modify the compiler like with google's salt thing. I wonder how hard it would be to write that. Searching the web for kvm though always assumes qemu. No, I want to write a super-small qemu, and I don't care if it can't boot linux. How hard can it be? but i'd better not get too much into it, I already have other plans for the next few weeks. Gotta finish my minigui.d!
Re: Experiments with emscripten and D
W dniu 18.08.2013 03:58, Adam D. Ruppe pisze: I wonder how hard it would be to write that. Searching the web for kvm though always assumes qemu. No, I want to write a super-small qemu, and I don't care if it can't boot linux. How hard can it be? Someone has written an LLVM backend for DCPU-16 and here's the JS emulator of it: https://github.com/mappum/DCPU-16
Redundancy in std.stdio name
As a frustrated C++ user, I was sniffing around D for a decade. Today, I started reading The D Programming Language. The first line of the first code example in this book: import std.stdio triggered my redundancy detector. Does it have to be std.stdio? How about std.io?
Re: Redundancy in std.stdio name
On Sunday, 18 August 2013 at 02:26:59 UTC, Paul Jurczak wrote: As a frustrated C++ user, I was sniffing around D for a decade. Today, I started reading The D Programming Language. The first line of the first code example in this book: import std.stdio triggered my redundancy detector. Does it have to be std.stdio? How about std.io? I think there's a replacement in the works, but I'm not sure of the status on that: http://forum.dlang.org/thread/vnpriguleebpbzhkp...@forum.dlang.org#post-mailman.234.1362471736.14496.digitalmars-d:40puremagic.com
Re: Redundancy in std.stdio name
On Sunday, 18 August 2013 at 02:26:59 UTC, Paul Jurczak wrote: As a frustrated C++ user, I was sniffing around D for a decade. Today, I started reading The D Programming Language. The first line of the first code example in this book: import std.stdio triggered my redundancy detector. Does it have to be std.stdio? How about std.io? std.stdio's upcoming replacement is called std.io. std.stdio is called stdio because it's based on C's stdio.h.
Re: GPGPUs
On Sunday, 18 August 2013 at 01:43:33 UTC, Atash wrote:
Unified virtual address-space I can accept, fine. Ignoring that
it is, in fact, in a totally different address-space where
memory latency is *entirely different*, I'm far *far* more iffy
about.
We basically have to follow these rules,
1. The range must be none prior to execution of a gpu code
block
2. The range can not be changed during execution of a gpu code
block
3. Code blocks can only receive a single range, it can however
be multidimensional
4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many
instances in parallel each with their own unique key)
6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower
then on the cpu
11. separate running instances of the same code block on the
gpu can not have any interdependency on each other.
Please explain point 1 (specifically the use of the word
'none'), and why you added in point 3?
Additionally, point 11 doesn't make any sense to me. There is
research out there showing how to use cooperative warp-scans,
for example, to have multiple work-items cooperate over some
local block of memory and perform sorting in blocks. There are
even tutorials out there for OpenCL and CUDA that shows how to
do this, specifically to create better performing code. This
statement is in direct contradiction with what exists.
Now if we are talking about HSA, or other similar setup, then
a few of those rules don't apply or become fuzzy.
HSA, does have limited access to global state, HSA can call
cpu functions that are pure, and of course because in HSA the
cpu and gpu share the same virtual address space most of
memory is open for access.
HSA also manages memory, via the hMMU, and their is no need
for gpu memory management functions, as that is managed by the
operating system and video card drivers.
Good for HSA. Now why are we latching onto this particular
construction that, as far as I can tell, is missing the support
of at least two highly relevant giants (Intel and NVidia)?
Basically, D would either need to opt out of legacy api's such
as openCL, CUDA, etc, these are mostly tied to c/c++ anyway,
and generally have ugly as sin syntax; or D would have go the
route of a full and safe gpu subset of features.
Wrappers do a lot to change the appearance of a program. Raw
OpenCL may look ugly, but so do BLAS and LAPACK routines. The
use of wrappers and expression templates does a lot to clean up
code (ex. look at the way Eigen 3 or any other linear algebra
library does expression templates in C++; something D can do
even better).
I don't think such a setup can be implemented as simply a
library, as the GPU needs compiled source.
This doesn't make sense. Your claim is contingent on opting out
of OpenCL or any other mechanism that provides for the
application to carry abstract instructions which are then
compiled on the fly. If you're okay with creating kernel code
on the fly, this can be implemented as a library, beyond any
reasonable doubt.
If D where to implement gpgpu features, I would actually
suggest starting by simply adding a microthreading function
syntax, for example...
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
By adding an aggregate keyword to the function, we can assume
the range simply using the length of a[] without adding an
extra set of brackets or something similar.
This would make access to the gpu more generic, and more
importantly, because llvm will support HSA, removes the needs
for writing more complex support into dmd as openCL and CUDA
would require, a few hints for the llvm backend would be
enough to generate the dual bytecode ELF executables.
1) If you wanted to have that 'key' nonsense in there, I'm
thinking you'd need to add several additional parameters:
global size, group size, group count, and maybe group-local
memory access (requires allowing multiple aggregates?). I mean,
I get the gist of what you're saying, this isn't me pointing
out a problem, just trying to get a clarification on it (maybe
give 'key' some additional structure, or something).
2) ... I kind of like this idea. I disagree with how you led up
to it, but I like the idea.
3) How do you envision *calling* microthreaded code? Just the
usual syntax?
4) How would this handle working on subranges?
ex. Let's say I'm coding up a radix sort using something like
this:
https://sites.google.com/site/duanemerrill/PplGpuSortingPreprint.pdf?attredirects=0
What's the high-level program organization with this syntax if
we can only use one range at a time? How many work-items get
fired off? What's the gpu-code launch procedure?
sorry typo,
Re: Redundancy in std.stdio name
On Sunday, 18 August 2013 at 02:42:32 UTC, Brad Anderson wrote: On Sunday, 18 August 2013 at 02:26:59 UTC, Paul Jurczak wrote: As a frustrated C++ user, I was sniffing around D for a decade. Today, I started reading The D Programming Language. The first line of the first code example in this book: import std.stdio triggered my redundancy detector. Does it have to be std.stdio? How about std.io? std.stdio's upcoming replacement is called std.io. std.stdio is called stdio because it's based on C's stdio.h. Wow, that was fast! Thanks guys.
Re: GPGPUs
On Sunday, 18 August 2013 at 01:43:33 UTC, Atash wrote:
Unified virtual address-space I can accept, fine. Ignoring that
it is, in fact, in a totally different address-space where
memory latency is *entirely different*, I'm far *far* more iffy
about.
We basically have to follow these rules,
1. The range must be none prior to execution of a gpu code
block
2. The range can not be changed during execution of a gpu code
block
3. Code blocks can only receive a single range, it can however
be multidimensional
4. index keys used in a code block are immutable
5. Code blocks can only use a single key(the gpu executes many
instances in parallel each with their own unique key)
6. index's are always an unsigned integer type
7. openCL,CUDA have no access to global state
8. gpu code blocks can not allocate memory
9. gpu code blocks can not call cpu functions
10. atomics tho available on the gpu are many times slower
then on the cpu
11. separate running instances of the same code block on the
gpu can not have any interdependency on each other.
Please explain point 1 (specifically the use of the word
'none'), and why you added in point 3?
Additionally, point 11 doesn't make any sense to me. There is
research out there showing how to use cooperative warp-scans,
for example, to have multiple work-items cooperate over some
local block of memory and perform sorting in blocks. There are
even tutorials out there for OpenCL and CUDA that shows how to
do this, specifically to create better performing code. This
statement is in direct contradiction with what exists.
You do have limited Atomics, but you don't really have any sort
of complex messages, or anything like that.
Now if we are talking about HSA, or other similar setup, then
a few of those rules don't apply or become fuzzy.
HSA, does have limited access to global state, HSA can call
cpu functions that are pure, and of course because in HSA the
cpu and gpu share the same virtual address space most of
memory is open for access.
HSA also manages memory, via the hMMU, and their is no need
for gpu memory management functions, as that is managed by the
operating system and video card drivers.
Good for HSA. Now why are we latching onto this particular
construction that, as far as I can tell, is missing the support
of at least two highly relevant giants (Intel and NVidia)?
Intel doesn't have a dog in this race, so their is no way to know
what they plan on doing if anything at all.
The reason to point out HSA, is because it is really easy add
support for, it is not a giant task like opencl would be. A few
changes to the front end compiler is all that is needed, LLVM's
backend does the rest.
Basically, D would either need to opt out of legacy api's such
as openCL, CUDA, etc, these are mostly tied to c/c++ anyway,
and generally have ugly as sin syntax; or D would have go the
route of a full and safe gpu subset of features.
Wrappers do a lot to change the appearance of a program. Raw
OpenCL may look ugly, but so do BLAS and LAPACK routines. The
use of wrappers and expression templates does a lot to clean up
code (ex. look at the way Eigen 3 or any other linear algebra
library does expression templates in C++; something D can do
even better).
I don't think such a setup can be implemented as simply a
library, as the GPU needs compiled source.
This doesn't make sense. Your claim is contingent on opting out
of OpenCL or any other mechanism that provides for the
application to carry abstract instructions which are then
compiled on the fly. If you're okay with creating kernel code
on the fly, this can be implemented as a library, beyond any
reasonable doubt.
OpenCL isn't just a library, it is a language extension, that is
ran through a preprocessor that compiles the embedded __KERNEL
and __DEVICE functions, into usable code, and then outputs
.c/.cpp files for the c compiler to deal with.
If D where to implement gpgpu features, I would actually
suggest starting by simply adding a microthreading function
syntax, for example...
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
By adding an aggregate keyword to the function, we can assume
the range simply using the length of a[] without adding an
extra set of brackets or something similar.
This would make access to the gpu more generic, and more
importantly, because llvm will support HSA, removes the needs
for writing more complex support into dmd as openCL and CUDA
would require, a few hints for the llvm backend would be
enough to generate the dual bytecode ELF executables.
1) If you wanted to have that 'key' nonsense in there, I'm
thinking you'd need to add several additional parameters:
global size, group size, group count, and maybe group-local
memory access (requires allowing multiple aggregates?). I mean,
I get the gist of what you're saying, this isn't me pointing
out a
Re: Experiments with emscripten and D
On Saturday, 17 August 2013 at 16:43:14 UTC, Piotr Szturmaj wrote:
What happens when you forget a semicolon or a comma? Or make
some typos? It silently breaks. I don't care if there are tools
to help with it. It's still a mess. Did you see WAT
(https://www.destroyallsoftware.com/talks/wat) ? If not, please
do. Here are some examples of JS additions which WAT
demonstrated:
[] + [] // yields empty string
[] + {} // [object Object]
{} + [] // 0
{} + {} // NaN
Seriously, WTF!
I could explain, but I'm not sure you are interested. The
ambiguity on that one come from {} being either an object literal
or a block statement.
I feel pretty confident I can do a wat speech for D.
Obviously, you can't share every possible code. It's about
sharing the cross cutting parts. Imagine an application with a
server, web frontend and desktop frontend. With shared
codebases, you could write one client code. Just use the same
abstractions for the web and for the desktop. Then you can
create similar interfaces from the same codebase. It's a huge
win. Duplicating efforts is tiresome, error prone and obviously
takes time.
It has already been done, but didn't caught up. Actually I can't
even find theses project in google, so I guess ti was a compete
fail.
It worked, but cause many problem, especially securitywise.
Re: GPGPUs
On Sunday, 18 August 2013 at 03:55:58 UTC, luminousone wrote:
You do have limited Atomics, but you don't really have any sort
of complex messages, or anything like that.
I said 'point 11', not 'point 10'. You also dodged points 1 and
3...
Intel doesn't have a dog in this race, so their is no way to
know what they plan on doing if anything at all.
http://software.intel.com/en-us/vcsource/tools/opencl-sdk
http://www.intel.com/content/www/us/en/processors/xeon/xeon-phi-detail.html
Just based on those, I'm pretty certain they 'have a dog in this
race'. The dog happens to be running with MPI and OpenCL across a
bridge made of PCIe.
The reason to point out HSA, is because it is really easy add
support for, it is not a giant task like opencl would be. A few
changes to the front end compiler is all that is needed, LLVM's
backend does the rest.
H'okay. I can accept that.
OpenCL isn't just a library, it is a language extension, that
is ran through a preprocessor that compiles the embedded
__KERNEL and __DEVICE functions, into usable code, and then
outputs .c/.cpp files for the c compiler to deal with.
But all those extra bits are part of the computing *environment*.
Is there something wrong with requiring the proper environment
for an executable?
A more objective question: which devices are you trying to target
here?
Those are all platform specific, they change based on the whim
and fancy of NVIDIA and AMD with each and every new chip
released, The size and configuration of CUDA clusters, or
compute clusters, or EU's, or whatever the hell x chip maker
feels like using at the moment.
Long term this will all be managed by the underlying support
software in the video drivers, and operating system kernel.
Putting any effort into this is a waste of time.
Yes. And the only way to optimize around them is to *know them*,
otherwise you're pinning the developer down the same way OpenMP
does. Actually, even worse than the way OpenMP does - at least
OpenMP lets you set some hints about how many threads you want.
void example( aggregate in float a[] ; key , in float b[], out
float c[]) {
c[key] = a[key] + b[key];
}
example(a,b,c);
in the function declaration you can think of the aggregate
basically having the reserve order of the items in a foreach
statement.
int a[100] = [ ... ];
int b[100];
foreach( v, k ; a ) { b = a[k]; }
int a[100] = [ ... ];
int b[100];
void example2( aggregate in float A[] ; k, out float B[] ) {
B[k] = A[k]; }
example2(a,b);
Contextually solid. Read my response to the next bit.
I am pretty sure they are simply multiplying the index value by
the unit size they desire to work on
int a[100] = [ ... ];
int b[100];
void example3( aggregate in range r ; k, in float a[], float
b[]){
b[k] = a[k];
b[k+1] = a[k+1];
}
example3( 0 .. 50 , a,b);
Then likely they are simply executing multiple __KERNEL
functions in sequence, would be my guess.
I've implemented this algorithm before in OpenCL already, and
what you're saying so far doesn't rhyme with what's needed.
There are at least two ranges, one keeping track of partial
summations, the other holding the partial sorts. Three separate
kernels are ran in cycles to reduce over and scatter the data.
The way early exit is implemented isn't mentioned as part of the
implementation details, but my implementation of the strategy
requires a third range to act as a flag array to be reduced over
and read in between kernel invocations.
It isn't just unit size multiplication - there's communication
between work-items and *exquisitely* arranged local-group
reductions and scans (so-called 'warpscans') that take advantage
of the widely accepted concept of a local group of work-items (a
parameter you explicitly disregarded) and their shared memory
pool. The entire point of the paper is that it's possible to come
up with a general algorithm that can be parameterized to fit
individual GPU configurations if desired. This kind of algorithm
provides opportunities for tuning... which seem to be lost,
unnecessarily, in what I've read so far in your descriptions.
My point being, I don't like where this is going by treating
coprocessors, which have so far been very *very* different from
one another, as the same batch of *whatever*. I also don't like
that it's ignoring NVidia, and ignoring Intel's push for
general-purpose accelerators such as their Xeon Phi.
But, meh, if HSA is so easy, then it's low-hanging fruit, so
whatever, go ahead and push for it.
=== REMINDER OF RELEVANT STUFF FURTHER UP IN THE POST:
A more objective question: which devices are you trying to
target here?
=== AND SOMETHING ELSE:
I feel like we're just on different wavelengths. At what level do
you imagine having this support, in terms of support for doing
low-level things? Is this something like OpenMP, where threading
and such are done at a really (really really really...) high
level, or
Re: Possible codegen bug when using Tcl/Tk (related to DMC and DMD)
On Saturday, 17 August 2013 at 21:34:24 UTC, Andrej Mitrovic
wrote:
I think this is the same issue as
https://github.com/aldacron/Derelict3/issues/143
The solution advised by aldacron (Mike Parker) in his last few
posts is to compile your D executable as a Windows subsystem exe
or use WinMain instead of main.
On 8/17/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
First, here is the C code:
Btw, here's the D equivalent where I can also recreate the bug:
-
import core.sys.windows.windows;
import std.stdio;
alias extern(C) void* function() Tcl_CreateInterp_Type;
alias extern(C) int function(void*) Tcl_Init_Type;
alias extern(C) int function(void*) Tk_Init_Type;
alias extern(C) int function(void*, const(char)*) Tcl_Eval_Type;
alias extern(C) void function() Tk_MainLoop_Type;
int main()
{
HMODULE hTcl = LoadLibraryA(tcl86.dll);
HMODULE hTk = LoadLibraryA(tk86.dll);
Tcl_CreateInterp_Type Tcl_CreateInterp;
Tcl_CreateInterp =
cast(Tcl_CreateInterp_Type)GetProcAddress(hTcl,
Tcl_CreateInterp);
Tcl_Init_Type Tcl_Init;
Tcl_Init = cast(Tcl_Init_Type)GetProcAddress(hTcl,
Tcl_Init);
Tk_Init_Type Tk_Init;
Tk_Init = cast(Tk_Init_Type)GetProcAddress(hTk, Tk_Init);
Tcl_Eval_Type Tcl_Eval;
Tcl_Eval = cast(Tcl_Eval_Type)GetProcAddress(hTcl,
Tcl_Eval);
Tk_MainLoop_Type Tk_MainLoop;
Tk_MainLoop = cast(Tk_MainLoop_Type)GetProcAddress(hTk,
Tk_MainLoop);
void* _interp = Tcl_CreateInterp();
Tcl_Init(_interp);
Tk_Init(_interp);
Tcl_Eval(_interp, tkwait visibility .);
Tcl_Eval(_interp, tk::toplevel .mywin);
Tcl_Eval(_interp, wm resizable .mywin false false);
Tk_MainLoop();
return 0;
}
-
I've also tried the C sample with various DMC versions such as
857,
846, 837, 830, but I still haven't found a version that doesn't
have
this bug.
Maybe the issue is with something else.. I can't tell what DMC
and GCC
are doing differently here.
