www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Python's features, which requires D

reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
Hi,
I've collected some of Python's features. It seems to me that 
they are not in the D!

Surely all this is in the D? :)
http://rextester.com/CNQQR3333
May 21 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote:
 Hi,
 I've collected some of Python's features. It seems to me that 
 they are not in the D!

 Surely all this is in the D? :)
 http://rextester.com/CNQQR3333
D doesn't have list comprehensions, so it's difficult to directly port these. off the top of my head, the last one can easily be done with std.range.stride
P.S. I think that all of this is written in D is much more lines 
of code!
and they can be done in less with APL and J.
May 21 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Friday, 22 May 2015 at 01:17:17 UTC, weaselcat wrote:
 D doesn't have list comprehensions, so it's difficult to 
 directly port these.
I can not imagine how difficult it is to implement it in D, but I'm pretty sure that nested for loops to fill arrays (in D, you can call them differently, for example, force :)) will be very useful thing, because Python is a veryIt is often used. Besides, I do not understand what could be the problem with nested loops in arrays, because std.algorithm.map works on the principle of nested loops. I think that the biggest problem in the implementation of this should not be. Excuse me if I'm wrong.
 off the top of my head, the last one can easily be done with 
 std.range.stride
import std.stdio, std.range; void main() { int[] a = [ 1, 2, 3, 4, 5, 6 ]; writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK // [2, 4, 6] #even #print(x[1::2]) #no equivalent in D auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]; // [2, 6, 10] #print(x[1::4]) #no equivalent in D }
May 21 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 22 May 2015 at 01:52:30 UTC, Dennis Ritchie wrote:
 On Friday, 22 May 2015 at 01:17:17 UTC, weaselcat wrote:
 D doesn't have list comprehensions, so it's difficult to 
 directly port these.
I can not imagine how difficult it is to implement it in D, but I'm pretty sure that nested for loops to fill arrays (in D, you can call them differently, for example, force :)) will be very useful thing, because Python is a veryIt is often used. Besides, I do not understand what could be the problem with nested loops in arrays, because std.algorithm.map works on the principle of nested loops. I think that the biggest problem in the implementation of this should not be. Excuse me if I'm wrong.
 off the top of my head, the last one can easily be done with 
 std.range.stride
import std.stdio, std.range; void main() { int[] a = [ 1, 2, 3, 4, 5, 6 ]; writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK // [2, 4, 6] #even #print(x[1::2]) #no equivalent in D
writeln(stride(a[1..$], 2));
     auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
     // [2, 6, 10] #print(x[1::4]) #no equivalent in D
writeln(stride(a[1..$], 4));
 }
May 21 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Friday, 22 May 2015 at 02:18:23 UTC, weaselcat wrote:
 On Friday, 22 May 2015 at 01:52:30 UTC, Dennis Ritchie wrote:
 off the top of my head, the last one can easily be done with 
 std.range.stride
import std.stdio, std.range; void main() { int[] a = [ 1, 2, 3, 4, 5, 6 ]; writeln(stride(a, 2)); // [1, 3, 5] #odd #print(x[::2]) #OK // [2, 4, 6] #even #print(x[1::2]) #no equivalent in D
writeln(stride(a[1..$], 2));
    auto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
    // [2, 6, 10] #print(x[1::4]) #no equivalent in D
writeln(stride(a[1..$], 4));
 }
Yes, this is what you need (I often forget that the functions can take ranges in D). Maybe somewhere and nested loops "for" to fill the arrays lying around :)
May 21 2015
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/21/2015 05:23 PM, Dennis Ritchie wrote:
 Hi,
 I've collected some of Python's features. It seems to me that they are
 not in the D!

 Surely all this is in the D? :)
 http://rextester.com/CNQQR3333
