digitalmars.D.learn - Python's features, which requires D
- Dennis Ritchie (5/5) May 21 2015 Hi,
- weaselcat (6/13) May 21 2015 D doesn't have list comprehensions, so it's difficult to directly
- Dennis Ritchie (18/22) May 21 2015 I can not imagine how difficult it is to implement it in D, but
- weaselcat (3/26) May 21 2015 writeln(stride(a[1..$], 4));
- Dennis Ritchie (5/23) May 21 2015 Yes, this is what you need (I often forget that the functions can
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (38/43) May 21 2015 Here is my attempt:
- Dennis Ritchie (35/76) May 22 2015 Yes, it looks pretty good :) Thanks. But...
- Dennis Ritchie (2/2) May 22 2015 By the way, Python has deepDup :)
- Kagamin (3/10) May 23 2015 Well, list comprehension is built into language in python (and
- Dennis Ritchie (7/9) May 23 2015 Well, what's to keep D more functions to work with slist and
- Russel Winder via Digitalmars-d-learn (18/29) May 23 2015 The issue is performance, especially for random access to the sequence.
- Dennis Ritchie (6/23) Jun 11 2015 Yes, but D is also possible to create a strong inclusion of list
- Alex Parrill (30/35) May 23 2015 import std.algorithm;
- Dennis Ritchie (31/66) May 23 2015 This does not work!
- cym13 (26/36) May 23 2015 I think you are mistaken. The hard part about growing a
- cym13 (2/2) May 23 2015 (just noticed a weird typo trend with know/now....
- Dennis Ritchie (11/53) May 23 2015 You may find it nonsense, but Paul Graham says that each language
- Idan Arye (7/13) May 23 2015 I'm a fan of lisp(Clojure being my favorite. Too bad it takes
- Dennis Ritchie (6/12) May 24 2015 This is not ironic, because I did neglect the power of Lisp,
- Idan Arye (5/18) May 24 2015 This IS ironic, because Paul Graham claims lisp to be the most
- Dennis Ritchie (4/8) May 24 2015 Probably! But, in my opinion, it has not yet appeared stronger
- Idan Arye (4/12) May 24 2015 But according to the Blub Paradox, your(Or mine. Or Paul
- Dennis Ritchie (14/17) May 24 2015 Based on an article Graham about Blub Paradox, I can conclude
- anonymous (7/14) May 23 2015 The code itself is ok.
- Dennis Ritchie (72/87) May 23 2015 Perhaps that's not the site, and in Windows. That's what gives me
- anonymous (7/14) May 23 2015 That's a different issue. Works fine for me in wine.
- Dennis Ritchie (2/13) May 23 2015 Yes, I think I scored one space after 546.
- Dennis Ritchie (3/8) May 23 2015 Also present ranges from the time of D1 and Tango, because there
- weaselcat (8/13) May 23 2015 After another review, I think some of these conversions to D
- Dennis Ritchie (4/11) May 23 2015 Embed multidimensional slices directly into the language is not
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
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/CNQQR3333D 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.strideP.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
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.strideimport 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
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:writeln(stride(a[1..$], 2));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.strideimport 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 Dauto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]; // [2, 6, 10] #print(x[1::4]) #no equivalent in Dwriteln(stride(a[1..$], 4));}
May 21 2015
"Dennis Ritchie" <dennis.ritchie mail.ru> 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: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 :)writeln(stride(a[1..$], 2));off the top of my head, the last one can easily be done with std.range.strideimport 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 Dauto x = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]; // [2, 6, 10] #print(x[1::4]) #no equivalent in Dwriteln(stride(a[1..$], 4));}
May 21 2015
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/CNQQR3333Here 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
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 } } AliYes, 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
By the way, Python has deepDup :) http://rextester.com/KBFA82886
May 22 2015
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:Well, list comprehension is built into language in python (and not in D), such level of support is definitely more streamlined.auto a = stdin .byLine .map!(l => l.splitter.map!(to!int).array) .take(n);
May 23 2015
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
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: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_winderWell, 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?
May 23 2015
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:Yes, but D is also possible to create a strong inclusion of list comprehensions. Here's the proof: https://github.com/pplantinga/delightFor 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:Well, list comprehension is built into language in python (and not in D), such level of support is definitely more streamlined.auto a = stdin .byLine .map!(l => l.splitter.map!(to!int).array) .take(n);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 }
Jun 11 2015
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/CNQQR3333import 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
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
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
(just noticed a weird typo trend with know/now.... %s/know/now/g)
May 23 2015
On Saturday, 23 May 2015 at 20:44:37 UTC, cym13 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 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 :)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
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.htmlI'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
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
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: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.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
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
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: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!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
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
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
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: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 RtlInitializeExceptionChainThis does not work! enum n1 = 5; writeln(stdin.byLine .map!(line => line.split(" ").map!(x => to!int(x))) ); ----- http://rextester.com/VGHZF81178The 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
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 intThat'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
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:Yes, I think I scored one space after 546.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 intThat's a different issue. Works fine for me in wine. You may be typing spaces before/after the numbers.
May 23 2015
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
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/CNQQR3333After 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
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.htmlEmbed multidimensional slices directly into the language is not very good, but in a separate module, why not...
May 23 2015