Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote: The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. Go can move stacks and extend them. Go is closer to having a low latency GC. These are not small language issues for D.
Re: readln() doesn't stop to read the input.
On Friday, 27 March 2015 at 04:37:34 UTC, jonaspm wrote: Please, i need your help, I tried this: write(Write p: ); readln(p); p = chomp(p); writeln(Write q: ); readln(q); q = chomp(q); but the result is: Write p: Write q: and doesn't pause to read keyboard input... what's wrong? Thanks in advance! The easiest to use is the form string = readln(): write(Write p: ); auto p = readln().chomp(); write(Write q: ); auto q = readln().chomp(); The second version, length = readln(buffer), goes something like: auto buf = new char[1024]; write(Write p: ); string p = buf[0..readln(buf)].chomp().idup; write(Write q: ); string q = buf[0..readln(buf)].chomp().idup; It allows to reuse a preallocated buffer for greater speed and finer allocation control. Also worth noting, the best place for such questions in D.learn group: http://forum.dlang.org/group/digitalmars.D.learn Ivan Kazmenko.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote: Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important. That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong. What is almost always important is: 1. to be able to ship the product in a predictable fashion 2. not go 300-400% over budget 3. being able to train new people to maintain it in reasonable time 4. being able to add new unexpected features to the code base on request Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.
OT; Donald Knuth on beauty, efficiency, and the programmer as artist
An old essay that may yet be relevant today at a time when intellectual fashion has continued in the direction he was moved to address in his speech. there is a way to make a big improvement: it is still a pleasure to do routine jobs if we have beautiful things to work with. For example, a person will really enjoy wiping off the dining room table, day after day, if it is a beautifully designed table made from some fine quality hardwood. Language designers also have an obligation to provide languages that encourage good style, since we all know that style is strongly influenced by the language in which it is expressed. The present surge of interest in structured programming has revealed that none of our existing languages is really ideal for dealing with program and data structure http://www.paulgraham.com/knuth.html CACM, December 1974 When Communications of the ACM began publication in 1959, the members of ACM'S Editorial Board made the following remark as they described the purposes of ACM'S periodicals [2]: If computer programming is to become an important part of computer research and development, a transition of programming from an art to a disciplined science must be effected. Such a goal has been a continually recurring theme during the ensuing years; for example, we read in 1970 of the first steps toward transforming the art of programming into a science [26]. Meanwhile we have actually succeeded in making our discipline a science, and in a remarkably simple way: merely by deciding to call it computer science. Implicit in these remarks is the notion that there is something undesirable about an area of human activity that is classified as an art; it has to be a Science before it has any real stature. On the other hand, I have been working for more than 12 years on a series of books called The Art of Computer Programming. People frequently ask me why I picked such a title; and in fact some people apparently don't believe that I really did so, since I've seen at least one bibliographic reference to some books called The Act of Computer Programming. In this talk I shall try to explain why I think Art is the appropriate word. I will discuss what it means for something to be an art, in contrast to being a science; I will try to examine whether arts are good things or bad things; and I will try to show that a proper viewpoint of the subject will help us all to improve the quality of what we are now doing. ... As I was looking up these things about the meanings of art, I found that authors have been calling for a transition from art to science for at least two centuries. For example, the preface to a textbook on mineralogy, written in 1784, said the following [17]: Previous to the year 1780, mineralogy, though tolerably understood by many as an Art, could scarce be deemed a Science. According to most dictionaries science means knowledge that has been logically arranged and systematized in the form of general laws. The advantage of science is that it saves us from the need to think things through in each individual case; we can turn our thoughts to higher-level concepts. As John Ruskin wrote in 1853 [32]: The work of science is to substitute facts for appearances, and demonstrations for impressions. It seems to me that if the authors I studied were writing today, they would agree with the following characterization: Science is knowledge which we understand so well that we can teach it to a computer; and if we don't fully understand something, it is an art to deal with it. Since the notion of an algorithm or a computer program provides us with an extremely useful test for the depth of our knowledge about any given subject, the process of going from an art to a science means that we learn how to automate something. ... From this standpoint it is certainly desirable to make computer programming a science, and we have indeed come a long way in the 15 years since the publication ot the remarks I quoted at the beginning of this talk. Fifteen years ago computer programming was so badly understood that hardly anyone even thought about proving programs correct; we just fiddled with a program until we knew it worked. At that time we didn't even know how to express the concept that a program was correct, in any rigorous way. It is only in recent years that we have been learning about the processes of abstraction by which programs are written and understood; and this new knowledge about programming is currently producing great payoffs in practice, even though few programs are actually proved correct with complete rigor, since we are beginning to understand the principles of program structure. ... A scientific approach is generally characterized by the words logical, systematic, impersonal, calm, rational, while an artistic approach is characterized by the words aesthetic, creative, humanitarian, anxious, irrational. It seems to me
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, and is not a language issue (it's an implementation issue). Go is closer to having a low latency GC. I.e. it doesn't have one. These are not small language issues for D. GC issues are library issues, not language issues.
Re: readln() doesn't stop to read the input.
On Friday, 27 March 2015 at 04:37:34 UTC, jonaspm wrote:
Please, i need your help, I tried this:
write(Write p: );
readln(p);
p = chomp(p);
writeln(Write q: );
readln(q);
q = chomp(q);
but the result is:
Write p: Write q:
and doesn't pause to read keyboard input... what's wrong?
Thanks in advance!
This works for me on Linux:
---
import std.stdio;
import std.string;
void main()
{
char[] p, q;
p.length=1024;
q.length=1024;
write(Write p: );
readln(p);
p=p.chomp;
write(Write q: );
readln(q);
q=q.chomp;
writeln; writefln(p=%s, q=%s, p,q);
}
---
bye,
lobo
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Interfaces can be done with D templates. It'll be compile time polymorphism rather than run time, but the same effect will result (and of course it'll be faster). It's pretty much how Ranges work in D. Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. D needs to corral all the bits, which I think are there, to create a good offering. Yes. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 09:44:27 UTC, Walter Bright wrote: On 3/27/2015 1:41 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables So what? The point is there is PLENTY of virtual address space. You can allocate absurd amounts of address space for each goroutine, and still have plenty without physically moving anything. If you don't care about performance, bloated page tables and laying waste to memory: 1. Page tables are hierarchical, to save space nodes can point back to themselves. IFF the node is similar. Throwing shit all over the memory space makes this impossible. So you get BLOATed page tables. 2. All dirty pages maps to physical memory. So one recursion chain on a fiber will create a big physical mem allocation. To get rid of it you would have make a slow syscall. 3. You have no way to go below the page size for a stack. 4. Operating system calls like mmap are slow. 5. Trapped pages are slow and so are modifying page tables. 6. You cannot expect to get more than 47-53 bits of address space from the OS. It's not like 64 bits CPUs provide 64 bits address space. There is a big hole in the middle. Have you actually thought about these issues or done performance tests?
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: The problem, as Andrei Alexandrescu pointed out(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=6#post-mduv1i:242169:241:40digitalmars.com), is learning how to use them. Ideally you'd want to be able to look at a function's signature and learn from that how to use it. It's name and return type should tell you what it does and it's argument names and types should tell you what to send to it. The documentation only there for a more through description and to warn you about pitfalls and edge cases. But when it comes to heavily templated functions - understanding the signature is HARD. It's hard enough for the top programmers that can handle the complex D features - it's much harder for the average programmers that could have easily used these functions if they could just understand the documentation. I think the documentation should simply contain the unittests - they show quite well how to call the template, from minimal cases to the complex ones. Ok, they tend to show a lot of edge-cases, but even the very simplest usages of a function should be unit-tested, so at least those have to be part of the documentation.
[Issue 14348] New: typeof(x).ident is not accepted as a symbol
https://issues.dlang.org/show_bug.cgi?id=14348
Issue ID: 14348
Summary: typeof(x).ident is not accepted as a symbol
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: yebbl...@gmail.com
I don't see any reason why this shouldn't work:
class B
{
int foo() { return 0; }
}
class C : B
{
override int foo() { return 1; }
alias superfoo = typeof(super).foo;
alias thisfoo = typeof(this).foo;
}
void main()
{
assert(B.foo is C.superfoo);
assert(C.foo is C.thisfoo);
}
The current implementation requires the typeof(a).b expression evaluates to
both a type and a symbol, when only a symbol is required.
--
[Issue 12152] Cannot forward reference subclass member in superclass
https://issues.dlang.org/show_bug.cgi?id=12152 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12152] Cannot forward reference subclass member in superclass
https://issues.dlang.org/show_bug.cgi?id=12152 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/91dd1ff1ec207d3510fc12808e8166c3f80dab05 fix Issue 12152 - Cannot forward reference subclass member in superclass https://github.com/D-Programming-Language/dmd/commit/a17015aa5d0dbd2a0e1eca68067cb7f81ba48e32 Merge pull request #4469 from 9rnsr/fix12152 Issue 12152 - Cannot forward reference subclass member in superclass --
[Issue 14320] Improve diagnostic message for undefined identifier error
https://issues.dlang.org/show_bug.cgi?id=14320 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: readln() doesn't stop to read the input.
On 3/27/15 4:22 AM, tcak wrote:
On Friday, 27 March 2015 at 05:17:03 UTC, jonaspm wrote:
but readln(p); isn't supposed to read input and store it into p?
Nope. Parameter is terminator character. Read string is returned from
the function. So, it would be like:
string p = readln();
readln has an overload that looks like this:
size_t readln(C)(ref C[] buf, dchar terminator = '\x0a') if
(isSomeChar!C is(Unqual!C == C) !is(C == enum));
Which is what the OP is using (possibly, he never defines p and q).
As for the error, assuming you have proper buffer types for p and q, it
appears that your stdin is closed somehow. I think this is likely an
environmental issue. Please post the full code and describe the
environment if you need more help.
Your code works fine for me on OSX:
import std.stdio;
import std.string;
void main()
{
char[] p;
char[] q;
write(Write p: );
readln(p);
p = chomp(p);
writeln(Write q: );
readln(q);
q = chomp(q);
writeln(p, , q);
}
RUN:
Write p: adb;lna;lhiser
Write q:
slisieleru
adb;lna;lhiser slisieleru
-Steve
Re: Why dont dlang check NullPointer?
On 3/27/15 12:13 AM, deadalnix wrote: On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote: The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers. But this will make the developement more difficult for me, or not acceptable. Is there any other ways? http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ There is a hook in the runtime to enable this if you want. BUT, null pointer exception or not, Adam is right. Have your stuff run in multiple process that you can restart. This is more reliable, this is more secure, this is easier to update without downtime, and so on... This is far superior solution for server stuff. Please note, this is NOT a null pointer exception, it's a segfault exception. This can happen with corruption (absolutely should not continue) as well as forgetting to initialize a variable (dangerous if not handled correctly, but still feasible to continue). It may not be as black and white as if it's a null pointer that was dereferenced or not. I highly recommend terminating the process. As for the original question (why does D do this?), it's because the system ALREADY catches null pointer access. To add additional checks would slow down the system. And as you can see, you can hook these mechanisms to actually throw an exception, but this is a relatively recent development. In addition, as I mentioned, a seg fault can occur for a number of reasons, and D takes the position that you really should just terminate the process if this happens. The reason using multiple processes is more secure and reliable is because a rogue thread (one that has segfaulted because of a memory corruption error) can corrupt data in all your other threads. A separate process cannot. -Steve
Re: OT; Donald Knuth on beauty, efficiency, and the programmer as artist
Hmm... science exists only as long as we don't understand something, then it disappears and only knowledge remains. Looks like he talks about engineering, but calls it science.
Re: How does the D compiler get updated on travis-ci.org?
On Thursday, 26 March 2015 at 21:02:56 UTC, Alex Parrill wrote: On Thursday, 26 March 2015 at 20:40:50 UTC, Gary Willoughby wrote: On Thursday, 26 March 2015 at 19:37:06 UTC, extrawurst wrote: i think it is already available on travis. this it what works for me: https://github.com/Extrawurst/unecht/blob/master/.travis.yml ``` language: d d: - dmd-2.067.0 ``` I'm just using: language: d I hoped this would pick up the latest version. From the source [1], looks like its harcoded to default to 2.066.1. [1] https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script/d.rb i made a PR: https://github.com/travis-ci/travis-build/pull/414
[Issue 14348] typeof(x).ident is not accepted as a symbol
https://issues.dlang.org/show_bug.cgi?id=14348 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from yebblies yebbl...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4521 --
[Issue 14320] Improve diagnostic message for undefined identifier error
https://issues.dlang.org/show_bug.cgi?id=14320 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6d4c8492fb3c9879b918560afbb29133625ca122 fix Issue 14320 - Improve diagnostic message for undefined identifier error https://github.com/D-Programming-Language/dmd/commit/36059423f3b4a839455d6cc42c560ee33ce353fb Merge pull request #4510 from 9rnsr/fix14320 Issue 14320 - Improve diagnostic message for undefined identifier error --
Advise for syntax highlighting
I'm currently updating the TextMate D bundle for D2. I have a couple of
questions for how to highlighting some specific code or how other
editors/IDE's highlight them.
* this in constructor
this () {}
In TextMate functions/methods are highlighted, should this be
highlighted as a keyword or as a method?
* this in copy constructor
this (this) {}
The this parameter, should that be highlighted as a keyword or as a
parameter?
* The __ctfe variable
if (__ctfe) {}
How should this highlighted? I see a couple of alternatives:
- not at all
- as a keyword
- as a special recognized built-in symbol, similar to __LINE__
- as a special recognized library symbol. For example, in the C bundle
many of functions in the standard library are specially recognized and
highlighted differently. This might not apply here since it's not a
library symbol
* __traits identifiers
__traits(allMembers, Foo);
In this case allMembers. Basically the same question and alternatives
as for the __ctfe variable.
* Predefined version identifiers
version (OSX) {}
Again, same a question and alternatives as for the __ctfe variable.
* Extern identifiers
extern (C)
Again, same a question and alternatives as for the __ctfe variable.
--
/Jacob Carlborg
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 03:11 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: […] However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem. If no-one is resourced to write the code, it will not get written. -- 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: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 10:14 +, via Digitalmars-d-announce wrote: […] Have you actually thought about these issues or done performance tests? The Go team certainly have, and have changed their goroutine model twice because of it. No matter what they do in Go 0.0 →1.4, 1.5 onwards will be different since the who system is being revised: Go implemented Go toolchain, new GC, new runtime. I suspect Go 1.6 will be the watershed for this, but that will likely be 2016. The question is though what should happen in D. If Vibe.d fibres are a single threaded system, then they are not suitable for the actor, dataflow, CSP implementation needed in D since that must sit on a kernel thread pool where each lightweight thread is animated by whichever work stealing kernel thread comes along. Erlang, Go, GPars, Quasar, etc. all have different solutions to the problem of thread pools and task switching since the context is all important. -- 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: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 10:37:01 UTC, Russel Winder wrote: The question is though what should happen in D. If Vibe.d fibres are a single threaded system, then they are not suitable for the actor, dataflow, CSP implementation needed in D since that must sit on a kernel thread pool where each lightweight thread is animated by whichever work stealing kernel thread comes along. Erlang, Go, GPars, Quasar, etc. all have different solutions to the problem of thread pools and task switching since the context is all important. Yes, I agree that the question is what should happen in D. But the claim was that D provides everything Go does and there is only a tiny scheduler that is missing. I don't think D benefits from these claims. Benchmark D thoroughly against Go before making claims or just give Go credit for being better in some areas. If it was up to me then co-routines would be ripped out of the language. They are a cross cutting feature that makes significant optimizations and improvements difficult or impossible.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 12:37 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote: On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, It has. The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. The MMU can map and remap that to physical memory on demand through the address translation tables. Moving stacks is a great solution for 1995 computers.
[Issue 10925] unittests qualified on the right hand side fail
https://issues.dlang.org/show_bug.cgi?id=10925 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement --- Comment #4 from Walter Bright bugzi...@digitalmars.com --- This is an enhancement request, not a bug. --
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thu, 2015-03-26 at 18:47 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote: (Almost) All publicity is good publicity. I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write Go code in D much like you can write C code in D. That is almost certainly true. I suspect you can write Go in C++ as well. D and C++ are definitely supersets of Go. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Aren't green threads now given the label fibres? And I think Vibe.d has an implementation for these – but I do not know for certain. The dataflow way of working and the special case CSP, also actors are clearly the right abstraction for most parallel computation, using as we all agree, a kernel thread pool animating tasks. std.parallelism has something along these lines but focussed on data parallelism. Given the existence of C++CSP2 (http://www.cs.kent.ac.uk/projects/ofa/c ++csp/) D can get a CSP implementation for free, especially if the recent innovation on C++ working come to fruition. As work on GPars and Quasar in the JVM arena, and Erlang and Go since they were created, show, lightweight processes with communication channels is the next step in providing good abstractions for CPU and IO bound processing. Anthony Williams (Just Software, https://www.justsoftwaresolutions.co.uk/)) has been at work trying to put actors and dataflow on top of C++11 threads, with some success. D needs to corral all the bits, which I think are there, to create a good offering. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. -- 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
[Issue 14322] Menu on downloads.dlang.org is completely broken
https://issues.dlang.org/show_bug.cgi?id=14322 Jacob Carlborg d...@me.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: DlangUI
On Thursday, 26 March 2015 at 13:48:20 UTC, Chris wrote: On Thursday, 26 March 2015 at 11:47:59 UTC, Vadim Lopatin wrote: Try `dub upgrade --force-remove` followed by `dub build --force` For the love of God, please put this on the github page under troubleshooting. It happens quite a lot. Ok. Added following notice to README (you can see it on project main page on GitHub) Important notice If build of your app is failed due to dlangui or its dependencies, probably you have not upgraded dependencies. Try following: dub upgrade --force-remove dub build --force As well, sometimes removing of dub.json.selections can help.
Re: problems with std.bitmanip.append (bug?)
On Friday, 27 March 2015 at 00:50:34 UTC, Hugo wrote:
On Thursday, 26 March 2015 at 12:29:03 UTC, John Colvin wrote:
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes
of invocation...
void main() {
import std.stdio, std.array, std.bitmanip, std.system;
auto buffer = appender!(const ubyte[])();
buffer.append!(ushort, Endian.littleEndian)(261);
assert(buffer.data == [5, 1]);
writefln(%s, buffer.data);
}
Thanks, although it puzzles me that one has to move the type
inside the parenthesis and the value after them, otherwise it
doesn't compile.
It looks quite irregular, at least to someone like me, more
used to function than templates. :(
Think of it as compile-time arguments and run-time arguments.
First set of parenthesis are compile-time, second are run-time.
The parenthesis are optional for compile-time arguments iff
there's only one of them.
I wish one could simply append a buffer using the concatenation
operator, which would be the obvious choice, but it doesn't
seem to work for ubytes...
I agree that std.bitmanip often doesn't have the most intuitive
interface.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables
Re: Class Hierarchy Graphs
On Friday, 27 March 2015 at 08:26:51 UTC, Dragos Carp wrote: On Thursday, 26 March 2015 at 17:41:58 UTC, w0rp wrote: If enough people are interested and have a few suggestions for some features they like which aren't crazy massive feature lists, I'd be willing to expand it a bit, add some documentation, and offer it as a DUB package. Very nice! PlantUML [1] output would be even nicer! [1] http://plantuml.sourceforge.net/classes.html I'll give that a go. I was thinking before of offerring a DOT file with just the class and interface names, and another one with the class and interface names and some methods. I might support that and also PlantUML. I've been considering some kind of web-friendly format, but I'm not sure what to do for that yet. Maybe it's enough to have Graphviz output an SVG. Last night I simplified part of the code and re-arranged everything into a DUB package format, which wasn't too hard. I'll probably work on it over the weekend.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 1:41 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables So what? The point is there is PLENTY of virtual address space. You can allocate absurd amounts of address space for each goroutine, and still have plenty without physically moving anything.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 06:53:01 UTC, Walter Bright wrote: On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, It has. and is not a language issue (it's an implementation issue). It is if you cannot control references to the stack. Go is closer to having a low latency GC. I.e. it doesn't have one. Comes in Go 1.5. https://docs.google.com/document/d/1wmjrocXIWTr1JxU-3EQBI6BK6KgtiFArkG47XK73xIQ/preview?sle=true These are not small language issues for D. GC issues are library issues, not language issues. It is a language issue if you want it to perform well.
Re: Why dont dlang check NullPointer?
On Friday, 27 March 2015 at 03:46:49 UTC, zhmt wrote:
class A
{
void test()
{
writeln(test);
}
}
try
{
A a = null;
a.test();
}catch(Throwable t)
{
writeln(t.msg);
}
The code above will not print a exception message, but crashes
instead.
I dont think this a good choice for most scenes. For example,I
developed many modules in my server, and add a new module now.
If null exception happens, I hope the server continue running,
not crash. If the server continue running, the functions
offered by old modules can be used by users, only the new
module stop serving.
In short words, I want to catch something like
NullPointerException.
Is this possible?
GCC has the switch -fno-non-call-exceptions, but not sure if GDC
does. You could ask in the gdc forum?
Re: readln() doesn't stop to read the input.
On Friday, 27 March 2015 at 05:17:03 UTC, jonaspm wrote: but readln(p); isn't supposed to read input and store it into p? Nope. Parameter is terminator character. Read string is returned from the function. So, it would be like: string p = readln();
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 08:41:40 UTC, Ola Fosheim Grøstad wrote: tables? If you want to address more than 512GB you need to move to 1MiB pages. Actually, it is 2MiB. Also keep in mind that there is an advantage to having very small stacks (e.g. 1-2K) when you do simulations.
Re: Why dont dlang check NullPointer?
zhmt: In short words, I want to catch something like NullPointerException. Is this possible? One solution is to add null tests to D in nonrelease mode. A better solution is to modify D to remove all or most chances of dereferencing null pointers and class references. Bye, bearophile
Re: Feature idea: scope (failure, ExceptionSpecification) for catching exceptions
On 2015-03-26 12:23, Andrej Mitrovic via Digitalmars-d wrote:
One idea I'd like to see is to enhance scope(failure) to allow it to
catch a specific type of exception which would allow us to e.g. log
the exception message and potentially re-throw the exception. All of
this without having to nest our code in try/catch statements.
Sounds like you want a catch statement without being tied to a try
statement. Something like this exists in Ruby:
With begin/end:
def foo
begin
raise 'foo'
rescue Exception = E
p e
end
end
Without:
def foo
raise 'foo'
rescue Exception = E // tied to the function scope
p e
end
In the above example the rescue is tied to the function scope.
Something similar could be supported in D:
void foo ()
{
throw new Exception(foo);
catch (Exception e) // tied to the function scope
writeln(e);
}
Or possibly tie it to the most enclosing scope:
void foo ()
{
{
throw new Exception(foo);
catch (Exception e) // tied to the scope
writeln(e);
}
}
I wouldn't mind if this was supported.
--
/Jacob Carlborg
Re: between and among: worth Phobosization? (reprise)
On Friday, 27 March 2015 at 01:53:22 UTC, H. S. Teoh wrote: On Fri, Mar 27, 2015 at 01:37:45AM +, Vladimir Panteleev via Digitalmars-d wrote: On Thursday, 26 March 2015 at 22:23:12 UTC, Andrei Alexandrescu wrote: New idea: bool ordered(pred = a b)(T...)(T values) So... isSorted for tuples? That's pretty much what it is, and I'm wondering why use a completely different name rather than overload isSorted. T import std.typecons : ∑ = tuple; ∑(a, x, b).isSorted; Or maybe not, haha! It's kinda tempting for personal projects, as ∑ is just alt-w on my macbook...
Re: Class Hierarchy Graphs
On Thursday, 26 March 2015 at 17:41:58 UTC, w0rp wrote: If enough people are interested and have a few suggestions for some features they like which aren't crazy massive feature lists, I'd be willing to expand it a bit, add some documentation, and offer it as a DUB package. Very nice! PlantUML [1] output would be even nicer! [1] http://plantuml.sourceforge.net/classes.html
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei Downplaying other languages makes the D crowd look desperate... Go has stability, is production ready and has an ecosystem with commercial value. D lacks all of these atm... Not to mention that Go is in GCC for a very long time already... :) I never liked the language much (I think Erlang or Scala are definitely better choices than Go), but it is in a much better shape than D (unless you want to use stable D1).
Re: HTTP() from std.net.curl hidden state
It looks like in perform() method curl option is set: p.curl.set(CurlOption.customrequest, DELETE); but is never reset and all requests after DELETE are DELETE too (even if asked for POST).
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 11:11 schrieb Walter Bright: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses).
Re: HTTP() from std.net.curl hidden state
Solved by a workaround: // before anything else in method call() http.handle.set(CurlOption.customrequest, cast(void*) null); http.clearRequestHeaders(); Hope this will help is anyone else has this problem.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 21:00:37 UTC, Andrei Alexandrescu wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei If Go community is what they believe they are - intelligent. They would not blame D community for this article, but the person who wrote it. - It is not tagged Opinion for no reason !! My personal opinion about the article - people may hate D equally for being too pragmatic. That `source.byLine.join.to!(string);` line for example, takes much longer time to understand than 20 lines of Go code. Any D newbie with knowledge of some modern language will struggle understanding (and being 100% sure that he/she understands!) that line of D code. I could give a big list of things where Go has advantage over D. What I found pathetic is that Go community used list of established open-source projects done in Go. :) But OK, we expected that, did we?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: Am 27.03.2015 um 11:11 schrieb Walter Bright: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. It has, that is more or less the original selling point. It also keeps an internal thread pool where each thread has a dynamic set of reusable fibers to execute tasks. Each fiber is bound to a certain thread, though, and they have to, because otherwise things like thread local storage or other thread specific code (e.g. the classic OpenGL model, certain COM modes etc.) would break. Apart from these concerns, It's also not clear to me that moving tasks between threads is necessarily an improvement. There are certainly cases where that leads to a better distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). I've always wondered whether thread-local fibers with a stop-the-world (or at least part of the world) load balancer that can move them would be a good model. You could get away without a lot of synchronisation e.g. tls could be fixed-up from the scheduler thread while all the others are stopped. Perhaps there are good reasons why not, I don't know enough to say...
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 03:53:36 UTC, Laeeth Isharc wrote: That kind of articles are bad for the image of the D community Nick S: No. Just...no. I'm honestly *really* tired of general society's (seemingly?) increasing intolerance FOR intolerance. Some things ARE bad. Some ideas are dumb ideas (ie without merit). Some features are bad features. Some products really are crappy products. Calling it out when you see it, using a frank explanation of your reasoning, isn't bad, it's productive. Excellence is incompatible with tolerating mediocrity or what is appalling, and what I have seen is that there are aesthetic aspects to creative endeavours not conventionally thought of as having an aesthetic element, and it is in the nature of such things that one cannot and should not tolerate what one perceives to be ugly in a creative endeavour. If one is driven mostly by ROI rather than high feelings, one doesn't get to excellence. So it is my belief that dealing with creative people means dealing with a certain ... intensity. That (on the aesthetic aspects of technical fields) is not just my opinion, but also (I think) that of a certain Mr W Bright, judging by his comments on how good code should look and on good aircraft design, although he presented this in his usual low-key manner. I was looking for a language that was beautiful, as well as powerful, and for whatever it is worth, this was a factor of high appeal with D. It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. ...The inexperienced, the crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought. - Feynman via Wikiquote (but the same idea comes across in his books). To discourage dissent, objections, or complaints is to rob ourselves of potential improvement. *That's* what critique and complaints and objections ARE: Recognition of the potential for improvement. There *cannot* be progress and improvement without first identifying existing faults. If nobody ever identified and voiced criticism of punchcards, for example, we'd all still be stuck in the world of 1950's computing. Excellently put. (And, I would add, a constructive draw towards what is generative - not just fault-finding). It's not as if the D crowd doesn't critique itself and it's own language just plenty, so it's not like there's any hypocrisy here. And I'm certainly not willing to accept that programmers should be viewed as being part of distinct mutually-exclusive factions based on some single-language allegiance. I'm a D guy. I also happen to be a fan of Nemerle. And both languages have things I hate. So scratch the it's the D crowd idea. Interesting - what should I read about Nemerle, and what is it best at ? And seriously, the article in question barely mentions D at all. So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it? Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow. I was just thinking yesterday how working with D makes me happy whereas working with other (lower) languages makes me grumpy. Going down to the punchcard level (PHP, JS etc.) is boring and doesn't do justice to the human mind. Whenever I use D, I am confident that I can map a complicated reality onto a machine, it inspires me and it challenges me. Primitive languages discourage me. So there's more to productivity than meets the eye when looking at numbers. Numbers are insignificant, they can prove anything you want, and you can tweak them any way you want. Eat shit, a million flies can't be wrong!, as they say. It's one thing to be productive in terms of maintaining and selling apps and another in terms of being innovative. You can sell a million records by sticking to well-trodden
Re: Advise for syntax highlighting
On Friday, 27 March 2015 at 10:34:58 UTC, Jacob Carlborg wrote:
I'm currently updating the TextMate D bundle for D2. I have a
couple of questions for how to highlighting some specific code
or how other editors/IDE's highlight them.
* this in constructor
this () {}
In TextMate functions/methods are highlighted, should this be
highlighted as a keyword or as a method?
* this in copy constructor
this (this) {}
The this parameter, should that be highlighted as a keyword
or as a parameter?
* The __ctfe variable
if (__ctfe) {}
How should this highlighted? I see a couple of alternatives:
- not at all
- as a keyword
- as a special recognized built-in symbol, similar to __LINE__
- as a special recognized library symbol. For example, in the C
bundle many of functions in the standard library are specially
recognized and highlighted differently. This might not apply
here since it's not a library symbol
* __traits identifiers
__traits(allMembers, Foo);
In this case allMembers. Basically the same question and
alternatives as for the __ctfe variable.
* Predefined version identifiers
version (OSX) {}
Again, same a question and alternatives as for the __ctfe
variable.
* Extern identifiers
extern (C)
Again, same a question and alternatives as for the __ctfe
variable.
Am using Textadept, the highlighting is as follows:
highlighted as keyword:
this()
__traits
extern(C) // The extern; C isn't highlighted at all
highlighted as a special recognized built-in symbol, similar to
__LINE__:
version(OSX) // the OSX; version is highlighted as keyword
not highlighted at all:
__ctfe
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Thursday, 26 March 2015 at 21:36:56 UTC, rumbu wrote: On Thursday, 26 March 2015 at 19:45:19 UTC, Alex Parrill wrote: On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: ...snip... So tl;dr; make the template constraints in ddoc less prominent? The new library reference preview under Resources seems to already have this (example: http://dlang.org/library/std/algorithm/searching/starts_with.html) This will not solve the readability problem: - what is a range? - what is a needle? - what is a predicate? Phobos is reinventing the OOP encapsulation without providing the minimal tools. IMHO, something similar to interface is mandatory to define constraints for range and the relationship between needle and range. Never heard that complain about python's protocols which have no language support whatsoever.
Re: Solution to problems:
On Thursday, 26 March 2015 at 22:05:27 UTC, Andrei Alexandrescu wrote: On 3/26/15 2:23 PM, Jake The Baker wrote: But until people stop acting like little children and think seriously about the problems, goals, and solutions then who the heck knows what to do? http://wiki.dlang.org/Vision/2015H1 -- Andrei Yes, but you had to pull that up for me. Suppose there was a one stop D shop that had all this stuff available, direct, and immediate? A place that one could get there D fix in many ways. A facebook for D coders, so to speak. All integrated into an IDE proper. (collaboration, development, documentation, core development, etc) My main point about the child remark is that there are very few people here(you, Walter, and a handful of others) actually doing all the heavy lifting and most others(including myself) just talk or do minimal work that ultimately won't lead anywhere(At least any time soon). What good is D if no one uses it? What good is it if all the libraries used have poor or hidden documentation? What good is it if the average noob gets board with it and gives up trying to get it to work? (Not just D, which is, of course, easy to setup if you don't mind doing a little text editing and file manipulation) This is what I imagine. I know it can be done, that is not the issue. This is all standard programming stuff. That is not the point. The point is, to discuss ideas freely so the best solution(Which is usually a combination of all relevant inputs). 1. Get up in the morning 2. Turn on computer. 3. Run the famous D IDE 4. Immediately on loading on presented with the main window(eclipse, visual studio, etc...) 5. Apon loading I notice I have a msg from Joe. Seems Joe found a bug and he thinks maybe I can fix it. 6. I download his project(all handled by the IDE, as it has a build in messenger system). 7. Load up the probject, find the bug, can quickly match the bug to the D internals since it's all there. (can jump to core source code and look at it from any version. All the details of versioning is handed behind the scenes. All I have to do is click on a button to select which version I want to use. 8. So I write small patch quickly(just needed a null check or what ever). I can cross reference the bug's(find out if anyone else has the issue, the discussions involved, all at a drop of a click. 9. I can submit the patch. Internally the IDE handles creating the patch report, all the info(source code, test project, info(line numbers, file names, etc) 10. Now, I'm done with the patching. I want to see what currently has been done already in the last week. I can easily see the whats new and extract relevant info by filtering. (I could filter only on core topics, forum posts, etc) 11. By doing so, I find out that the bug I reported on as similar bugs. I can further investigate that and see how it all relates. I can pin, follow, start, (potentially) merge, etc topics, bugs, patches, etc. 12. I can jump over to Walter's D blog and see what he is up to. 13. I can check out the main Vision which is interactive. (click the year see the topics for that year, see the individual progress(would be great to have a sort of project manager build in). 14. After I have all that fun(With the world of D at my finger tips in the IDE) I can simply open up some project I've been working on. 15. The IDE has complete cross-referencing of documentation built in and very fast. It has full intelligent support. All the standard IDE stuff. 16. The only thing really difference from this point on is that I can easily send people projects(simply send project o Joe, Mike, Other where Joe and Mike are my buddies that have joined my project)... all standard collaboration stuff but quick access. They can even remote view the project if I allow them. 17. e.g., imagine how much easier it would be for people to solve problems if they could easily remote view into a project? etc.. etc.. etc.. 18. Of course, If I wanted to switch to C++ or (D++?) I could do so at the drop of a hat. The IDE should be somewhat language agnostic. (this would allow you to do benchmarks and comparisons easily between different languages... easy Go and D. 19. Not only that, Suppose I have a bug in my code. The IDE can automatically cross-reference the error code with all bug reports, forum posts or whatever. I can show anyone who is working on the patches, allow me to join the discussion or whatever. Similar to Git in many ways. The point is quick. I don't have to open a browser, go to my favorite search engine, sift through hundreds of irrelevant posts just to find that Bob had the same bug and no one is working on it. Might take me 10 mins, or 10 hours, or even 10 months to figure out what is going on or to fix it. The point being, we know that having this so called perfect IDE would solve many problems. The real question is it worth doing? Will having such a thing ultimately bind all the looseness that the D community has into one well oiled
Re: Solution to problems:
On Thursday, 26 March 2015 at 22:33:33 UTC, ketmar wrote: On Thu, 26 Mar 2015 21:28:13 +, Jake The Baker wrote: On Thursday, 26 March 2015 at 07:06:50 UTC, ketmar wrote: On Wed, 25 Mar 2015 16:56:32 +, Jake The Baker wrote: Do *you know what progress is? one important part of progress is not wasting time on useless things. And yet you seem to think D's progress is efficient. sorry, but your mind-reading abilities are weak. i believe that using IDEs greatly weakens telepathy trait. Thanks for proving my point!
Re: DDT 0.11.0 released (please read!)
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Note that there is a tool recently released, Eclipse Optimizer, that can help optimize Eclipse startup time: Also, to improve Eclipse performance and startup time, it is recommended you tweak the JVM parameters. There is a tool called Eclipse Optimizer that can do that automatically, it is recommended you use it. Read more about it http://www.infoq.com/news/2015/03/eclipse-optimizer . (Installing/enabling the JRebel optimization is not necessary as that only applies to Java developers) I've added the above info to the User Guide. Also, because Google Code is shutting down, I've moved the DDT project homepage to: http://ddt-ide.github.io/ -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: A reason to choose D over Go
On 2015-03-25 10:17:00 +, Bienlein said: I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them. Please drop a comment in this thread or somewhere when it is published. Cheers, Bienlein D is a superset of go's functionality aside from the structural typing (which in my opinion is a huge fail for a variety of reasons you will see if you try to use it for anything extensive). If you don't want to learn about templates and metaprogramming, then don't. I fail to understand why having extra features is a deterrant? -Shammah
Re: Can we deprecate D-style Variadic Functions
On 2015-03-26 01:04:03 +, Freddy said:
On Thursday, 26 March 2015 at 00:11:05 UTC, Dicebot wrote:
On Wednesday, 25 March 2015 at 22:12:04 UTC, Freddy wrote:
D-style Variadic Functions found here:http://dlang.org/function.html
seem entirely out classed by Variadic Function Templates. Can we
deprecate them?
Those are two different concepts with different trade-offs. Using
variadic templates adds template bloat. Using D-style variadics
requires RTTI (and small overhead for it). It is up to
library/application writer to decide what is best in his case.
My ploblem is that Variadic Function shouldn't be builtin the language.
They are rarely need and can be abstracted into a library. Something
like this:
```
import core.stdc.stdlib: alloca;
import std.stdio;
template VariadicFunction(alias Imp){
auto VariadicFunction(T...)(T args){
enum size=T.length * TypeInfo.sizeof;
auto rtti=cast(TypeInfo[])(alloca(size)[0..size]);
foreach(i,type;T){
rtti[i]=typeid(type);
}
//auto data=args; bug? doesn't work
void* data;
{
size_t datasize;//T.sizeof doesn't work
foreach(type;T){
datasize+=type.sizeof;
}
data=alloca(datasize);
size_t inc;
foreach(v;args){
*cast(typeof(v)*)(data+inc)=v;
inc+=v.sizeof;
}
}
Imp(data,rtti);
}
}
private void rtVariadicImp(void* vars,scope const TypeInfo[] rtinfo){
writeln(*cast(int*)vars);
writeln(rtinfo);
}
alias rtVariadic=VariadicFunction!(rtVariadicImp);
void main(){
rtVariadic(1,'a');
}
```
I disagree, and your example does not get rid of the template bloat.
That does in fact instantiate a template for every set of argument
types.
-Shammah
Re: Advise for syntax highlighting
On Friday, 27 March 2015 at 14:10:22 UTC, Jacob Carlborg wrote: On 2015-03-27 15:03, Chris wrote: Well, it _is_ a keyword. You cannot write a function called this, nor can you use it as a variable name. So yes, it's a keyword = reserved. It depends on how you see it. It's also a special method that just happens to use a keyword as its name. It doesn't have the same meaning as this instead a regular method. Either way, it should be highlighted somehow.
Re: Advise for syntax highlighting
On 2015-03-27 13:33, Chris wrote: Am using Textadept, the highlighting is as follows: highlighted as keyword: this() Why is this highlighted as a keyword? I was more leaning to highlight it as a method. What about the parameter in a copy constructor? __traits What about the identifiers/keywords used as the first argument to __traits? -- /Jacob Carlborg
Re: pureity of closures
On 2015-03-23 09:45:39 +, Dicebot said: I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case) Pure functions returning impure functions. *BOOM* My brain just exploded. -Shammah
Re: Advise for syntax highlighting
On 2015-03-27 15:03, Chris wrote: Well, it _is_ a keyword. You cannot write a function called this, nor can you use it as a variable name. So yes, it's a keyword = reserved. It depends on how you see it. It's also a special method that just happens to use a keyword as its name. It doesn't have the same meaning as this instead a regular method. -- /Jacob Carlborg
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Friday, 27 March 2015 at 10:10:37 UTC, Dominikus Dittes Scherkl wrote: On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: But when it comes to heavily templated functions - understanding the signature is HARD. It's hard enough for the top programmers that can handle the complex D features - it's much harder for the average programmers that could have easily used these functions if they could just understand the documentation. I think the documentation should simply contain the unittests - they show quite well how to call the template, from minimal cases to the complex ones. Ok, they tend to show a lot of edge-cases, but even the very simplest usages of a function should be unit-tested, so at least those have to be part of the documentation. Unittests are helpful, but I think examples aimed at demonstrating usage are of more value if possible. Unittests and examples have subtly different purposes. When writing a Unittest the programmer will likely take whatever shortcuts they can to get data into the tested function in the correct format, with the least amount of code/effort legally possible. Whereas examples (hopefully) will try to present inputs in 'real life' scenarios. If the function inputs are trivial (ie. takes an integer or basic string) then this isn't an issue. But for functions taking complex inputs it can be a bit baffling for someone new to the language. I must admit when I was new to phobos I struggled with the use of unittests as examples, especially for functions taking Anyway, unittests are better than nothing - if that is the other option.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Friday, 27 March 2015 at 13:07:30 UTC, Panke wrote: On Thursday, 26 March 2015 at 21:36:56 UTC, rumbu wrote: On Thursday, 26 March 2015 at 19:45:19 UTC, Alex Parrill wrote: On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: ...snip... So tl;dr; make the template constraints in ddoc less prominent? The new library reference preview under Resources seems to already have this (example: http://dlang.org/library/std/algorithm/searching/starts_with.html) This will not solve the readability problem: - what is a range? - what is a needle? - what is a predicate? Phobos is reinventing the OOP encapsulation without providing the minimal tools. IMHO, something similar to interface is mandatory to define constraints for range and the relationship between needle and range. Never heard that complain about python's protocols which have no language support whatsoever. I've never used Python, so take this as a live experiment: I googled for startswith python: str.startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of prefixes to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. In 3 seconds, I understood the basic usage, without ANY knowledge about Python. Even if I don't know Python, the brackets told me that start and end are optional. str, prefix, start, end - comprehensible simple words. The only thing remaining is the tuple thing. But I can use this function without knowing what a tuple is. Looked also in the source code to find out that startsWith is locale sensitive, something ignored in phobos. https://hg.python.org/cpython/file/4ebe1ede981e/Objects/stringobject.c#l2903 Now compare with this: uint startsWith(alias pred = a == b, Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range Needles.length 1 is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint)); bool startsWith(alias pred = a == b, R1, R2)(R1 doesThisStart, R2 withThis) if (isInputRange!R1 isInputRange!R2 is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool)); bool startsWith(alias pred = a == b, R, E)(R doesThisStart, E withThis) if (isInputRange!R is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool)); *Checks whether the given input range starts with (one of) the given needle(s).* I'm not a native English speaker, but a range can start with a needle? Where is the haystack? :) Anyway, in the Python built-in lib I didn't find any levenshtheinDistance, boyermooreFinder or schschchcscshshscscshshscscssscsshcswarzSort.
Re: Advise for syntax highlighting
On Friday, 27 March 2015 at 13:58:03 UTC, Jacob Carlborg wrote: On 2015-03-27 13:33, Chris wrote: Am using Textadept, the highlighting is as follows: highlighted as keyword: this() Why is this highlighted as a keyword? I was more leaning to highlight it as a method. Well, it _is_ a keyword. You cannot write a function called this, nor can you use it as a variable name. So yes, it's a keyword = reserved. What about the parameter in a copy constructor? __traits What about the identifiers/keywords used as the first argument to __traits? Not highlighted.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). It is a complete disaster to not move fibers between threads if you want good latency.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Friday, 27 March 2015 at 14:02:55 UTC, CraigDillabaugh wrote: clip If the function inputs are trivial (ie. takes an integer or basic string) then this isn't an issue. But for functions taking complex inputs it can be a bit baffling for someone new to the language. I must admit when I was new to phobos I struggled with the use of unittests as examples, especially for functions taking for functions taking ranges or other non-trivial inputs. Anyway, unittests are better than nothing - if that is the other option.
Re: problems with std.bitmanip.append (bug?)
On Friday, 27 March 2015 at 08:43:56 UTC, John Colvin wrote: Think of it as compile-time arguments and run-time arguments. First set of parenthesis are compile-time, second are run-time. The parenthesis are optional for compile-time arguments iff there's only one of them. I really appreciate this little explanation, now it makes some sense.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
Looked also in the source code to find out that startsWith is locale sensitive, something ignored in phobos. Why would I need a locale for startsWith? Please file a bug, if that's actually needed for unicode strings.
Re: Why dont dlang check NullPointer?
On 2015-03-27 05:34:59 +, zhmt said: On Friday, 27 March 2015 at 04:13:01 UTC, deadalnix wrote: On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote: The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers. But this will make the developement more difficult for me, or not acceptable. Is there any other ways? http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ There is a hook in the runtime to enable this if you want. BUT, null pointer exception or not, Adam is right. Have your stuff run in multiple process that you can restart. This is more reliable, this is more secure, this is easier to update without downtime, and so on... This is far superior solution for server stuff. multi-process means crashes are isolated by process, but isolated by thread may be more handy. For example , this feature is suported by java c# lua, ie. This can make dlang app developed by most developers more reliable. All the languages you mention run in a VM. In the case of a systems language like D, the operation system itself is intercepting the reference to invalid memory and sending a SIGSEG to the process. The default handler causes the process to immediately terminate. Having the D runtime do something different in the SIGSEG handler by default would be bad form. -Shammah
Re: Human unreadable documentation - the ugly seam between simple D and complex D
[skip] I'm not a native English speaker, but a range can start with a needle? Where is the haystack? :) Yes the output is awful, but that does not imply some kind of concepts is needed to make the documentation easier to understand. And Python's startsWith makes no use of a protocol. See here http://www.rafekettler.com/magicmethods.html for an explanation. Now that we're talking about creating your own sequences in Python, it's time to talk about protocols. Protocols are somewhat similar to interfaces in other languages in that they give you a set of methods you must define. However, in Python protocols are totally informal and require no explicit declarations to implement. Rather, they're more like guidelines. It's similar to what we have, just with even less help from the language. (We can at least statically check that some arguments is e.g. a range). Anyway, in the Python built-in lib I didn't find any levenshtheinDistance Please calculate the levenshtein distance of aaabc and ababc both in python and D. Then come back and tell me it was too hard in D compared to Python. , boyermooreFinder or schschchcscshshscscshshscscssscsshcswarzSort. Both are well known and useful algorithms. You might not know them but that's actually no argument not to include them in phobos. Their presence does not make the documentation any harder to understand or harder to find a startsWith function. I don't buy this There is a function I don't know, it's so hard to understand thing. That's like saying: I only need XML, don't put JSON in the stdlib because I will get confused! How should I anticipate that I don't need std.json when I just want to parse XML? I cannot even google that for me.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On 2015-03-26 19:32:51 +, Idan Arye said: There is a discussion about D vs Go going on in several threads(yey for multithreading!), and one thread is about an article by Gary Willoughby that claims that Go is not suitable for sophisticated programmers(http://forum.dlang.org/thread/mev7ll$mqr$1...@digitalmars.com). What's interesting about this one is the reddit comments, which turned into an argument between simple languages that average programmers can use and complex languages that only the top 1% of intelligent programmers can use, but they can extract more out of them. But the thing is - the world of the top programmers is not really separate from that of average programmers. Professional development teams can have a few top programmers and many average one, all be working on the same project. Open source projects can have top programmers working on the core while allowing average programmers to contribute some simple features. Top programmers can write libraries that can be used by average programmers. To allow these things, top programmers and average programmers should be able to work on the same language. Of course, any language that average programmers can master should be easy for a top programmer to master - but the thing is, we also want the top programmer to be able to bring more out of the language, without limiting them by it's over-simplicity. This will also benefit the average programmers, since they also improve the quality of the libraries and modules they are using. This idea is nothing new, and was mentioned in the main(=biggest) current D vs Go thread(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=3#post-jeuhtlocousxtezoaqqh:40forum.dlang.org). What I want to talk about here is the seams. The hurdles that in practice make this duality harder. Let's compare it to another duality that D(and many other languages, mainly modern systems languages) promotes - the duality between high-level and low-level. Between write-code-fast and write-fast-code. The transition between high-level and low-level code in D consists by a change of the things uses - which language constructs, which idioms, which functions. But there aren't any visible seams. You don't need to use FFI or to dynamically load a library file written in another language or anything like that - you simply write the high-level parts like you would write high-level code and the low-level parts like you would write low-level code, and they just work together. The duality between high-level D and low-level D is seamless. The duality between simple D and complex D - not so much. The seams here exist mainly in understanding how to use complex code from simple code. Let's take std.algorithm(.*) for example. The algorithms' implementations there are complex and use advanced D features, but using them is very simple. Provided, of course, that you know how to use them(and no - not everything that you know becomes simple. I know how to solve regular differential equations, but it's still very complex to do so). The problem, as Andrei Alexandrescu pointed out(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=6#post-mduv1i:242169:241:40digitalmars.com), is learning how to use them. Ideally you'd want to be able to look at a function's signature and learn from that how to use it. It's name and return type should tell you what it does and it's argument names and types should tell you what to send to it. The documentation only there for a more through description and to warn you about pitfalls and edge cases. But when it comes to heavily templated functions - understanding the signature is HARD. It's hard enough for the top programmers that can handle the complex D features - it's much harder for the average programmers that could have easily used these functions if they could just understand the documentation. Compare it, for example, to Jave. Even if a library doesn't contain a single documentation comment, the auto-generated javadoc that contains just the class tree and method signatures is usually enough to get an idea of what's going where. In D, unless the author has provided some actual examples, you are going to have a hard time trying to sort out these complex templated signatures... That's quite an hurdle to go though when wanting to use complex code from simple code(or even from other complex code). That's the ugly seam I'm talking about. Now, if you are working on a big project(be it commercial or open-source), you can find lot's of examples how to use these complex functions, and that's probably how you'd tackle the problem. When you are using some library you usually don't have that luxury - but these libraries usually have the generated ddoc at their website. Of course - that generated ddoc is full with complex templated signatures, so that's not very helpful... So, what can be done? Maybe the ddoc
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 14:18:33 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote: distribution across the cores, but in most scenarios the number of concurrent tasks should be high enough to keep all cores busy anyhow. There are also additional costs for moving fibers (synchronization, cache misses). It is a complete disaster to not move fibers between threads if you want good latency. Only if execution time between fibers is very unevenly distributed and/or their amount is low.
Format double in decimal notation without trailing zeros after the decimal point
The task seemed very simple. But I'm stuck. I want to: 1234567890123.0 to 1234567890123 1.23 to 1.23 1.234567 to 1.2346. With format string %.4f i get 1.2300 for 1.23. With %g i get 1.23456789e+12 for 1234567890123.0. I can not believe that it is not implemented. What did I miss?
Re: Advise for syntax highlighting
Personal preferences:
* this in constructor
this () {}
In TextMate functions/methods are highlighted, should this be
highlighted as a keyword or as a method?
method
* this in copy constructor
this (this) {}
The this parameter, should that be highlighted as a keyword
or as a parameter?
keyword (because, well, it is not a parameter)
* The __ctfe variable
if (__ctfe) {}
How should this highlighted? I see a couple of alternatives:
- not at all
- as a keyword
- as a special recognized built-in symbol, similar to __LINE__
- as a special recognized library symbol. For example, in the C
bundle many of functions in the standard library are specially
recognized and highlighted differently. This might not apply
here since it's not a library symbol
not at all. The fact it is reserved is already denoted by __,
otherwise it is just another vairable/symbol.
* __traits identifiers
__traits(allMembers, Foo);
In this case allMembers. Basically the same question and
alternatives as for the __ctfe variable.
this is different from __ctfe as it is actual compiler built-in
with special semantics. special recognized built-in symbol is
probably best fit as it is not listed as keyword either.
* Predefined version identifiers
version (OSX) {}
Again, same a question and alternatives as for the __ctfe
variable.
special recognized built-in symbol
* Extern identifiers
extern (C)
Again, same a question and alternatives as for the __ctfe
variable.
special recognized built-in symbol
Re: Can we deprecate D-style Variadic Functions
What Shammah has said. Your proposal is not a proper replacement, it has very different effect on a binary. It could be possible to reimplement D-style varargs on top of C-style varargs + manual RTTI usage but not with template variadics.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
Regarding the scscscshghshshshhswarzThing, here we discuss the readability and accessibility of the documentation, not the power of the library. Every other language will use a variation of sortBy instead of the scscshwcwscThing. I'm happy that D has in the default lib functions like levenshteinDistance, but this will not attract the average or just starting to learn developer. On the contrary, sorting correctly some names is a more common task than calculating the Levenshtein distance, but there is no function for it in phobos. You may have a point that schwartzSort has a bad name (I disagree), but putting another algorithm does not make the documentation worse per se. Dunno, what problem you have with the levenshteinDistance. On the contrary, sorting correctly some names is a more common task than calculating the Levenshtein distance, but there is no function for it in phobos. What do you mean by correct? http://unicode.org/reports/tr10/? We even have something obscure like levenshteinDistance but no implementation for the unicode collation algorithm, which all newcomers are looking for! is a) a questionable comparison between a relative simple algorithm and a monster and b) wrong, because 99% of programmers don't even know about the algorithm itself, thus they aren't looking for it. BTW. python's startwith does the Köln example wrong. Kö and Ko\u0308 dont match.
Re: pureity of closures
On Fri, Mar 27, 2015 at 05:28:54PM +, Dicebot via Digitalmars-d wrote: On Friday, 27 March 2015 at 14:29:05 UTC, Shammah Chancellor wrote: On 2015-03-23 09:45:39 +, Dicebot said: I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case) Pure functions returning impure functions. *BOOM* My brain just exploded. -Shammah As long it is exactly the same impure function for given set of arguments (including the context if any) it should comply it pure requirements, shouldn't it? Makes sense to me. What I'm more concerned about is whether the current compiler implementation may accidentally allow leakage of the pure function's internal context, which would break purity. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
[Issue 14349] New: String imports with subpaths don't work on Windows
https://issues.dlang.org/show_bug.cgi?id=14349 Issue ID: 14349 Summary: String imports with subpaths don't work on Windows Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com echo pragma(msg, import(\a/b.txt\)); test.d mkdir a echo aoeu a/b.txt dmd -o- -J. test.d Works on Linux. On Windows, complains: test.d(1): Error: file a/b.txt cannot be found or not in a path specified with -J test.d(1):while evaluating pragma(msg, import(a/b.txt)) --
[Issue 14350] New: Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 Issue ID: 14350 Summary: Unit test failures are not displayed in Windows GUI programs Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com Forum thread: http://forum.dlang.org/post/laoqugqszpkkoyavg...@forum.dlang.org The unit test runner uses its own code to print the exception instead of reusing printThrowable. --
[Issue 14350] Unit test failures are not displayed in Windows GUI programs
https://issues.dlang.org/show_bug.cgi?id=14350 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/1200 --
Re: Format double in decimal notation without trailing zeros after the decimal point
On 3/27/15 11:02 AM, akaDemik wrote: The task seemed very simple. But I'm stuck. I want to: 1234567890123.0 to 1234567890123 1.23 to 1.23 1.234567 to 1.2346. With format string %.4f i get 1.2300 for 1.23. With %g i get 1.23456789e+12 for 1234567890123.0. I can not believe that it is not implemented. What did I miss? I think you are asking for trouble to do this. Floating point is not exact, so for example, if I do writefln(%.15f, 123456.789123); I get: 123456.78912295016 How far do you want to go before you determine there will only be zeros? It could be infinity. I'd say your best bet is to format to the max level you want, e.g. %.6f Then trim off any trailing zeros (and decimal point if necessary) after conversion to a string. -Steve
[Issue 14349] String imports with subpaths don't work on Windows
https://issues.dlang.org/show_bug.cgi?id=14349 bb.t...@gmx.com changed: What|Removed |Added CC||bb.t...@gmx.com --
Re: Unittests and windows application
On Thursday, 26 March 2015 at 12:11:33 UTC, Stefan wrote: On Thursday, 26 March 2015 at 10:50:06 UTC, Vladimir Panteleev wrote: On Thursday, 26 March 2015 at 10:23:58 UTC, Stefan wrote: .. That's a bug. You'll notice that if an exception is thrown in main() (or anything called from it), you'll get a MessageBox for GUI applications. That this doesn't also occur with unittest failures is a bug. Do you have the bug/issue number for that? https://issues.dlang.org/show_bug.cgi?id=14350
Re: Advise for syntax highlighting
On 2015-03-27 16:04, Dicebot wrote: not at all. The fact it is reserved is already denoted by __, otherwise it is just another vairable/symbol. Doesn't this symbol also have special semantics? -- /Jacob Carlborg
Re: Advise for syntax highlighting
On Friday, 27 March 2015 at 15:23:56 UTC, Jacob Carlborg wrote: On 2015-03-27 16:04, Dicebot wrote: not at all. The fact it is reserved is already denoted by __, otherwise it is just another vairable/symbol. Doesn't this symbol also have special semantics? A more pragmatical view would be: if(__ctf ... Was it __ctfe or __ctfe__? Easily answered if it has special highlighting.
Re: pureity of closures
On Friday, 27 March 2015 at 14:29:05 UTC, Shammah Chancellor wrote: Pure functions returning impure functions. *BOOM* My brain just exploded. -Shammah I am not sure when this would happen, but why disallow it ?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 17:06 schrieb Dicebot: On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse. Exactly, the problem will remain there, even with moving fibers around, because you might as well have the same situation in all of the threads at the same time like that. It always makes sense to have dedicated threads for lengthy computations. Apart from that, long computations can call yield() every now and then to avoid this kind of issue in the first place.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote: I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers. Nice one. I am sure your attitude is very helpful for D.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:20:28 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 16:09:08 UTC, Chris wrote: It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know. New things can be cool for a toy language, but not for a production language. The latter needs polish and support (IDE etc). Just pointed out the social dynamics where Go/D communities are not all that different. There's probably a difference between programmers that juggle 5-7 languages and programmers that stick to 1 language: «it is just A tool among many» vs «it is THE tool». I think you see this expressed in both Go and D communities. I'd say Go fans are worse in this respect (yes, I know, probably not all of them). People in the D community are here, because they have tried at least 5-7 other languages. Go programmers, if Pike's remarks are anything to go by, are probably less experienced (just left school or college) and are more susceptible to Google's propaganda. I'd say they know not better.
[Issue 9826] import doesn't work with absolute paths
https://issues.dlang.org/show_bug.cgi?id=9826 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com --- String-importing absolute paths to arbitrary files are forbidden by design, to prevent programs from capturing arbitrary files from the filesystem during compilation. The bug is that the compiler should realize that the absolute path, in fact, points to a file that is under the allowed string import path (-J.). --
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 27.03.2015 um 17:31 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote: So what happens if 10 requests come in at the same time? Does moving things around still help you? No. Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests. You could say the same for the non-moving case. If you have a fully loaded node and mix request handling and lengthy computations like this, you'll run into this no matter what. The simple solution is to just either separate lengthy computations (easy) or to split them up into shorter parts using yield() (usually easy, too). Caching *may* make it unlikely, but that completely depends on the application. If you have some kind of server-side image processing web service with many concurrent users, you'd have a lot of computation heavy requests with no opportunities for caching. BTW, why would an event driven design be any better? You'd have exactly the same issue. 1. No stack. That reduces the memory footprint, but doesn't reduce latency. 2. Batching. Can you elaborate? But it is more tedious.
Re: GtkD 3.1.0 released, GTK+ with D.
On Thursday, 26 March 2015 at 22:41:01 UTC, Mike Wey wrote: Shortly after the last release, GtkD has been updated for GTK+ 3.16. Thank you, that's awesome :) Can't wait for my distro to get updated to start playing with this.
Re: Why dont dlang check NullPointer?
I'd be tempted to go way back to the very root of the problem starting with Tony Hoare again. Eliminate null as a possibility. That's a whole other subject, though.
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #21 from github-bugzi...@puremagic.com --- Commit pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9edd2223950b919a201cf104601f877283cca2bf Merge pull request #4458 from mihails-strasuns-sociomantic/redundant-attrib-deprec [REG] fix Issue 14232 : redundant attribute 'const' --
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Thursday, 26 March 2015 at 19:45:19 UTC, Alex Parrill wrote: On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: ...snip... So tl;dr; make the template constraints in ddoc less prominent? The new library reference preview under Resources seems to already have this (example: http://dlang.org/library/std/algorithm/searching/starts_with.html) https://w0rp.com/project/dstruct/dstruct/weak_reference/ I've got a Toggle Contraints button on my site for showing and hiding them dynamically. It kind of works.
Re: pureity of closures
On Friday, 27 March 2015 at 14:29:05 UTC, Shammah Chancellor wrote: On 2015-03-23 09:45:39 +, Dicebot said: I think this was not intended and is simply a side effect of limited D call graph analysis. Relaxing that limitation makes sense to me because unused impure function can be used for compile-time reflection or returned from pure function as a result (you need to ensure it does not capture pure functions as closure context in that case) Pure functions returning impure functions. *BOOM* My brain just exploded. -Shammah As long it is exactly the same impure function for given set of arguments (including the context if any) it should comply it pure requirements, shouldn't it?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:40:14 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 16:27:48 UTC, Dicebot wrote: I have no interest in arguing with you, just calling out especially harmful lies that may mislead random readers. Nice one. I am sure your attitude is very helpful for D. Actually, it really is. He does a lot of useful work that has helped improve many parts of D and it's ecosystem. Mostly I see you sniping from the sidelines with in-actionable comments; not because you're necessarily wrong, but because despite what appears to be a significant body of knowledge, your arguments lack detail and are often supported by a bunch of academic knowledge that - at best - you refer to in overly general terms. Sorry if that sounds harsh, but it's frustrating seeing you throw knowledge at topics without making any of it stick.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Friday, 27 March 2015 at 14:39:48 UTC, Tobias Pankrath wrote: Looked also in the source code to find out that startsWith is locale sensitive, something ignored in phobos. Why would I need a locale for startsWith? Please file a bug, if that's actually needed for unicode strings. Because in German, Köln can start with Kö, but also with Koe and K\u0308o ? Regarding the scscscshghshshshhswarzThing, here we discuss the readability and accessibility of the documentation, not the power of the library. Every other language will use a variation of sortBy instead of the scscshwcwscThing. I'm happy that D has in the default lib functions like levenshteinDistance, but this will not attract the average or just starting to learn developer. On the contrary, sorting correctly some names is a more common task than calculating the Levenshtein distance, but there is no function for it in phobos.
Re: dfmt options
On 2015-03-14 23:15:34 +, Brian Schott said: First, a disclaimer: I am an idiot for starting this thread. Moving on... I'm working on a list of configuration options for dfmt - a formatter for D source code. So far I have the following: * Insert spaces between if, while, for, foreach, etc loops and the ( * Allman vs One True Brace Style (Already supported by commant-line switch) * Operators at the end of the old line vs beginning of the new line when wrapping long expressions. * Insert space after the ) of a cast expression * Make case and default match the indent level of the enclosing switch * Labels for loops always on their own line vs the same line as the loop * Labels outdented one level * Label indentation matches the most recent switch * Hard limit for line length * Soft limit for line length What am I missing? A way to configure this and have it look for the most relevant `.dfmtcfg` file! :) That is to say, make it look up from the current directory recursively until it finds a config file, and use that.This will greatly help people who are contributing to the same project keep a consistent format. Also, Hard and soft limit for line length causes an exception to be thrown when I tried it. -Shammah
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 16:18:33 UTC, Sönke Ludwig wrote: So what happens if 10 requests come in at the same time? Does moving things around still help you? No. Load balancing is probabilistic in nature. Caching also makes it unlikely that you get 10 successive high computation requests. BTW, why would an event driven design be any better? You'd have exactly the same issue. 1. No stack. 2. Batching. But it is more tedious.
[Issue 14343] Postfix increment doesn't work on structs with immutable member
https://issues.dlang.org/show_bug.cgi?id=14343 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86 |All --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4522 --
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 15:28:31 UTC, Ola Fosheim Grøstad wrote: No... E.g.: On the same thread: 1. fiber A receives request and queries DB (async) 2. fiber B computes for 1 second 3. fiber A sends response. Latency: 1 second even if all the other threads are free. This is a problem of having blocking 1 second computation in same fiber pool as request handlers - broken application design. Hiding that issue by moving fibers between threads is just making things worse.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 15:54:31 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 12:48:04 UTC, Dejan Lekic wrote: My personal opinion about the article - people may hate D equally for being too pragmatic. That Yeah, well, both the D/Go communities use the term pragmatic to gloss over underwhelming design issues in D/Go, and makes a point of how D/Go is deliberately not being a research language, yet still claim that D/Go bring novel features... although neither D or Go bring anything new to the table. I.e.just about all the major concepts in D/Go are 30-50 years old... It need not be new, it needs to be good. That's all. I don't understand this obsession people have with new things, as if they were automatically good only because they are new. Why not try square wheels? Uh, it's new, you know. It is mostly a case of inexperienced programmers not knowing PL history becoming fanbois of new languages. Kind of like the OS wars of the 1990s.