Here is my attempt: import std.stdio; import std.algorithm; import std.conv; import std.range; void main() { // Replace 'none' with 'all' to activate. version (none) { const n = 5; auto a = stdin .byLine .map!(l => l.splitter.map!(to!int).array) .take(n); writeln(a); writeln("-----"); } { const n = 6; auto a = iota(n) .map!(i => chain([2].replicate(i), [1], [0].replicate(n - i - 1))); writefln("%(%(%s %)\n%)", a); writeln("-----"); } { const x = [ 1, 2, 3, 4, 5, 6 ]; writeln(x.stride(2)); writeln(x.dropOne.stride(2)); writeln("-----"); } { // The internet does not need another fizz buzz. :p } } Ali
May 21 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Friday, 22 May 2015 at 05:31:38 UTC, Ali Çehreli wrote:
 Here is my attempt:

 import std.stdio;
 import std.algorithm;
 import std.conv;
 import std.range;

 void main()
 {
     // Replace 'none' with 'all' to activate.
     version (none) {
         const n = 5;

         auto a = stdin
                  .byLine
                  .map!(l => l.splitter.map!(to!int).array)
                  .take(n);

         writeln(a);
         writeln("-----");
     }

     {
         const n = 6;

         auto a = iota(n)
                  .map!(i => chain([2].replicate(i),
                                   [1],
                                   [0].replicate(n - i - 1)));

         writefln("%(%(%s %)\n%)", a);
         writeln("-----");
     }

     {
         const x = [ 1, 2, 3, 4, 5, 6 ];

         writeln(x.stride(2));
         writeln(x.dropOne.stride(2));
         writeln("-----");
     }

     {
         // The internet does not need another fizz buzz. :p
     }
 }

 Ali
Yes, it looks pretty good :) Thanks. But... It seems to me that D lacks features that allow you to write function readln/readln.strip/readln.split just inside the lambda. stdin.byLine is a good feature, but it captures the entire input stream, which I should handle all or take lambdas function take(n) n lines and then still handle all of these lines right away. Ie stdin.byline used everywhere is not always convenient! For example, the code in Python looks quite natural: a = [[int(j) for j in input().split()] for i in range(n)] About D-code, I can not say:
auto a = stdin
          .byLine
          .map!(l => l.splitter.map!(to!int).array)
          .take(n);
I can call the map with the existing array: import std.stdio, std.algorithm, std.conv, std.array; void main() { auto a = [1, 2, 3]; auto b = a.map!(c => c ~ readln.split.map!(to!int).array).array; writeln(b); } ----- http://rextester.com/MBUMHI13858 But I can not call the readln n times without a map: import std.stdio, std.conv, std.algorithm, std.array, std.range; void main() { auto a = [1, 2, 3]; auto b = [readln.split.map!(to!int).array].take(3); writeln(b); } ----- http://rextester.com/KCJ9346 Ie readln function cycle is needed for, another lambda or revised map! Is there a function in Phobos?
May 22 2015
next sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
By the way, Python has deepDup :)

http://rextester.com/KBFA82886
May 22 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Saturday, 23 May 2015 at 02:36:14 UTC, Dennis Ritchie wrote:
 For example, the code in Python looks quite natural:

 a = [[int(j) for j in input().split()] for i in range(n)]

 About D-code, I can not say:

auto a = stdin
         .byLine
         .map!(l => l.splitter.map!(to!int).array)
         .take(n);
Well, list comprehension is built into language in python (and not in D), such level of support is definitely more streamlined.
May 23 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 10:58:33 UTC, Kagamin wrote:
 Well, list comprehension is built into language in python (and 
 not in D), such level of support is definitely more streamlined.
Well, what's to keep D more functions to work with slist and dlist ? In my opinion, lists in D completely bald :) After all, there is a module in Phobos std.array, so why not make the module std.list. Do lists in D can be done as powerful as arrays?
May 23 2015
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 2015-05-23 at 12:58 +0000, Dennis Ritchie via
Digitalmars-d-learn wrote:
 On Saturday, 23 May 2015 at 10:58:33 UTC, Kagamin wrote:
 Well, list comprehension is built into language in python (and=20
 not in D), such level of support is definitely more streamlined.
