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...
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: 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: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.
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: .
You can work around that by passing the correct line terminator
to byLine: .
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 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: .
You can work around that by passing the correct line terminator
to byLine: .
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
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
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
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: 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.
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: 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? 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? You could have obtained answer long time ago by using debugger and looking into sources of druntime at github.
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
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: Python's features, which requires D
On Sat, 2015-05-23 at 12:58 +, 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 > > 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? 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. -- 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: 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 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: 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: 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: 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: 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 ?
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: 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 ?
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: 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.
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, 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: 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: 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 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: 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 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: 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);
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);
