Re: Python's features, which requires D
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...
Re: Python's features, which requires D
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 :)
Re: Python's features, which requires D
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\phobos\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.
Re: indie game contests
Danny that is great cause I am not capable of more than coder art :) How can i reach you ? On Saturday, 23 May 2015 at 05:17:13 UTC, Danni Coy wrote: Got very close to a year or so ago. Probably something I would be much more capable of doing now. The only downside is that I enjoy doing asset creation more. On Sat, May 23, 2015 at 7:34 AM, Vlad Levenfeld via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 22 May 2015 at 17:00:06 UTC, Namespace wrote: On Friday, 22 May 2015 at 16:24:18 UTC, Vlad Levenfeld wrote: I know there's a strong gamedev presence here, so I'm wondering if anyone's submitted any games written in D to any of these contests? What was your experience like? I'd like to enter one, and wonder if anyone would be interested in a collaboration. Outside of programming, I used to do low-poly 3d art (just as a hobby in my secondary school days), so I can potentially contribute visuals, and I'm pretty comfortable with openGL. From time to time I'm working on two smaller games, Angry Snowball (https://github.com/Dgame/AngrySnowball) and Quinn Quadrat. I would like to present them, once they are ready, at one game a month, but in the last few week I was busy with my studies. I would like to collaborate with you, but you should know that my pixel art is not that good. ;) Let's do it! Maybe we can get some diablo style prerendered sprites going :) I'm at vlevenfeld (at) gmail and github.com/evenex
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617 --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- A neat advantage over C is that we can define the .init value so we don't need such an initializer. In fact, core.posix.pthread defines PTHREAD_MUTEX_INITIALIZER as pthread_mutex_t.init. However, there is an issue, because core/sys/posix/sys/types.d is not included in the build. So if I define a new init, it won't be found (tried it). I also tried updating the PTHREAD_MUTEX_INITIALIZER in pthread.d, and that also is not found. So we need some Makefile updates in order to fix this. And I'm not sure we want to do that. Thoughts? --
[Issue 14616] ddoc shows std.socket.UnixAddress as abstract
https://issues.dlang.org/show_bug.cgi?id=14616 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- PR has been pulled. --
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
--- Comment #4 from Andrei Alexandrescu and...@erdani.com ---
Thanks for all this, folks! Steve, can't you just insert the proper defaults
where the struct is defined? I.e. we have in src/core/sys/posix/sys/types.d the
following definition at line 594:
struct pthread_mutex_t
{
c_long __sig;
byte[__PTHREAD_MUTEX_SIZE__]__opaque;
}
Changing it to the following makes at least my tests pass:
struct pthread_mutex_t
{
c_long __sig = 0x32AAABA7;
byte[__PTHREAD_MUTEX_SIZE__]__opaque;
}
--
[Issue 11098] template instance x cannot use local y as parameter to non-global template z
https://issues.dlang.org/show_bug.cgi?id=11098
--- Comment #2 from r...@rcorre.net ---
This is still around in DMD2.067.
The UFCS trick is a nice work-around on the callee side.
You can also work around it on the caller side with:
struct S {
void f(alias F)() { }
}
void main() {
static int fun(int i) { return i; }
S.init.f!(fun);
}
Both are less than ideal though.
--
[Issue 14618] New: can break immutable with inout and a delegate
https://issues.dlang.org/show_bug.cgi?id=14618
Issue ID: 14618
Summary: can break immutable with inout and a delegate
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
struct S
{
immutable(int)* p;
}
inout(int)* f(inout S s)
{
inout(int)* result;
auto dg = (inout(int)* p) {result = p;};
dg(s.p);
return result;
}
void main()
{
immutable int x = 42;
immutable int* p = x;
assert(*p == 42); /* passes */
scope(exit) assert(*p == 42); /* fails */
int* m = f(S(p)); /* uh-oh */
*m = 13; /* writing over immutable *p */
}
--
Re: Python's features, which requires D
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. :)
Re: Python's features, which requires D
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!
Re: Python's features, which requires 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.
Re: Python's features, which requires D
(just noticed a weird typo trend with know/now %s/know/now/g)
Re: Python's features, which requires D
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.
Re: Python's features, which requires D
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__lambda2TAAaZ.MapResult.front() at C:\D\dmd2\windows\bin\..\..\src\phobos\ std\algorithm\iteration.d(548) 0x004122D4 in D3std6format169__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration76A5C81813C007BD25AC82BE82F3551A66 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(240 9) 0x0041213F in D3std6format169__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration768E862681E57D43E301EA954AAC63F894 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311 2) 0x004120AA in D3std6format171__T13formatElementTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationC8BE2524D6E8B27505208FE77A7AABE7 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(261 9) 0x00411B89 in D3std6format172__T11formatRangeTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration7956A969C910F877511562257DEEBA50CE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(241 0) 0x00411A27 in D3std6format172__T11formatValueTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iteration793B5F1700DB9877FAF5528C7A1A67E5DC at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(311 2) 0x00411991 in D3std6format174__T13formatGenericTS3std5stdio4File17LockingTextWriterTS3std9algorithm9iterationD44607637B1FEE3931BFD9A68911D4FE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(345 1) 0x0041185C in D3std6format175__T14formattedWriteTS3std5stdio4File17LockingTextWriterTaTS3std9algorithm9iteratD57474F5CD8E0DF85B780AE37888E8BE at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(521 ) 0x00411320 in D3std5stdio4File129__T5writeTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TSD37A9C7F430415C668F40B8F70856955 at C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1200 ) 0x0041120A in D3std5stdio129__T7writelnTS3std9algorithm9iteration79__T9MapResultS213acm4mainFZ9__lambda1TS3stC41BC71D1E9C2BC78EB8446AC4667CCD 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
Re: Python's features, which requires D
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/CNQQR 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
Re: Python's features, which requires D
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\phobos\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.
[Issue 14610] [REG2.067] 'null this' assertion missing in 2.067
https://issues.dlang.org/show_bug.cgi?id=14610 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/4678 --
Re: Python's features, which requires D
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...
How to append range to array?
int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); Hopefully in one GC allocation (assuming we know the range's length). I tried std.range.primitives.put but its behavior seems a little mysterious: This compiles but asserts at runtime: int[] arr = [1, 2, 3]; arr.put(iota(4, 10)); And this is even weirder, can you guess what it will print? int[] arr = [1, 2, 3]; arr.put(4); writeln(arr);
Re: What happens when you launch a D application ?
FYI, I didn't realize this (but just figured it out), C main *used* to be in druntime, but it's now generated by the compiler. See here: https://github.com/D-Programming-Language/dmd/blob/master/src/mars.c#L236 True. But it is compiler-dependent. GDC actually still defines C main in the runtime: https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/__entrypoint.di#L60 Mike
Re: indie game contests
On Friday, 22 May 2015 at 21:34:27 UTC, Vlad Levenfeld wrote: On Friday, 22 May 2015 at 17:00:06 UTC, Namespace wrote: On Friday, 22 May 2015 at 16:24:18 UTC, Vlad Levenfeld wrote: I know there's a strong gamedev presence here, so I'm wondering if anyone's submitted any games written in D to any of these contests? What was your experience like? I'd like to enter one, and wonder if anyone would be interested in a collaboration. Outside of programming, I used to do low-poly 3d art (just as a hobby in my secondary school days), so I can potentially contribute visuals, and I'm pretty comfortable with openGL. From time to time I'm working on two smaller games, Angry Snowball (https://github.com/Dgame/AngrySnowball) and Quinn Quadrat. I would like to present them, once they are ready, at one game a month, but in the last few week I was busy with my studies. I would like to collaborate with you, but you should know that my pixel art is not that good. ;) Let's do it! Maybe we can get some diablo style prerendered sprites going :) I'm at vlevenfeld (at) gmail and github.com/evenex Sounds good! I'll write you a mail during the day.
Re: Necessity of D Library (and/or Core Library)
On 23/05/2015 6:35 p.m., Anthony Monterrosa wrote: Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? I have become very interested in how programming languages do their magic; how they interact with the computer itself, and their inner mechanics. This eventually led me to resources that said the line between a language and its library differs between languages, and I was wondering where D stood on that line. Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. P.S. I'm only a freshman computer science student, so if some of this should be basic, I simply don't know it yet. Thanks in advance! D can function without any form of standard library or runtime on e.g. embedded devices. But it will be next to useless without druntime. Druntime atleast in master requires libc. Libc defines things such as malloc and free. As well as other required functions to interact with the OS with. Although OS libs such as user32 on windows is used. It also provides the GC. But phobos itself is not required in any sense for D to work. It's just library code that comes with it.
Re: How to append range to array?
On Saturday, May 23, 2015 07:03:33 Vladimir Panteleev via Digitalmars-d-learn wrote: int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); Hopefully in one GC allocation (assuming we know the range's length). I tried std.range.primitives.put but its behavior seems a little mysterious: This compiles but asserts at runtime: int[] arr = [1, 2, 3]; arr.put(iota(4, 10)); And this is even weirder, can you guess what it will print? int[] arr = [1, 2, 3]; arr.put(4); writeln(arr); For better or worse, put does not append to arrays. It fills them. If you want to append using put, then using std.array.Appender. - Jonathan M Davis
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Friday, 22 May 2015 at 21:03:43 UTC, Jonathan M Davis wrote: On Friday, 22 May 2015 at 20:21:59 UTC, Kagamin wrote: Hmm, now that I look at it, the declaration of bigEndianToNative is weird: http://dpaste.dzfl.pl/6fad7c9ef22d What's weird about it? Why it has a separate n parameter? It makes no sense. If it was like in the paste, it would give proper error message.
Necessity of D Library (and/or Core Library)
Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? I have become very interested in how programming languages do their magic; how they interact with the computer itself, and their inner mechanics. This eventually led me to resources that said the line between a language and its library differs between languages, and I was wondering where D stood on that line. Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. P.S. I'm only a freshman computer science student, so if some of this should be basic, I simply don't know it yet. Thanks in advance!
[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD
https://issues.dlang.org/show_bug.cgi?id=14571 --- Comment #18 from Manu turkey...@gmail.com --- (In reply to Walter Bright from comment #6) I'll fix this, but you should know that this necessarily creates large sections in the executable file of repeated data. For such large arrays, it is better to allocate and initialize them on program startup. I reported it because it was a bug, and I agree it's not excellent practise. That said though, Vladimir has already presented my thoughts; it's perfectly valid code, people do it, code like this exists. In my case, I am porting C++ code, and it's quite a lot of code... it is difficult to refactor and port at the same time. Regarding .init, this is something I never really thought about too much, but I'm now really concerned. I have been concerned by classinfo's in the past, but somehow init slipped under my radar. I think a few things need to be considered and/or possible. 1. How do I disable the existence of 'init' for a type? It's conceivable that I want to produce an uninitialised (and uninitialisable) type, like these ones I have here. 2. Any type with a static array naturally has an unreasonably large .init value; what optimisations are possible with relation to init? Can they be alocated+synthesised at init (*cough*) time, rather than built into the exe? An array is a series of repeated elements, so storing that full array in the binary is not only wasteful, but can only lead to disaster when people put a static array as a member of a type, and the length is large, or perhaps is fed from a 3rd party who doesn't have this specific consideration in mind (nor should they). 3. Can D effectively link-strip .init when it is un-referenced? How can we make this possible if there is something preventing it? I'd love to spend some time working towards D binaries being the same predictable size as C/C++ binaries. For some reason, despite my efforts, I always seem to end up with D binaries that are easily 10 times the size of their counterpart C binary. Infact, I constantly find myself in the surprising situation where I create a D interface for a C lib, which simply declares extern(C)'s along with minimal D code for adaptation, no actual functional D code in sight, and the .lib it produces is significantly larger than the entire C lib that it represents. I have never taken the time to explore the problem, I suspect it's just classinfo's and init values... are there other known bloat inducing problems? The way globals work on modern CPUs is you are not saving any execution time by using static data. Large static arrays is an artifact of FORTRAN. This isn't about execution time, it's about perfectly valid code that looks completely benign causing an unexpected explosion to your binary. Not all programmers are aware or conscious of this sort of thing. It shouldn't be so simple for an unexpecting (junior?) programmer to make a mess like this, and likely not understand what they've done, or that they've even done it at all. --
Re: How to append range to array?
std.range.chain? Atila On Saturday, 23 May 2015 at 07:03:35 UTC, Vladimir Panteleev wrote: int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); Hopefully in one GC allocation (assuming we know the range's length). I tried std.range.primitives.put but its behavior seems a little mysterious: This compiles but asserts at runtime: int[] arr = [1, 2, 3]; arr.put(iota(4, 10)); And this is even weirder, can you guess what it will print? int[] arr = [1, 2, 3]; arr.put(4); writeln(arr);
Re: What happens when you launch a D application ?
On 5/22/2015 10:26 PM, Suliman wrote: Really hard to understand... So what what would call at first ? extern(C) int main() or int _Dmain() Your D programs have multiple layers. There is the C runtime, DRuntime, and your program code. The C runtime is at the bottom. When the program launches, it gets control first. When it has done its work, it looks for a main function and calls it. Normally, in a C program, that would be the main function that you implement. But in D, it is a function implemented by DRuntime. The DRuntime main, because it is called by C, must be declared as extern(C) in order for the C runtime to recognize it. When it is called by the C runtime, then DRuntime does some housekeeping work (calling module constructors, intializing the garbage collecter, and so on). When it is done with that, it then calls the main function that you implemented in your program. The exception to this is when a program is compiled on Windows with WinMain enabled. In this case, the C main is not the entry point, but WinMain is instead. DRuntime does not implement WinMain, so when compiling a D program like this, we have to call initialize DRuntime manually.
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #1 from Martin Nowak c...@dawg.eu ---
According to the headers, the initializer should be {0x32AAABA7}.
http://www.opensource.apple.com/source/Libc/Libc-167/pthreads.subproj/pthread.h
--
[Issue 14611] socket.localAddress fails on Unix sockets with longer path ( 13 characters)
https://issues.dlang.org/show_bug.cgi?id=14611 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |FIXED --
[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD
https://issues.dlang.org/show_bug.cgi?id=14571 --- Comment #19 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Manu from comment #18) 1. How do I disable the existence of 'init' for a type? I think that if you make sure that all of the initial values are zero bytes, the compiler won't generate a .init block. Instead, the TypeInfo will have a null .init pointer, and the runtime will use that as a clue to simply do a memset instead of copying over the .init data when allocating new types. You might be able to also use this to ensure that your complex types aren't accidentally creating .init blocks. 2. Any type with a static array naturally has an unreasonably large .init value; what optimisations are possible with relation to init? Can they be alocated+synthesised at init (*cough*) time, rather than built into the exe? Not at the moment, AFAIK. 3. Can D effectively link-strip .init when it is un-referenced? How can we make this possible if there is something preventing it? Each .init would need to be in its own section to allow linker garbage collection. DMD doesn't seem to do this at the moment, though (at least not on Win32/Win64). Whether to put things in individual sections is usually a trade-off between link time and resulting executable size. It would be great if DMD at least gave the user some control over this. gcc has e.g. -ffunction-sections and -fdata-sections. I'd love to spend some time working towards D binaries being the same predictable size as C/C++ binaries. For some reason, despite my efforts, I always seem to end up with D binaries that are easily 10 times the size of their counterpart C binary. I agree, bloated executables are not nice. This becomes a real problem with proprietary/closed-source applications, since then the compiler is pulling in code and data that is never actually used, and which should not be present in the published executable. I have never taken the time to explore the problem, I suspect it's just classinfo's and init values... are there other known bloat inducing problems? Yes. - Static constructors pull in everything they reference. - Object.factory requires that all classes that the compiler sees must be instantiatable, which means pulling in their vtables, invariants, virtual methods, and all their dependencies. - Many things which could be emitted in separate sections are put in one section. As a result, anything that's referenced within that section pulls in everything else from it, and all their dependencies. - There are probably other problems. This is generally one of the more neglected aspects of D and the current implementations. People working on embedded D stuff are constantly running into the above problems as well. --
Re: Serialization library with support for circular references?
On Saturday, 10 November 2012 at 22:09:07 UTC, Andrej Mitrovic wrote: On 11/10/12, nixda b...@or.de wrote: You can try vibe.d bson serialization. http://vibed.org/api/vibe.data.bson/serializeToBson It doesn't handle them either. Anyway I've implemented it for msgpack (took a whole of 30 minutes, it's a great and readable codebase), I just have to write some more extensive unittests to make sure everything works ok.
Re: Serialization library with support for circular references?
On Saturday, 23 May 2015 at 08:01:28 UTC, timotheecour wrote: On Saturday, 10 November 2012 at 22:09:07 UTC, Andrej Mitrovic wrote: On 11/10/12, nixda b...@or.de wrote: You can try vibe.d bson serialization. http://vibed.org/api/vibe.data.bson/serializeToBson It doesn't handle them either. Anyway I've implemented it for msgpack (took a whole of 30 minutes, it's a great and readable codebase), I just have to write some more extensive unittests to make sure everything works ok. Do you have any pointers to it? This issue tracks this feature request: https://github.com/msgpack/msgpack-d/issues/7 Thanks!
Re: How to append range to array?
On Saturday, 23 May 2015 at 07:03:35 UTC, Vladimir Panteleev wrote: int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); import std.array : array; arr ~ r.array;
Re: How to append range to array?
On Saturday, 23 May 2015 at 08:35:45 UTC, weaselcat wrote: On Saturday, 23 May 2015 at 07:03:35 UTC, Vladimir Panteleev wrote: int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); import std.array : array; arr ~ r.array; woops, meant ~= but this is probably fairly inefficient. Working with ranges and arrays at the same time feels really badly designed.
Re: Necessity of D Library (and/or Core Library)
On Saturday, 23 May 2015 at 06:35:50 UTC, Anthony Monterrosa wrote: Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? Phobos is not required completely. D runtime can be a couple of lines not counting object.d. If you want all asserts, string switch and bounds checking (which I nice to have) and nice error reporting, it can grow to 100 lines or so. Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. Phobos works on top of C stdio.
Re: What happens when you launch a D application ?
Could you explain what mean C main inside the runtime. I
thought that is only one main is possible. And why it's named
*С* main D is not C-translated language.
Same question is about _Dmain -- what is it?
If I will call this() before main? What it will be? Will it run
before main?
This is a great question; one which I've tried to answer through
my own investigation. So, I'll add what I've learned.
Every D program is started as if it were a C program. This is
easiest to see with the GNU toolchain. Try to compile a blank
test.c file
gcc test.c
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crt1.o:
In function `_start':
(.text+0x20): undefined reference to `main'
Now try to compile a blank test.d file
gdc test.d
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crt1.o:
In function `_start':
(.text+0x20): undefined reference to `main'
{...and a bunch of other errors}
So, you can see that both C and D programs need to define an
unmangled `main` symbol. We call this symbol C main. DMD and
LDC seem to add C main automatically, while GDC defines it in
the D runtime:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/__entrypoint.di#L60
C main then calls `_d_run_main`, and passes in a pointer to
`_DMain`. `_DMain` is actually a phony alias to your D program's
`void main()`, so you won't find it implemented anywhere. Your D
program's `void main()` is D-mangled, so it is distinguishable
from C main. We call this symbol D main
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/__entrypoint.di#L62
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/rt/dmain2.d#L235
_d_run_main calls `rt_init()` which does all of the D runtime
initialization...
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/rt/dmain2.d#L410
... and then calls `_DMain` (but it was passed into `_d_run_main
as` `mainFunc`:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/rt/dmain2.d#L411
So in summary it looks like this (At least in Linux):
* Operating system calls `_start` which is defined in the C
Runtime (crt1.o).
* _start calls the unmangled `main` which we will call C main.
This function is automatically added by DMD and LDC, but defined
in GDC's D runtime.
* C main calls `_d_run_main` passing in a pointer to the symbol
`_DMain`. `_DMain` is actually your D program's `void main()`
function. It is D-mangled, so the linker can distinguish it from
C main
* `_d_run_main` then calls `rt_init()` to initialize the runtime,
and then calls `_DMain`.
I believe the module constructors and the static constructors are
called in D runtime's rt_init function:
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/rt/dmain2.d#L152
I'm still studying how exactly that works, though. I think they
are linked into ModuleInfo.
I hope this is helpful. If you want to know more about how the
operating system calls C main (at least in a Linux environment),
see these links:
http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
https://gcc.gnu.org/onlinedocs/gccint/Initialization.html
Mike
Re: Uphill
On Fri, 22 May 2015 16:00:28 +, Jonathan M Davis wrote: Joking aside, we do seem to frequently have the problem that what we have is good enough that folks expect it to be perfect and thus start complaining about how we don't do something well enough when we actually do it better than most anyone else. D certainly isn't perfect - and we _do_ have areas to improve upon - but we what we do have is pretty darn awesome. yes, this is the case. being good for D is took as granted, and being imperfect seen as devs lazyness. ;-) signature.asc Description: PGP signature
Re: Necessity of D Library (and/or Core Library)
On Saturday, 23 May 2015 at 12:47:12 UTC, Mike wrote: You can disable linking phobos and the D Runtime with the -nophoboslib compiler flag. I'm not sure if DMD or LDC offer a similar compiler option. -defaultlib= You can use that to change to linking to a .so for example but leaving it blank means no phobos/druntime at all.
Re: Python's features, which requires D
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?
Re: Necessity of D Library (and/or Core Library)
On Saturday, 23 May 2015 at 06:35:50 UTC, Anthony Monterrosa wrote: Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? I have become very interested in how programming languages do their magic; how they interact with the computer itself, and their inner mechanics. This eventually led me to resources that said the line between a language and its library differs between languages, and I was wondering where D stood on that line. Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. P.S. I'm only a freshman computer science student, so if some of this should be basic, I simply don't know it yet. Thanks in advance! I have some bare metal code that works without Druntime. The compiler injects code that references some druntime components, which causes the linker to barf if they're not defined somewhere. You can simply define them as global void* vars like so: --- module kernel.kmain; // So we compile without druntime. extern(C) __gshared void* _d_dso_registry; extern(C) __gshared void* _Dmodule_ref; extern(C) __gshared void* _d_arraybounds; extern(C) __gshared void* _d_assert; extern(C) __gshared void* _d_unittest; // rest of code here --- This was back in DMD 2.065 so things may have changed between then and now. bye, lobo
Re: What happens when you launch a D application ?
Every D program is started as if it were a C program. Why is so necessary? What about C++ and other languages? Does they have more then one main? Why it's more than one main is needed? Why D apps can't start with single main?
Re: Python's features, which requires D
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.
Re: What happens when you launch a D application ?
On 23/05/2015 10:57 p.m., Suliman wrote: Every D program is started as if it were a C program. Why is so necessary? What about C++ and other languages? Does they have more then one main? Depends on the implementation. I believe Visual C++ does. But it is used like D's to allow it to initialize the runtime. https://msdn.microsoft.com/en-us/library/bb918180.aspx Why it's more than one main is needed? Why D apps can't start with single main? Oh but they can. But I guess you'll want things like the GC, module constructors ext oh and some globally initialized memory.
Re: What happens when you launch a D application ?
On Saturday, 23 May 2015 at 10:57:22 UTC, Suliman wrote:
Every D program is started as if it were a C program.
Why is so necessary?
It's not actually necessary. You could implement the `_start`
function in your D program. Here's a D program without any C
runtime, D runtime, or main.
long __d_sys_write(long arg1, in void* arg2, long arg3)
{
ulong result;
asm
{
syscall
: =a result
: a 1,
D arg1,
S arg2,
m arg2,
d arg3
: memory, cc, rcx, r11;
}
return result;
}
extern(C) void __d_sys_exit(long arg1)
{
asm
{
syscall
:
: a 60,
D arg1,
: memory, cc, rcx, r11;
}
}
extern(C) void _start()
{
// you could put this in a main function and
// call main() from here.
auto text = Hello, World!\n;
__d_sys_write(1, text.ptr, text.length);
__d_sys_exit(0);
}
Compile with:
gdc -fno-emit-moduleinfo -nostartfiles test.d
This produces a 733 byte Hello World binary.
-fno-emit-moduleinfo will prevent the compiler from generating a
lot of auxiliary code that's not needed for this program.
-nostartfiles will prevent the C runtime from being linked in.
This is a nice little experiment, but once you start trying to
use structs, classes, arrays, exceptions, or any other feature of
D, you will need more and more of the D runtime.
There may also be some things generated by GDC that get called
implicitly by the C runtime's initialization procedures (e.g.
_init, _fini, etc..) but I'm not that knowledgeable about the
compiler's codegen.
What about C++ and other languages? Does they have more then
one main?
C++ is a superset of C, so in my experience, C++ only needs C
main. However, C++ has static constructors that get called by
some of the initialization procedures in the C runtime before
actually calling main. I wonder if C++ free functions mangled in
C++...I'm not sure.
Why it's more than one main is needed? Why D apps can't start
with single main?
I don't think the current implementation is necessary. There are
probably many different ways to implement D program
initialization. I don't see why D runtime couldn't just
implement _start, omit the C runtime altogether, and do
everything in D, but I trust the compiler implementers have their
reasons.
If you're interested in digging deeper, you'll probably have to
ask questions on D.GNU to get the attention of the compiler
implementers.
Mike
Re: Necessity of D Library (and/or Core Library)
On Saturday, 23 May 2015 at 06:35:50 UTC, Anthony Monterrosa wrote: Does D require the standard library to function? Or to be more direct, does D as a language need its library, or core library, to function correctly? There are two main libraries in D: The D Runtime, and the standard library (a.k.a. Phobos) By default, D links in Phobos and the D Runtime. With the GDC compiler, the two are actually compiled as a single binary. You can disable linking phobos and the D Runtime with the -nophoboslib compiler flag. I'm not sure if DMD or LDC offer a similar compiler option. You could, however, compile to object files and then link manually with the system linker to avoid linking in phobos and the D Runtime. If you don't explicitly import anything, then you won't need phobos, but you may need the D Runtime depending on which features of the language you use. However, if you stick to a C-like subset of D, you need very little of the D Runtime (50~100 lines of code) Note: since, I'm already here, does anyone know how D manipulates/uses standard streams to make its write/read functions as well? I can't find any resources telling me a non-abstracted way of this being completed. It is my understanding that D links in the C standard library and leverages the functionality there for standard streams. Mike
Re: Uphill
On Fri, 2015-05-22 at 16:00 +, Jonathan M Davis via Digitalmars-d wrote: On Friday, 22 May 2015 at 14:11:49 UTC, H. S. Teoh wrote: +1, finally, something other than the usual bickering on the forum. ;-) LOL. Don't worry. I'm sure that someone will come along and start griping about something soon. I think much of the problem is pure angst. And bad email list etiquette. In other language mailing lists I am, on a gripe thread lasts about five to 10 emails and then fades away. With this list it generally gets to about 300 or more. Usually covering, over time, seven or 20 different topics completely unrelated to the original posting and retained subject line. Anyway now D has Rust to content with, as well as Go and C++. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Dual conditions in D and Python
On 5/21/15 2:35 PM, Ali Çehreli wrote:
On 05/21/2015 12:44 PM, Meta wrote:
All we need is user-defined opIs and then we're really cooking with gas.
if (5 is between(4, 6))
{
//...
}
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
In fact we'll be there with 2.068:
http://dlang.org/phobos-prerelease/std_algorithm_sorting.html#.ordered
if (ordered(4, 5, 6)) { ... }
if (strictlyOrdered(4, 5, 6)) { ... }
Andrei
Re: Boy, std.bitmanip.bigEndianToNative is annoying to use
On Sat, May 23, 2015 at 09:54:35AM +, Kagamin via Digitalmars-d wrote: On Friday, 22 May 2015 at 21:03:43 UTC, Jonathan M Davis wrote: On Friday, 22 May 2015 at 20:21:59 UTC, Kagamin wrote: Hmm, now that I look at it, the declaration of bigEndianToNative is weird: http://dpaste.dzfl.pl/6fad7c9ef22d What's weird about it? Why it has a separate n parameter? It makes no sense. If it was like in the paste, it would give proper error message. Submit a PR? T -- MAS = Mana Ada Sistem?
Re: shared libs for OSX
On 2015-05-22 18:12, Martin Nowak wrote: One could also make emulated TLS work with shared libraries. Yeah, but then you would need to implement something similar to the TLS code already present in the dynamic linker in druntime. Both alternatives would require changes to both the compiler and runtime. Hopefully implementing native TLS in the compiler would not be any more difficult than adding support for shared libraries to the emulated TLS. -- /Jacob Carlborg
Re: Dual conditions in D and Python
On Sat, 2015-05-23 at 10:17 -0700, Andrei Alexandrescu via Digitalmars-d-learn
wrote:
[…]
if (ordered(4, 5, 6)) { ... }
if (strictlyOrdered(4, 5, 6)) { ... }
So the latter means the integers have to lashed as well as ordered? ;
-)
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com ---
According to testing:
Stevens-MacBook-Pro:testd steves$ cat pthreadm.cpp
#include pthread.h
#include stdio.h
int main(int argc, char *argv[])
{
pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER;
unsigned char *b = (unsigned char *)x;
unsigned char *e = (unsigned char *)((x) + 1);
while(b != e)
printf(%02x , (int)*b++);
printf(\n);
}
Stevens-MacBook-Pro:testd steves$ ./pthreadm
a7 ab aa 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
So that jives with Martin's research. I'll see about a PR.
--
[Issue 11098] template instance x cannot use local y as parameter to non-global template z
https://issues.dlang.org/show_bug.cgi?id=11098 r...@rcorre.net changed: What|Removed |Added CC||r...@rcorre.net --
Re: shared libs for OSX
On 2015-05-22 03:13, bitwise wrote: So does that mean that _dyld_register_func_for_add_image shouldn't be called at all from shared libs at all then? The fact that there is no unregister function seems to suggest that it's meant to be called once from the main executable to add a callbacck that survives the entire life of the program. Yes. Can't whatever the callback does be done from the runtime linked to the main executable? The runtime extracts some data from the loaded image and stores it in some global variable. If the executable would do this it needs to store the data in the global variable in the dynamic library. -- /Jacob Carlborg
Re: Python's features, which requires D
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/CNQQR
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).
Re: How to append range to array?
On Saturday, May 23, 2015 08:36:47 weaselcat via Digitalmars-d-learn wrote: On Saturday, 23 May 2015 at 08:35:45 UTC, weaselcat wrote: On Saturday, 23 May 2015 at 07:03:35 UTC, Vladimir Panteleev wrote: int[] arr = [1, 2, 3]; auto r = iota(4, 10); // ??? assert(equal(arr, iota(1, 10))); import std.array : array; arr ~ r.array; woops, meant ~= but this is probably fairly inefficient. Working with ranges and arrays at the same time feels really badly designed. It's fine if you're not interchanging them. It sounds like he probably wants to append to an existing array after some set of range operations are done. And that's not really any different from converting a range to an array via std.array.array except that the result ends up on the end of an existing array. The problem is that the output range API doesn't support that, because it treats arrays as buffers to be filled rather than appending to them. So, you probably either end up having to use Appender instead of a naked array, or you have to use foreach and append manually (or you could use std.array.array. and append the result, but I'd be surprised if that weren't less efficient). The problem is when you're trying to do range-based operations and throw array-specific operations in the middle of it. _That_ is what needs to be avoided. - Jonathan M Davis
Re: Dual conditions in D and Python
On Saturday, 23 May 2015 at 17:17:17 UTC, Andrei Alexandrescu
wrote:
On 5/21/15 2:35 PM, Ali Çehreli wrote:
On 05/21/2015 12:44 PM, Meta wrote:
All we need is user-defined opIs and then we're really
cooking with gas.
if (5 is between(4, 6))
{
//...
}
We're almost there. :)
bool is_between(T0, T1, T2)(T0 what, T1 min, T2 max)
{
return (what = min) (what = max);
}
void main()
{
if (5.is_between(4, 6)) {
// ...
}
}
In fact we'll be there with 2.068:
http://dlang.org/phobos-prerelease/std_algorithm_sorting.html#.ordered
if (ordered(4, 5, 6)) { ... }
if (strictlyOrdered(4, 5, 6)) { ... }
Andrei
I didn't realize this got pulled, I remember it being discussed a
while back on the general NG. Good addition.