=20 Well, what's to keep D more functions to work with slist and=20 dlist ? In my opinion, lists in D completely bald :) =20 After all, there is a module in Phobos std.array, so why not make=20 the module std.list. Do lists in D can be done as powerful as arrays?
The issue is performance, especially for random access to the sequence. Not all abstractions are equal! List structures are only really useful in very limited circumstances, generally you want more efficient sequence realizations: array, deque, etc. It is also probably worth noting that lists in Python are not singly or doubly linked lists, they are arrays. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 23 2015
prev sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 10:58:33 UTC, Kagamin wrote:
 On Saturday, 23 May 2015 at 02:36:14 UTC, Dennis Ritchie wrote:
 For example, the code in Python looks quite natural:

 a = [[int(j) for j in input().split()] for i in range(n)]

 About D-code, I can not say:

auto a = stdin
         .byLine
         .map!(l => l.splitter.map!(to!int).array)
         .take(n);
Well, list comprehension is built into language in python (and not in D), such level of support is definitely more streamlined.
Yes, but D is also possible to create a strong inclusion of list comprehensions. Here's the proof: https://github.com/pplantinga/delight
 Probably the coolest feature in Delight is list comprehensions. 
 Delight uses functions in std.algorithm to generate an iterable 
 range. The syntax is similar to Python's. See the last two 
 lines of the code above for an example.
print { i * 2 for i in 0 .. 5 where i ^ 2 less than 5 } # prints [0, 2, 4]
Jun 11 2015
prev sibling next sibling parent reply "Alex Parrill" <initrd.gz gmail.com> writes:
On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote:
 Hi,
 I've collected some of Python's features. It seems to me that 
 they are not in the D!

 Surely all this is in the D? :)
 http://rextester.com/CNQQR3333
import std.algorithm; import std.range; import std.stdio; import std.conv; void main() { enum n1 = 5; writeln(stdin.byLine .map!(line => line.split(" ").map!(x => to!int(x))) ); writeln("------"); enum n2 = 6; writeln(iota(n2) .map!(i => chain( repeat("2", i), only("1"), repeat("0", n2 - i - 1), only("\n") ).joiner(" ")).joiner ); } (I omitted evens/odds because it's been addressed and fizzbuzz because there's probably dozens of them floating around) You seem to be focusing on D's arrays only, but the real meat is in ranges, which are more generic. Also note that the above solution doesn't allocate any of the ranges in the heap; they're all on the stack (as opposed to Python, where you have to allocate lists or use iterators+itertools).
May 23 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 19:22:40 UTC, Alex Parrill wrote:
 import std.algorithm;
 import std.range;
 import std.stdio;
 import std.conv;

 void main() {
 	enum n1 = 5;
 	writeln(stdin.byLine
 		.map!(line => line.split(" ").map!(x => to!int(x)))
 	);
 	
 	writeln("------");
 	
 	enum n2 = 6;
 	writeln(iota(n2)
 		.map!(i => chain(
 			repeat("2", i),
 			only("1"),
 			repeat("0", n2 - i - 1),
 			only("\n")
 		).joiner(" ")).joiner
 	);
 }


 (I omitted evens/odds because it's been addressed and fizzbuzz 
 because there's probably dozens of them floating around)

 You seem to be focusing on D's arrays only, but the real meat 
 is in ranges, which are more generic. Also note that the above 
 solution doesn't allocate any of the ranges in the heap; 
 they're all on the stack (as opposed to Python, where you have 
 to allocate lists or use iterators+itertools).
This does not work! enum n1 = 5; writeln(stdin.byLine .map!(line => line.split(" ").map!(x => to!int(x))) ); ----- http://rextester.com/VGHZF81178 Even if you wanted to write this: enum n = 5; writeln(stdin.byLine .map!(line => line.split(" ").map!(x => to!int(x))).take(n) ); ----- http://rextester.com/COWE75794 That it's still not working. In my opinion, and should not work :)
 You seem to be focusing on D's arrays only, but the real meat 
 is in ranges, which are more generic.
Not sure what kind of meat you mean, but I really don't see much meat in ranges. Of course, this is 10 times better and easier to use than STL iterators C++. For me the most important feature D are mixins, which I, unfortunately, rarely use. I'm waiting for new features from D: for new designs, not simply the expansion of Phobos and fix bugs in DMD :) Should I wait for these new features? It seems to me that everyone is not enough to simply correct C++ — they all want a language in which many different sugar. In my opinion, sugar you can try to shake out of Lisp, if possible :)
 Also note that the above solution doesn't allocate any of the 
 ranges in the heap; they're all on the stack (as opposed to 
 Python, where you have to allocate lists or use 
 iterators+itertools).
And yet I do not like how the function byLine. It seems to me that we need analogues that will not work so damp as byLine. All right. Next time I will try to combine features that are not available in D, and of the faster languages: Erlang, Perl, Lisp, Nim, Rust, Scala etc. :)
May 23 2015
next sibling parent reply "cym13" <cpicard openmailbox.org> writes:
 Not sure what kind of meat you mean, but I really don't see 
 much meat in ranges. Of course, this is 10 times better and 
 easier to use than STL iterators C++. For me the most important 
 feature D are mixins, which I, unfortunately, rarely use. I'm 
 waiting for new features from D: for new designs, not simply 
 the expansion of Phobos and fix bugs in DMD :) Should I wait 
 for these new features? It seems to me that everyone is not 
 enough to simply correct C++ — they all want a language in 
 which many different sugar. In my opinion, sugar you can try to 
 shake out of Lisp, if possible :)
I think you are mistaken. The hard part about growing a programming language isn't adding features, it's finding the right core of features that are stable yet generic enough to answer everything in their own way. This is why C still is such a popular language, it hardly evolvevd since the begginning. It is also why Java in its time or Go know are popular among companies: they are boring, just boring. But they are stable. C++ wanted to address every problem, and look at it know. We have to develop a style, not more features. Python has its own style but every new feature (and they are rare) is very diligently examined. Most are refused. There is the python way. If python isn't the right tool for the job, then the best thing to do is finding another tool, not scotch an extension to the first one. I like python. I like D. I like other languages. Of course sometimes I'd like to have, say, UFCS in python or list comprehension in D. But D isn't the best language to do python, python is. And as there is a python way, there is a D way. This is not to say that we should dismiss any good concept of other languages, but those concepts fit in a philosophy, in an ecosystem.
May 23 2015
next sibling parent "cym13" <cpicard openmailbox.org> writes:
(just noticed a weird typo trend with know/now....     
%s/know/now/g)
May 23 2015
prev sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 20:44:37 UTC, cym13 wrote:
 Not sure what kind of meat you mean, but I really don't see 
 much meat in ranges. Of course, this is 10 times better and 
 easier to use than STL iterators C++. For me the most 
 important feature D are mixins, which I, unfortunately, rarely 
 use. I'm waiting for new features from D: for new designs, not 
 simply the expansion of Phobos and fix bugs in DMD :) Should I 
 wait for these new features? It seems to me that everyone is 
 not enough to simply correct C++ — they all want a language in 
 which many different sugar. In my opinion, sugar you can try 
 to shake out of Lisp, if possible :)
I think you are mistaken. The hard part about growing a programming language isn't adding features, it's finding the right core of features that are stable yet generic enough to answer everything in their own way. This is why C still is such a popular language, it hardly evolvevd since the begginning. It is also why Java in its time or Go know are popular among companies: they are boring, just boring. But they are stable. C++ wanted to address every problem, and look at it know. We have to develop a style, not more features. Python has its own style but every new feature (and they are rare) is very diligently examined. Most are refused. There is the python way. If python isn't the right tool for the job, then the best thing to do is finding another tool, not scotch an extension to the first one. I like python. I like D. I like other languages. Of course sometimes I'd like to have, say, UFCS in python or list comprehension in D. But D isn't the best language to do python, python is. And as there is a python way, there is a D way. This is not to say that we should dismiss any good concept of other languages, but those concepts fit in a philosophy, in an ecosystem.
You may find it nonsense, but Paul Graham says that each language has its own power. He believes that Lisp is the most powerful language, and programmers who write in other languages, he said Blub programmers. Learn more about "The Blub Paradox" can be read in the article Graham: http://www.paulgraham.com/avg.html What about increasing the number of features and stability, I agree. You may need more stability. Based on the theory of Graham, I should point out that the level of power python clearly lower than D :)
May 23 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Saturday, 23 May 2015 at 22:01:42 UTC, Dennis Ritchie wrote:
 You may find it nonsense, but Paul Graham says that each 
 language has its own power. He believes that Lisp is the most 
 powerful language, and programmers who write in other 
 languages, he said Blub programmers. Learn more about "The Blub 
 Paradox" can be read in the article Graham:
 http://www.paulgraham.com/avg.html
I'm a fan of lisp(Clojure being my favorite. Too bad it takes about a century just to load the runtime...), and yet I find it quite ironic that Paul Graham claims lisp to be the most powerful language right after claiming that programmers can't understand - and therefore disregard - the power of languages more powerful than the ones they use...
May 23 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Sunday, 24 May 2015 at 02:43:47 UTC, Idan Arye wrote:
 I'm a fan of lisp(Clojure being my favorite. Too bad it takes 
 about a century just to load the runtime...), and yet I find it 
 quite ironic that Paul Graham claims lisp to be the most 
 powerful language right after claiming that programmers can't 
 understand - and therefore disregard - the power of languages 
 more powerful than the ones they use...
This is not ironic, because I did neglect the power of Lisp, because not quite understand it fully :) The power of Lisp - his worst enemy. Strange Lisp syntax allows you to write powerful macros, which is unique in other languages, but many programmers do not understand Lisp syntax (and therefore may find it funny).
May 24 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 24 May 2015 at 11:07:19 UTC, Dennis Ritchie wrote:
 On Sunday, 24 May 2015 at 02:43:47 UTC, Idan Arye wrote:
 I'm a fan of lisp(Clojure being my favorite. Too bad it takes 
 about a century just to load the runtime...), and yet I find 
 it quite ironic that Paul Graham claims lisp to be the most 
 powerful language right after claiming that programmers can't 
 understand - and therefore disregard - the power of languages 
 more powerful than the ones they use...
This is not ironic, because I did neglect the power of Lisp, because not quite understand it fully :) The power of Lisp - his worst enemy. Strange Lisp syntax allows you to write powerful macros, which is unique in other languages, but many programmers do not understand Lisp syntax (and therefore may find it funny).
This IS ironic, because Paul Graham claims lisp to be the most powerful, but if he have ever encounter a more powerful language he couldn't accept it is more powerful than lisp due to the very same "Blub Paradox" he describes himself.
May 24 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Sunday, 24 May 2015 at 14:15:55 UTC, Idan Arye wrote:
 This IS ironic, because Paul Graham claims lisp to be the most 
 powerful, but if he have ever encounter a more powerful 
 language he couldn't accept it is more powerful than lisp due 
 to the very same "Blub Paradox" he describes himself.
Probably! But, in my opinion, it has not yet appeared stronger language Lisp, so "Blub Paradox" is not yet threatened with Graham :)
May 24 2015
parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Sunday, 24 May 2015 at 15:40:21 UTC, Dennis Ritchie wrote:
 On Sunday, 24 May 2015 at 14:15:55 UTC, Idan Arye wrote:
 This IS ironic, because Paul Graham claims lisp to be the most 
 powerful, but if he have ever encounter a more powerful 
 language he couldn't accept it is more powerful than lisp due 
 to the very same "Blub Paradox" he describes himself.
Probably! But, in my opinion, it has not yet appeared stronger language Lisp, so "Blub Paradox" is not yet threatened with Graham :)
But according to the Blub Paradox, your(Or mine. Or Paul Graham's) opinion on whether or not a stronger language than Lisp has appeared can not be trusted!
May 24 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Sunday, 24 May 2015 at 15:53:24 UTC, Idan Arye wrote:
 But according to the Blub Paradox, your(Or mine. Or Paul 
 Graham's) opinion on whether or not a stronger language than 
 Lisp has appeared can not be trusted!
Based on an article Graham about Blub Paradox, I can conclude that Blub Paradox programmers only acts on a certain age. It is possible that this occurs after the age of 25 years. And since I am under 25 years old, I think I can be trusted completely :) ----- Paul Graham: "This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough. ... But I don't expect to convince anyone (over 25) to go out and learn Lisp."
May 24 2015
prev sibling parent reply "anonymous" <anonymous example.com> writes:
On Saturday, 23 May 2015 at 20:25:18 UTC, Dennis Ritchie wrote:
 This does not work!

 enum n1 = 5;
 writeln(stdin.byLine
  	.map!(line => line.split(" ").map!(x => to!int(x)))
 );
 -----
 http://rextester.com/VGHZF81178
The code itself is ok. That site has broken newlines. You can see here that std.ascii.newline is different from what the site actually feeds to the program: <http://rextester.com/IIT33098>. You can work around that by passing the correct line terminator to byLine: <http://rextester.com/SOW95508>.
May 23 2015
parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 20:57:10 UTC, anonymous wrote:
 On Saturday, 23 May 2015 at 20:25:18 UTC, Dennis Ritchie wrote:
 This does not work!

 enum n1 = 5;
 writeln(stdin.byLine
 	.map!(line => line.split(" ").map!(x => to!int(x)))
 );
 -----
 http://rextester.com/VGHZF81178
The code itself is ok. That site has broken newlines. You can see here that std.ascii.newline is different from what the site actually feeds to the program: <http://rextester.com/IIT33098>. You can work around that by passing the correct line terminator to byLine: <http://rextester.com/SOW95508>.
Perhaps that's not the site, and in Windows. That's what gives me in CMD: 456 4 4 8 99 456 [[456, 4, 4, 8, 99, 456]13 546 std.conv.ConvException C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2013): Unexpected end of input when converting from type char[] to type int ---------------- 0x0040FD10 in pure safe int std.conv.parse!(int, char[]).parse(ref char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(2015) 0x00410C74 in pure safe int std.conv.toImpl!(int, char[]).toImpl(char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(1738) 0x0040FB92 in pure safe int std.conv.to!(int).to!(char[]).to(char[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(296) 0x0040FB7E in pure safe int acm.main().__lambda1!(char[]).__lambda1(char[]).__lambda2!(char[]).__lambda2(char[]) 0x00410DA7 in pure property safe int std.algorithm.iteration.__T9MapResultS553acm4mainFZ17__T9__lambda1TAaZ9__lambda1MFAaZ9__lambda2TAA Z.MapResult.front() at C:\D\dmd2\windows\bin\..\..\src\phobos\ std\algorithm\iteration.d(548) 0x004122D4 in D3std6format169__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration76A5C81813C007 D25AC82BE82F3551A66 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(240 9) 0x0041213F in D3std6format169__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration768E862681E57D 3E301EA954AAC63F894 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311 2) 0x004120AA in D3std6format171__T13formatElementTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationC8BE2524D6E8 27505208FE77A7AABE7 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(261 9) 0x00411B89 in D3std6format172__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration7956A969C910F8 7511562257DEEBA50CE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(241 0) 0x00411A27 in D3std6format172__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration793B5F1700DB98 7FAF5528C7A1A67E5DC at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311 2) 0x00411991 in D3std6format174__T13formatGenericTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationD44607637B1F E3931BFD9A68911D4FE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(345 1) 0x0041185C in D3std6format175__T14formattedWriteTS3std5stdio4File17LockingTextWriterTaTS3std9algorithm9iteratD57474F5CD8E DF85B780AE37888E8BE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(521 ) 0x00411320 in D3std5stdio4File129__T5writeTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TSD37A9C7F4304 5C668F40B8F70856955 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1200 ) 0x0041120A in D3std5stdio129__T7writelnTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TS3stC41BC71D1E9C BC78EB8446AC4667CCD at C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(2932 ) 0x0040203D in _Dmain at C:\Users\REiS\Documents\Projects\acm\acm\acm.d(21) 0x00427E06 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 0x00427DDB in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() 0x00427CF3 in _d_run_main 0x00427884 in main 0x0043E701 in mainCRTStartup 0x76BB7C04 in BaseThreadInitThunk 0x775AAD1F in RtlInitializeExceptionChain 0x775AACEA in RtlInitializeExceptionChain
May 23 2015
parent reply "anonymous" <anonymous example.com> writes:
On Saturday, 23 May 2015 at 21:08:19 UTC, Dennis Ritchie wrote:
 Perhaps that's not the site, and in Windows. That's what gives 
 me in CMD:

 456 4 4 8 99 456
 [[456, 4, 4, 8, 99, 456]13 546
 std.conv.ConvException C:\D\dmd2\windows\bin\..\..\src\phob
s\std\conv.d(2013): 
 Unexpected end of input when converting from type char[] to 
 type int
That's a different issue. Works fine for me in wine. You may be typing spaces before/after the numbers. That would result in empty items from `split`. You can `filter` empty items out, or you can use the unary version of `split` (not passing the delimiter) which, as per documentation, splits at whitespace and produces no empty words.
May 23 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 21:32:51 UTC, anonymous wrote:
 On Saturday, 23 May 2015 at 21:08:19 UTC, Dennis Ritchie wrote:
 Perhaps that's not the site, and in Windows. That's what gives 
 me in CMD:

 456 4 4 8 99 456
 [[456, 4, 4, 8, 99, 456]13 546
 std.conv.ConvException C:\D\dmd2\windows\bin\..\..\src\phob
s\std\conv.d(2013): 
 Unexpected end of input when converting from type char[] to 
 type int
That's a different issue. Works fine for me in wine. You may be typing spaces before/after the numbers.
Yes, I think I scored one space after 546.
May 23 2015
prev sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 19:22:40 UTC, Alex Parrill wrote:
 You seem to be focusing on D's arrays only, but the real meat 
 is in ranges, which are more generic. Also note that the above 
 solution doesn't allocate any of the ranges in the heap; 
 they're all on the stack (as opposed to Python, where you have 
 to allocate lists or use iterators+itertools).
Also present ranges from the time of D1 and Tango, because there is nothing surprising about them. Need new features!
May 23 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 22 May 2015 at 00:23:30 UTC, Dennis Ritchie wrote:
 Hi,
 I've collected some of Python's features. It seems to me that 
 they are not in the D!

 Surely all this is in the D? :)
 http://rextester.com/CNQQR3333
After another review, I think some of these conversions to D could be expressed much easier if the built-in slice had multidimensional slicing It was added in 2.066* but I don't think there's any plans to add support for it to slices. * - you can see an example at http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
May 23 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Saturday, 23 May 2015 at 21:09:45 UTC, weaselcat wrote:
 After another review, I think some of these conversions to D 
 could be expressed much easier if the built-in slice had 
 multidimensional slicing

 It was added in 2.066* but I don't think there's any plans to 
 add support for it to slices.
Actually not a bad idea: add to Phobos module std.multiarray.
 * - you can see an example at 
 http://denis-sh.bitbucket.org/unstandard/unstd.multidimarray.html
Embed multidimensional slices directly into the language is not very good, but in a separate module, why not...
May 23 2015