Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 7/11/14, 2:14 PM, Jacob Carlborg wrote: On 2014-07-10 20:27, Andrei Alexandrescu wrote: https://twitter.com/D_Programming/status/487301149645873152 https://www.facebook.com/dlang.org/posts/882371471776535 https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/2acqfq/dconf_2014_day_2_talk_5_tooling_bringing/ Why don't you upload to youtube directly? archive.org preserves the original format and resolution and isn't fussy about file size. -- Andrei
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On Saturday, 12 July 2014 at 08:54:29 UTC, Andrei Alexandrescu wrote: On 7/11/14, 2:14 PM, Jacob Carlborg wrote: On 2014-07-10 20:27, Andrei Alexandrescu wrote: https://twitter.com/D_Programming/status/487301149645873152 https://www.facebook.com/dlang.org/posts/882371471776535 https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/2acqfq/dconf_2014_day_2_talk_5_tooling_bringing/ Why don't you upload to youtube directly? archive.org preserves the original format and resolution and isn't fussy about file size. -- Andrei Those who have trouble with archive.org being very slow: lftp -e 'pget -n 30 file URL goes here' for very significant speedups. I'm sure other parallel downloaders will give similar results.
Dakka: Actors for D
Alright so, I've just finished Dakka's[0] exception support. Functionality supported: Local actor references Remote node connections, using given ip/port Remote actor calling On start/stop/error support Capabilities per node (can this node do x? if not which can do to create a reference?) Seemless integration of both actor references to actors Singleton (controller classes) actor support per node, works with AllActorRefs for calling them e.g. sequentially, or until a return value. At this point, I'm entering it into maintenance. What this means is I cannot myself expand on its functionality e.g. adding encryption. However if anybody wants to, please do. This is what I need, I've tried to make it as flexible as possible and inline with how akka works, but as I'm not the most adapt in it. Please feel free on drawing up a wanted feature list. There will be issues with threading, so if anyone is more skilled at it and understands Vibe's workers feel free pointing that out. For anybody interested, the code itself isn't well documented (I'll get back to it when I have time). But the actual overall design should be fairly documented. The protocol[2] and life cycle[3] can be found on the wiki[1]. [0] https://github.com/rikkimax/dakka [1] https://github.com/rikkimax/dakka/wiki [2] https://github.com/rikkimax/dakka/wiki/Protocol [3] https://github.com/rikkimax/dakka/wiki/LifeCycleOfObjects
Re: DMD v2.066.0-b3
On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David There is 1027 issues here... We can't even clear a list of 10 issues, what makes you think we can clear this list before the next release? On second thought this is a list of all issues ever marked as regressions. This might be what you intended: https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=47252query_format=advanced
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 2014-07-12 10:54, Andrei Alexandrescu wrote: archive.org preserves the original format and resolution and isn't fussy about file size. -- Andrei I'm not sure what problems you're having but youtube supports resolutions up to 4k and there are many files on youtube that are larger than the ones you're uploading. On the other hand, I have never upload anything to youtube so I don't know the restrictions it has. -- /Jacob Carlborg
Re: DMD v2.066.0-b3
On 2014-07-12 15:21, AfroboyX wrote: There is 1027 issues here... We can't even clear a list of 10 issues, what makes you think we can clear this list before the next release? The last three dashes of the URL is part of the link as well but is apparently not recognized as part of the link. If you add the three dashes you can see it's only 9 issues, the ones that are open. -- /Jacob Carlborg
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 7/12/14, 7:09 AM, Jacob Carlborg wrote: On 2014-07-12 10:54, Andrei Alexandrescu wrote: archive.org preserves the original format and resolution and isn't fussy about file size. -- Andrei I'm not sure what problems you're having but youtube supports resolutions up to 4k and there are many files on youtube that are larger than the ones you're uploading. On the other hand, I have never upload anything to youtube so I don't know the restrictions it has. I have experimented extensively last year, and archive.org was the best by far. Back then youtube would reduce the resolution and had video length restrictions. It's possible they were relaxed or lifted, but I'm not inclined to put time into researching that again. For my money archive.org works very well and I'm glad Dicebot is uploading to youtube as well. Andrei
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On Saturday, 12 July 2014 at 20:33:24 UTC, Andrei Alexandrescu wrote: On 7/12/14, 7:09 AM, Jacob Carlborg wrote: On 2014-07-12 10:54, Andrei Alexandrescu wrote: archive.org preserves the original format and resolution and isn't fussy about file size. -- Andrei I'm not sure what problems you're having but youtube supports resolutions up to 4k and there are many files on youtube that are larger than the ones you're uploading. On the other hand, I have never upload anything to youtube so I don't know the restrictions it has. I have experimented extensively last year, and archive.org was the best by far. Back then youtube would reduce the resolution and had video length restrictions. It's possible they were relaxed or lifted, but I'm not inclined to put time into researching that again. For my money archive.org works very well and I'm glad Dicebot is uploading to youtube as well. Andrei Even bearing in mind that archive.org is so slow that a simple download of the mp4 version of a talk can talk almost 2 hours? archive.org's per-connection bandwidth limit is very unusually low.
Re: DMD v2.066.0-b3
On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing what's important to them. You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it?
Re: DMD v2.066.0-b3
On 7/12/14, 4:31 PM, Andrew Edwards via Digitalmars-d-announce wrote: On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing what's important to them. You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it? An important topic, certainly. But not for the announce newsgroup. Please continue this over on the beta list.
Re: Using D
On 07/11/2014 09:53 AM, simendsjo wrote: On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: […] A little anecdote.. I once got a 20% speed increase in Python by moving a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here i = something This is interesting. I can believe there is some performance benefit, but I am not sure I believe 20% improvement. If you can send me the code you were using, I would like to do some benchmarking on this. Yes, I was very perplexed when I was profiling and finally found the main offender. Unfortunately I don't have the code - it was a project done for a past employer back in 2006/2007 (Python 2.4 IIRC). The compiler wasn't smart enough to do this. The Python compiler cannot and will never be able to do any such thing. Indeed if it did any such thing, it would be an error since it significantly changes the semantics of the program. Thus not doing this is not the fault of the compiler. The fact that you were able to do this and it appeared to give you the same results just means that the change in program semantics did not affect your computation. Which is good, but not something the compiler could determine. I think of this as a fault in the compiler. It was quite obvious (to me) that nothing else relied on the value so the value didn't have to be created on each iteration. Can that 'i = something' expression be monkey-patched in Python? If so, it could have side-effects to make the program change semantics like Russel Winder means. Ali
Re: Using D
Ali Çehreli: Can that 'i = something' expression be monkey-patched in Python? If so, it could have side-effects to make the program change semantics like Russel Winder means. Right. And even PyPy isn't a compiler. Python is interpreted. And at best JITted. In most cases you use Cpython, that is an interpreter. And in Python most optimizations are dangerous, because the language is very dynamic. If you look for performance it's better for you to look elsewhere (like Julia). Bye, bearophile
Re: Older versions of dmd
On Friday, 11 July 2014 at 17:44:29 UTC, Frustrated wrote: So why isn't there a link to previous versions of dmd? I have a regression I need to test out but can't find 2.064! There's a perfect tool for that called DVM [1]. It's a cross-platform tool that allows you to install any version of DMD, old or new. It supports having multiple compilers installed and easily switch between them. You can have one terminal window with one version of the compiler and in another window you have a different version of the compiler. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Re: Using D
On Friday, 11 July 2014 at 19:08:43 UTC, Nick Sabalausky wrote: Yea, that's one of the things that drew me to D. It came around saying (quite literally) pragmatic language design at exactly the time I was noticing how much of a pain ideology-driven and minimalist languages can be. +1000 --- Paolo
Re: API: string formatting / memory management
Am Fri, 11 Jul 2014 21:14:36 + schrieb Robert burner Schadek rburn...@gmail.com: On Friday, 11 July 2014 at 15:20:51 UTC, Johannes Pfau wrote: An logger can still receive the complete string by appending the chunks received in put but we might need some 'finish' function to signal the end of the message. I guess not all loggers can fit into this interface, so we should try to make this optional. But simple loggers (file, console) which write the header first and the message last could work without any dynamic memory allocation. (formattedWrite probably uses an fixed-size buffer on the stack, but that's fine) The api for none printf like logging has changed into something like write. So put properly needs to become a template. Any I'm not sure if there is a nice way around the template/inheritance problematic. Other than options one and two. Last time we discussed this I also thought we'd need to make put a template. But we overlooked the obvious solution: Type-string formatting stays part of the 'frontend' functions. We only pass strings to the backend. But instead of insisting that message is one string, we allow to pass the msg as many strings. This means that formatting can go in a fixed size stack buffer and still support arbitrary length strings. Here's a pull request to implement this idea: https://github.com/burner/logger/pull/9
Re: Review: std.logger
Am Fri, 11 Jul 2014 21:26:25 +
schrieb Robert burner Schadek rburn...@gmail.com:
On Friday, 11 July 2014 at 18:02:58 UTC, Marc Schütz wrote:
Some logging backends (e.g. systemd journal) support structured
logging. Should support for this be included (as a subclass,
presumably)?
Well, the idea behind std.logger is that I can not and should not
even try to give you implementations for all your backend needs.
It will just fall short and you will tell me that is it bad and
should not go into phobos. And even if I manage it is going to be
curl all over again.
So subclass Logger, implement writeLogMsg to your needs and be
happy.
Yes, but for structured loggers the frontend log* functions do not
provide enough information to the backend. Of course you can use the
systemd journal as a normal backend, but you lose features.
I think we can provide structured logging support as a non-breaking API
extension, so we should not make this part of this review. But here's
how I'd imagine such an API to work:
Frontend:
* log* get new overloads which accept (T...) as the last parameter (or
if T... is already the last parameter that's fine).
* Add a new struct to logger.core: struct MsgID which is just a
strong typedef for UUID
* Add a templated type, KeyValue, which can be used like this:
KeyValue(user, nobody) //string key / string value
KeyValue(age, 42); //string key / T value
KeyValue(msg, Hello %s! %s, World, 42); //string key/fmt val
* KeyValue stores it's parameters, no string processing yet
* Multivalue parameters handled by many KeyValue with same key? Might
complicate backend. Or don't support multivalue at all? Or
KeyValue(key, MultiValue(a, ,b, c)) (MultiValue == Tuple?)
* Structured loggers do not use msg, instead they use a KeyValue with
msg key. This is cause you usually want different messages with
structured loggers. We still keep everything in one function, so the
user doesn't have to do if(structuredlogger) logstruct() else log()
for every log message.
* MsgID marks the end of normal format parameters. See example below.
This is also the reason why we can't use UUID directly
Usage:
string error;
logf(Something bad happened: %s, error,
MsgID(abcd-valid-uuid), //MsgID-- end of fmt params
KeyValue(msg, Something bad happend),
KeyValue(error-code, error));
output:
normal backend: test.d:42 Something bad happened: out of memory
structured backend: (only example, exact format backend specific)
{
msg: Something bad happened,
error: out of memory,
file: test.d,
line: 42
}
The next part is an efficient Backend Layer:
class StructuredLogger : Logger
{
logHeader;
writeLogMsg; //Not used
finishLogMsg;
void logKey(string key);
void valuePart(const(char)[] part);
void finishValue(bool last); //Last only if we support multivalue
}
Usage:
auto slog = new StructuredLogger();
slog.logHeader(...);
foreach(KeyValue kv; T...)
{
slog.logKey(kv.key);
//Need slog - outputrange adapter: map putvaluePart
//see https://github.com/burner/logger/pull/9
formattedWrite(wrap(slog), kv.formatstring, kv.args);
slog.finishValue(true);
}
finishLogMsg();
Re: Using D
On Fri, 2014-07-11 at 20:25 +, Joakim via Digitalmars-d wrote: […] Name one general purpose language that currently crosses the native-scripting divide and has good usage on both ends of the market. It doesn't exist, because it's almost impossible to do. […] Go and D are really quite close to something useful though on this front. -- 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: @nogc
W dniu 2014-07-11 05:18, Kapps pisze: On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote: So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow @nogc' function: assert(false, Message ~ details); It complains Error: cannot use operator ~ in @nogc function I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts? More generally, I'm somewhat surprised that @nogc does not still allow allocating Errors (including with assert), as who cares if your program may slightly pause when it's about to crash in a theoretically unrecoverable way. It does matter when entire program is marked with @nogc, so there may be no GC code at all (GC code may not be linked).
Re: Using D
On Fri, 2014-07-11 at 18:53 +0200, simendsjo via Digitalmars-d wrote: […] Yes, I was very perplexed when I was profiling and finally found the main offender. Unfortunately I don't have the code - it was a project done for a past employer back in 2006/2007 (Python 2.4 IIRC). Ah. In which case the anecdote is only of historical interest since it says nothing about Python as it is today. 2.7 is way faster than 2.4 and has far more in it that would like make the code in need of a amendment anyway – also the way local variables are stored and manipulated has been changed and improved massively over the intervening time. Moreover 3.4 is way, way better than 2.7 and has so much more in it that a rewrite would definitely be needed if performance was a factor. Without the code though there is no data point, so nothing to pursue. Sadly. […] I think of this as a fault in the compiler. It was quite obvious (to me) that nothing else relied on the value so the value didn't have to be created on each iteration. A new variable was not being created on each iteration. Python does not have block scoping. This cannot be seen as a fault with the compiler since all the compiler does is to check syntax and indents and convert your source code into bytecodes. The compiler does not and must not do any form of amending the abstract syntax tree (AST). Manipulations of the AST must be in the source code, cf. MacroPy. -- 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: Lexical, Syntatic and Semantic Merge of D Source Code
On Friday, 11 July 2014 at 13:58:53 UTC, Nordlöw wrote: Now that we have reasonable support for lexing and parsing D in D through Dscanner/libdparse/DCD I believe it would be worth the effort to try to implement D-specific merge algorithms that operate on either the - D token stream or - a D parse tree possibly making use of semantic information. This would also require functions that write them back to the original source representation, of course preserving whitespace indentations. A token-based merger would be quite easy to implement and will resolve conflicts where multiple symbol renamings have occurred on the same line. Something that current mainstream line-based algorithms cannot handle. This could be useful when test-merging Git branches on Github. It also could be that these algorithms will have things in common with DustMite's algorithms. What do you say, Cybershadow? I could help implementing these ideas when necessary. Have perhaps anybody already cooked up some D implementations of generic diff/merge algorithms? If not could anybody point out a good reference implementation in C/C++ to start with? It's a good idea, something I've thought would be nice before, and a first step towards the Dfix concept Andrei has endorsed: http://forum.dlang.org/thread/sggntfmffiicpymov...@forum.dlang.org?page=2#post-ughxvktaonclzddyicve:40forum.dlang.org
Re: Using D
On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] I remember Java used to be th best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done once you take a language out of the hands of a committee. Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal propaganda. I think we ought to distinguish good marketing from hype. Java had good marketing, was in the right place at the right time, and had a huge amount of hype as well. If Go is better for server things than D then might as well stop trying to use D at all. Go was actually designed as a better C with CSP for concurrency and parallelism. Go, D, Rust, C++, C, Haskell,… are all just programming languages that create native code executable. Thus they are all in the same category regarding potential usage. Everything else is about whether the programmer likes and uses well, the language. If Go and Java are closed languages, so is D. All three have open source repositories and people can submit changes via pull requests. All three have committees comprising the people who have commit rights to the mainline and they are the only people who can actually change the language. I think I have to repeat the point about irony here regarding ideology :-) What I'm taking issue with is that everybody focuses on the flaws of D (every language has flaws), which often gives the impression that it's an unfinished, stay-away business. It's not. D can be used, and I've used it, for production code. It's more mature than D or Rust and it is superior to other languages like Java (no OO-ideology for example). Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. Talking about hindsight, I've tried many different languages, I like D because of what it has to offer for general purpose programming, it compiles natively, interfaces with C at no cost at all, it has strong modelling power, features that users require are added. I may sound like a zealot (see irony), but I'm not. I'm very pragmatic, D is a good tool and, being community driven, there is a real chance of making it a fantastic tool. Individual features are not everything. Go folk have exactly the same view and argument regarding Go. Java folk have exactly the same view and argument regarding Java – well except for the compiles to native code bit, obviously. ;-) In the end it is about community rather than the programming language per se. Java created a huge community that was evangelical. Go has rapidly created an active community that is evangelical. Python has rapidly created a large evangelical community. D has slowly created a small community that hasn't as yet created the outward looking evangelical aspect. Where are the user groups having local meetings is my main metric. Java definitely, Go definitely, C++ sort of, D no. This is the real problem for D I feel. Without local user groups meeting up you don't get exposure and you don't get traction in the market. If there were more D users in the London area than one in London and one in Brighton maybe we could start a London D User Group (LonDUG). SkillsMatter would host. -- 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: Using D
On Fri, 2014-07-11 at 10:40 -0700, H. S. Teoh via Digitalmars-d wrote:
[…]
When I finally got past the hype and tried out the language for myself,
I found the same thing you did: it's totally straitjacketed, and shoves
the OO idealogy down your throat even when it obviously doesn't fit. The
infamous long-winded class MyLousyApp { public static void main(blah
blah blah) ... } is a prime example of shoehorning something obviously
non-OO into an OO paradigm, just because we want to. Not to mention
Java's verbosity, which is only tolerable with IDE support -- total
fail, in my book. I mean, hello, we're talking about a *language*
intended for *humans* to communicate with the computer? If we need
*another* program to help us elucidate this communication, something's
gone very, very wrong with the language. A language that needs a machine
to help you write, is by definition a language for communication between
*machines*, not between humans and machines.
Java is not an object-oriented language in the Smalltalk, C++, Python
sense of object-oriented.
Picking out the main entry boilerplate is a wee bit unfair. Though
Groovy, Kotlin and Ceylon have added top-level functions again by
finding compilation strategies, and Scala has created the App class
which does something similar.
You comment about programming languages applies equally well to C++, Go,
Python, Rust, D, etc. as it does to Java.
Then there's the lack of generics until the n'th revision, and when it
finally came, it was lackluster (google for issues caused by type
erasure in Java sometime). D totally beats Java in this area IMO.
I think it may just be Stockholm Syndrome, but some notable people whose
opinions I generally trust, are now saying that type erasure in Java is
a good thing. I am not one of them. Java should have done what C# did
and enforce reification of type parameters in the underlying machine,
JVM and CLR respectively.
That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life. Well, except with the help
of automated tools like IDEs and what-not, which makes one wonder, if we
need a machine to help us communicate with a machine, why not just write
assembly language instead? But I digress. :-P
Now this is mis-direction. Java is a real-world language in that it is
used in the real world. Whilst there are many using Java because they
know no better, many are using it out of choice. Java evolves with the
needs of the users prepared to get involved in evolving the language.
--
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: @nogc
On Saturday, 12 July 2014 at 09:44:16 UTC, Piotr Szturman wrote: W dniu 2014-07-11 05:18, Kapps pisze: On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote: So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow @nogc' function: assert(false, Message ~ details); It complains Error: cannot use operator ~ in @nogc function I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts? More generally, I'm somewhat surprised that @nogc does not still allow allocating Errors (including with assert), as who cares if your program may slightly pause when it's about to crash in a theoretically unrecoverable way. It does matter when entire program is marked with @nogc, so there may be no GC code at all (GC code may not be linked). Well, it wouldn't even link then... But I think the more common route to go in such a case is to make a stubbed out GC that provides only allocation functionality (e.g. forwarding to malloc/free), but doesn't do any garbage collection. After all, some kind of memory allocation needs to present in almost all cases, it's just that it's done manually.
Re: Review: std.logger
On Saturday, 12 July 2014 at 03:22:10 UTC, Jesse Phillips wrote: On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote: On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David I'm of the opinion we should review for std.* and vote for std.experimental.* Prior to or during beta we vote to move into std.* Agreed.
Re: Any interest in detailed GC traces
On Saturday, 12 July 2014 at 03:54:59 UTC, safety0ff wrote: I found this link on reddit: http://dave.cheney.net/2014/07/11/visualising-the-go-garbage-collector and I was wondering if there was interest in having D's GC output detailed trace information. I was thinking perhaps collecting data and then writing it as a json file when the process exits. Thoughts? Would definitely like this. I even think something like this should be built in. (now if possible, it'd also be good to have a way to get Massif-like stats (i.e. which line has allocated how much at which moment), but that might take some work)
Re: Review: std.logger
Am Fri, 11 Jul 2014 14:36:30 + schrieb Dicebot pub...@dicebot.lv: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Code: https://github.com/D-Programming-Language/phobos/pull/1500 Documentation: Overall design API looks good. Some detail comments and / or questions: logger.core: * For some people the EBNF might be useful, but it looks kinda scary to me if I open the documentation ;-) * The docs do not mention thread safety at all. Can I change the default logger while other threads are logging? * The docs should clearly mention the default logger (this is kinda mentioned, but I'd make it more explicit) and the default loglevel. * Can the logger be influenced by command line flags / environment variables? I guess not, but if it can it should be documented. * I think an example how to change the default logger should be at the top of the module. (I think it's quite common people would want to log to files as well) * Why does LogManager.defaultLogger return by ref instead of just using a setter? * The logger.core documentation should have an overview of available logger types and link to them. Probably a table with Logger | module | Description StdIOLogger | std.logger.stdiologger | log to standard output(console) logger.multilogger: * Should mention thread safety. If other threads log to the multilogger can I simply add/remove loggers?
import from Internet
Could you support importing from Internet feature? I think that'll be very convenient. import http://example.com/MyLibrary.d;;
Re: import from Internet
On Saturday, 12 July 2014 at 12:24:19 UTC, Katayama Hirofumi MZ wrote: Could you support importing from Internet feature? I think that'll be very convenient. import http://example.com/MyLibrary.d;; dub : code.dlang.org
Re: Using D
On 12 July 2014 11:27, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] I remember Java used to be th best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done once you take a language out of the hands of a committee. Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal propaganda. I think we ought to distinguish good marketing from hype. Java had good marketing, was in the right place at the right time, and had a huge amount of hype as well. If Go is better for server things than D then might as well stop trying to use D at all. Go was actually designed as a better C with CSP for concurrency and parallelism. Or a better Oberon, I haven't quite decided which yet... :) If there were more D users in the London area than one in London and one in Brighton maybe we could start a London D User Group (LonDUG). SkillsMatter would host. And I say Hello! from sunny Brighton. I do believe there are a few people around the London area who either have worked in, work in, or have a vested interest in D. I'll give Dejan a poke and find out some more numbers. Regards Iain.
Re: import from Internet
dub : code.dlang.org OK, I'll move to there.
Re: Review: std.logger
On Saturday, 12 July 2014 at 09:19:47 UTC, Johannes Pfau wrote: I think we can provide structured logging support as a non-breaking API extension, so we should not make this part of this review. But here's how I'd imagine such an API to work: I look at the journald spec and LoggerPayload already contains most of the key value pairs. MSG_ID seams to be the last important one missing inside LoggerPayload. Thank you for taking the time to create a PR put, IMO that approach is to complicated. Anyway, if there are performance problems down the road this will be the first approach to try.
Re: import from Internet
On Saturday, 12 July 2014 at 13:10:09 UTC, Katayama Hirofumi MZ wrote: https://github.com/D-Programming-Language/dub/issues/373 What I have meant is that importing from internet functionality is currently provided by dub packages and does not belong to compiler. URL imports in your proposed form are absolutely horrible.
Re: import from Internet
https://github.com/D-Programming-Language/dub/issues/373
Re: Review: std.logger
On Saturday, 12 July 2014 at 12:19:03 UTC, Johannes Pfau wrote: Am Fri, 11 Jul 2014 14:36:30 + schrieb Dicebot pub...@dicebot.lv: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Code: https://github.com/D-Programming-Language/phobos/pull/1500 Documentation: Overall design API looks good. Some detail comments and / or questions: logger.core: * For some people the EBNF might be useful, but it looks kinda scary to me if I open the documentation ;-) I know, I will make it less scary. * The docs do not mention thread safety at all. Can I change the default logger while other threads are logging? That is already on my todo list. * The docs should clearly mention the default logger (this is kinda mentioned, but I'd make it more explicit) and the default loglevel. ok * Can the logger be influenced by command line flags / environment variables? I guess not, but if it can it should be documented. I thought not writing about it makes it clear that you can not. * I think an example how to change the default logger should be at the top of the module. (I think it's quite common people would want to log to files as well) Will do * Why does LogManager.defaultLogger return by ref instead of just using a setter? Because I use the defaultLogger at quite a lot of places and treating it as an property just felt right. * The logger.core documentation should have an overview of available logger types and link to them. Probably a table with Logger | module | Description StdIOLogger | std.logger.stdiologger | log to standard output(console) Will do logger.multilogger: * Should mention thread safety. If other threads log to the multilogger I know, threads can I simply add/remove loggers? yes: new WhatEverLoggerYouWant(some_good_name, LogLevel.);
Re: Any interest in detailed GC traces
On Saturday, 12 July 2014 at 11:06:10 UTC, Kiith-Sa wrote: Would definitely like this. I even think something like this should be built in. Sadly, I think this feature would require recompiling druntime because of overhead. (now if possible, it'd also be good to have a way to get Massif-like stats (i.e. which line has allocated how much at which moment), but that might take some work) Massif's functionality can come in handy. Though, I'm not interested in implementing it.
Re: import from Internet
On Sat, 2014-07-12 at 13:13 +, Dicebot via Digitalmars-d wrote: On Saturday, 12 July 2014 at 13:10:09 UTC, Katayama Hirofumi MZ wrote: https://github.com/D-Programming-Language/dub/issues/373 What I have meant is that importing from internet functionality is currently provided by dub packages and does not belong to compiler. URL imports in your proposed form are absolutely horrible. It's an idea Go has picked up. The URL must refer to a Git, Bazaar, Mercurial repository. The repository is clone locally so that the actual build is local. To be honest it works quite well. -- 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: import from Internet
Am 12.07.2014 15:47, schrieb Russel Winder via Digitalmars-d: On Sat, 2014-07-12 at 13:13 +, Dicebot via Digitalmars-d wrote: On Saturday, 12 July 2014 at 13:10:09 UTC, Katayama Hirofumi MZ wrote: https://github.com/D-Programming-Language/dub/issues/373 What I have meant is that importing from internet functionality is currently provided by dub packages and does not belong to compiler. URL imports in your proposed form are absolutely horrible. It's an idea Go has picked up. The URL must refer to a Git, Bazaar, Mercurial repository. The repository is clone locally so that the actual build is local. To be honest it works quite well. Except when: - one needs proper versions - binary only dependencies. - not everyone uses git, mercurial I still don't see Go moving into the enterprise until these issues are sorted out. The approach taken by Dub is much better. -- Paulo
Re: Using D
Am 12.07.2014 14:54, schrieb Iain Buclaw via Digitalmars-d: On 12 July 2014 11:27, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Fri, 2014-07-11 at 16:54 +, Chris via Digitalmars-d wrote: […] I remember Java used to be th best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done once you take a language out of the hands of a committee. Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. People believed the FORTRAN propaganda, the COBOL propaganda, the Pascal propaganda. I think we ought to distinguish good marketing from hype. Java had good marketing, was in the right place at the right time, and had a huge amount of hype as well. If Go is better for server things than D then might as well stop trying to use D at all. Go was actually designed as a better C with CSP for concurrency and parallelism. Or a better Oberon, I haven't quite decided which yet... :) No, Oberon is still better. Active Oberon has concurrency support via active objects and contrary to Go, has first class support for systems programming. Oh and the last versions even had a primitive version of generics. Only thing I dislike in Wirth's languages is the need of uppercase keywords, but all modern editors can do a replace as you type kind of thing anyway. -- Paulo
Re: Go vs. D vs Java 8
On Thu, 2014-07-10 at 11:29 -0700, H. S. Teoh via Digitalmars-d wrote: On Thu, Jul 10, 2014 at 07:17:39PM +0100, Russel Winder via Digitalmars-d wrote: On Mon, 2014-07-07 at 15:47 +, Meta via Digitalmars-d wrote: On Monday, 7 July 2014 at 15:33:06 UTC, bearophile wrote: If you write it like java, it looks like java. This sentence struck me as very zen for some reason. Does this mean it is time for The Zen of D or Zen and the Art of D Programming? [...] That was zen; this is tao. :P Very Sifu Anthony Korahais -- 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: Review: std.logger
Am Sat, 12 Jul 2014 13:09:37 + schrieb Robert burner Schadek rburn...@gmail.com: On Saturday, 12 July 2014 at 09:19:47 UTC, Johannes Pfau wrote: I think we can provide structured logging support as a non-breaking API extension, so we should not make this part of this review. But here's how I'd imagine such an API to work: I look at the journald spec and LoggerPayload already contains most of the key value pairs. MSG_ID seams to be the last important one missing inside LoggerPayload. Thank you for taking the time to create a PR put, IMO that approach is to complicated. Anyway, if there are performance problems down the road this will be the first approach to try. The whole point of journald is that the user can define arbitrary key/value pairs. you're not limited to the special key/value pairs. http://0pointer.de/blog/projects/journal-submit.html Also giving log messages uuids is an important property of structured logging.
Re: Review: std.logger
Am Sat, 12 Jul 2014 13:18:29 +
schrieb Robert burner Schadek rburn...@gmail.com:
* Can the logger be influenced by command line flags /
environment
variables? I guess not, but if it can it should be documented.
I thought not writing about it makes it clear that you can not.
Yes, the documentation is OK in that regard, that was more a question
than a criticism about the docs ;-)
* Why does LogManager.defaultLogger return by ref instead of
just using
a setter?
Because I use the defaultLogger at quite a lot of places and
treating it as an property just felt right.
Yes, it's perfectly fine as a property. But why not:
static @property @trusted Logger defaultLogger() //getter
{
return ...;
}
static @property @trusted void defaultLogger(Logger value) //setter
{
myLogger = value;
}
Usage of the property is exactly the same, but an explicit setter is
more powerful and afaik we usually use explicit setters.
Re: import from Internet
I agree. Go approach my seem tempting in its simplicity but it scales terribly. It is one of less wise decisions made by Go authors.
Re: Using D
On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote: […] Or a better Oberon, I haven't quite decided which yet... :) Whatever the reality initially, it is definitely now marketed as a modernized C. Echoes of C++ then. If there were more D users in the London area than one in London and one in Brighton maybe we could start a London D User Group (LonDUG). SkillsMatter would host. And I say Hello! from sunny Brighton. Aha the Brighton dwelling D user of note ;-) I have lived in Brighton, but it was a long time ago, it is probably very different now. No West Pier for a start! I do believe there are a few people around the London area who either have worked in, work in, or have a vested interest in D. I'll give Dejan a poke and find out some more numbers. We could start a code dojo to build up an initial activity and then spawn off public meetings with tutorial style material to attract people new to D. D for C++ programmers, D for C programmers, D for Python programmers, D for JavaScript kiddies,… We might initially draw on the ACCU London people to gauge interest. -- 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: Any interest in detailed GC traces
On 12.07.2014 05:54, safety0ff wrote: I found this link on reddit: http://dave.cheney.net/2014/07/11/visualising-the-go-garbage-collector and I was wondering if there was interest in having D's GC output detailed trace information. I was thinking perhaps collecting data and then writing it as a json file when the process exits. Thoughts? Being able to visualize GC behaviour can be very helpful in analyzing what's going on during the execution of a program. When developing the precise GC presented at last years conference, I added a simple version of this by adding a hook that is called during collections. It wrote some GC info to a file for plotting the memory usage diagrams.
Re: import from Internet
On Sat, 2014-07-12 at 15:52 +0200, Paulo Pinto via Digitalmars-d wrote: […] Except when: - one needs proper versions Clearly just using DVCS repositories is a versioning problem, though the Go system does not automatically update clones so you are in total control of updating. Recognizing the problem of API versions versus repository versions, Gustavo Niemeyer created the repository gopkg.in with a full version naming system allowing people to version by API number. Seems to work very well. - binary only dependencies. Go is a source code oriented culture like Python. - not everyone uses git, mercurial There is always Bazaar or Subversion. I think there might even be a nascent Perforce capability. I still don't see Go moving into the enterprise until these issues are sorted out. That boat has already sailed, Go is firmly established in many major networking and Web organizations even without a formal versioning system. They didn't bother waiting for perfection, they got on, did, and coped. I believe from anecdotal evidence just in and around London, Go is now firmly established, shouldering out C completely, being used in areas where otherwise a combination of C, C++ and Python might have been used. Yet Python use has not really been affected. The approach taken by Dub is much better. I think Dub is very analogous to Gustavo Niemeyer's gopkg.in. I suggest that Dub needs to be able to build Fortran, C and C++ systems (replacing or integrating the wonderful SCons) as well as D, with or without bits of Fortran, C and C++, allowing C and C++ folk to slowly introduce bits of D into their systems. I would use this, especially if it could be used in Emacs, Eclipse and IntelliJ IDEA. But maybe it already has these facilities, I haven't been able to do any C++ or D work for three or four months now. -- 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: Using D
On 12 July 2014 15:11, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sat, 2014-07-12 at 13:54 +0100, Iain Buclaw via Digitalmars-d wrote: […] Or a better Oberon, I haven't quite decided which yet... :) Whatever the reality initially, it is definitely now marketed as a modernized C. Echoes of C++ then. If there were more D users in the London area than one in London and one in Brighton maybe we could start a London D User Group (LonDUG). SkillsMatter would host. And I say Hello! from sunny Brighton. Aha the Brighton dwelling D user of note ;-) I have lived in Brighton, but it was a long time ago, it is probably very different now. No West Pier for a start! I live literally 400 yards away from the burnt down west pier. Its a beautiful sight in the morning, come sun, rain, or fog. I hear they are building a 100 metre high elevator-to-nowhere in its place. Sad times... I do believe there are a few people around the London area who either have worked in, work in, or have a vested interest in D. I'll give Dejan a poke and find out some more numbers. We could start a code dojo to build up an initial activity and then spawn off public meetings with tutorial style material to attract people new to D. D for C++ programmers, D for C programmers, D for Python programmers, D for JavaScript kiddies,… We might initially draw on the ACCU London people to gauge interest. I can give you my details, and can see where things go from there. Regards Iain.
Re: Go vs. D vs Java 8
On Sat, Jul 12, 2014 at 03:01:19PM +0100, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-10 at 11:29 -0700, H. S. Teoh via Digitalmars-d wrote: [...] That was zen; this is tao. :P Very Sifu Anthony Korahais [...] https://ca.answers.yahoo.com/question/index?qid=20120310115255AAvhPKE :-P T -- All problems are easy in retrospect.
Re: import from Internet
On Sat, 2014-07-12 at 14:07 +, Dicebot via Digitalmars-d wrote: I agree. Go approach my seem tempting in its simplicity but it scales terribly. It is one of less wise decisions made by Go authors. The decision wasn't made by the Go authors, it was proposed and initially implemented by users, then incorporated into Go by the official high priests. As to whether it is wise, that is must be left to opinion and history. Personally I like it. Good use of DVCS. It only works though because they gave up using Make for using the go command as a build manager associated with having a very strong source code filestore hierarchy requirement. -- 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: Brighton [was Using D]
On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote: […] I live literally 400 yards away from the burnt down west pier. Its a beautiful sight in the morning, come sun, rain, or fog. I hear they are building a 100 metre high elevator-to-nowhere in its place. Sad times... We lived for a while in Little Western Street. Even then the West Pier was crumbling and was closed a short while after we wandered up and down it one afternoon in glorious (very un-English) sun. […] I can give you my details, and can see where things go from there. Is evening meetings in London something you might be up for? Depending on who is involved and what constitutes the centre of mass, there is always the option of meeting in a pub in Clapham Junction – saves the extra haul across Central London. -- 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: Brighton [was Using D]
On 12 July 2014 15:53, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote: […] I live literally 400 yards away from the burnt down west pier. Its a beautiful sight in the morning, come sun, rain, or fog. I hear they are building a 100 metre high elevator-to-nowhere in its place. Sad times... We lived for a while in Little Western Street. Even then the West Pier was crumbling and was closed a short while after we wandered up and down it one afternoon in glorious (very un-English) sun. […] I can give you my details, and can see where things go from there. Is evening meetings in London something you might be up for? Depending on who is involved and what constitutes the centre of mass, there is always the option of meeting in a pub in Clapham Junction – saves the extra haul across Central London. That sounds like at least the beginnings of a plan to me. My only way of getting around would be train due to lack of a car, or license.
The constness problem
http://pointersgonewild.wordpress.com/2014/07/11/the-constness-problem/ I can relate to this. I don't use classes much in D, but I find it frustrating that you need to reach to std.typecons.Rebindable for what I would consider to be a more common usage of const with classes. I really feel that a mutable reference to a const object should be expressible in the core language.
Re: Go vs. D vs Java 8
On Sat, 2014-07-12 at 07:37 -0700, H. S. Teoh via Digitalmars-d wrote: On Sat, Jul 12, 2014 at 03:01:19PM +0100, Russel Winder via Digitalmars-d wrote: On Thu, 2014-07-10 at 11:29 -0700, H. S. Teoh via Digitalmars-d wrote: [...] That was zen; this is tao. :P Very Sifu Anthony Korahais [...] https://ca.answers.yahoo.com/question/index?qid=20120310115255AAvhPKE :-P I'll raise you: http://www.wongkiewkit.com/forum/showthread.php?2336-That-was-Zen-this-is-Tao!/ :-) -- 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: Thread Attributes
On Friday, 11 July 2014 at 18:56:07 UTC, Timon Gehr wrote: On 07/10/2014 08:12 PM, Jonathan Marler wrote: So what do people think? How do you make sure there is at most one thread of each kind? Good question. First, since the language doesn't support starting threads itself (like Go) but instead uses a library, the compiler would likely need to be modified to semantically understand whenever a line of code is starting a thread (I'm assuming it doesn't already). If this feature were interesting enough I'm sure Walter would have an opinion on the right way to accomplish this. Then how do you make sure that every named thread is only started once? The ideal situation would be to verify this at compile time. This is possible in some situations. If it is not possible to verify this at compile time then the compiler could generate a synchronized global pointer to every named thread to prevent each one from getting started more than once. However, one thought that comes to mind is if the developer cannot change the code to be able to verify that the thread is only started once at compile-time then maybe their code is poorly designed or they are using this feature incorrectly. This is just a random thought I had after writing this but maybe if you could somehow tell the compiler that a section of code will only ever be executed once it would help in this analysis. @executeonce. The main function would obviously only be executed once, so any function that executes once would need to be called at most once and you can directly trace where it is called from the main thread. However I'm not sure how useful this feature would be in the general case...I would have to think on it more.
Re: import from Internet
On Saturday, 12 July 2014 at 14:43:13 UTC, Russel Winder via Digitalmars-d wrote: The decision wasn't made by the Go authors, it was proposed and initially implemented by users, then incorporated into Go by the official high priests. As to whether it is wise, that is must be left to opinion and history. Personally I like it. Good use of DVCS. It only works though because they gave up using Make for using the go command as a build manager associated with having a very strong source code filestore hierarchy requirement. Sorry but I am tired of endless appeal to history / usage - by this logic Java and PHP are very good languages full of wisdom. And if someone thinks so we will have a hard time agreeing about anything. Inertia will keep everyone using this feature with no complaints but problems remain : coupling compiler with rather complicated fetching/caching infrastructure, lack of centralized registry to verify contributions, version control. Regarding latter I find it quite telling that dub has recently banned usage of ~master as dependency version and only allows explicit tags/releases - good hygienic decision for growing ecosystem.
Re: Go vs. D vs Java 8
On Monday, 7 July 2014 at 15:33:06 UTC, bearophile wrote: Nordlöw: Done. But that author doesn't switch to dmd 2.066beta1 :-) From the blog post: However, the language itself feels a bit old and a bit too much like C++. That's not strange considering its age, but you can’t help thinking that time has left D a bit behind. This is partially true, but it's also a matter of what kind of style you use D. If you write it like java, it looks like java. Bye, bearophile As a C# programmer, i feel offended
Re: Go vs. D vs Java 8
On 07/12/2014 05:56 PM, Israel Rodriguez wrote: On Monday, 7 July 2014 at 15:33:06 UTC, bearophile wrote: From the blog post: However, the language itself feels a bit old and a bit too much like C++. That's not strange considering its age, but you can’t help thinking that time has left D a bit behind. This is partially true, but it's also a matter of what kind of style you use D. If you write it like java, it looks like java. Bye, bearophile As a C# programmer, i feel offended Why would you feel offended?
Re: Review: std.logger
Overall looks good to me. Some points that haven't been mentioned so far in this review round: - Using a class with static members doesn't seem to be very idiomatic. It seems like the three member properties can simply be made global and everything should be fine - the LogManager. prefix doesn't really add information. This has been mentioned in the last review round and it's not a very important point in this particular instance, but we should really make a decision here that will also decide how future modules go about this. - Personally, I really find additional verbose log levels useful. Currently there is only trace. Previous proposals had a generic verbose(N) set of levels, but I think it's important for the proper interaction of multiple libraries to define a semantic set of verbose levels. A proposal, which has worked very well me (from low to high): trace: as now, used for low level tracing of program flow debugv: verbose debug messages, may flood the log debug: normal, low frequency debug messages, useful for the developer diagnostic: diagnostic output also potentially useful for the user this is what you typically would get with the -v command line switch - There is a formatString string mixin that includes a lot of if-else cases that seem to do exactly what formattedWrite would do anyway, is there something that it actually does in addition to that? Also, why is it a string mixin in contrast to a simple (template) function? It may be a matter of taste (but also of compile time/memory), but I'd almost always prefer a non-string-mixin solution. - Even if it may be more typing (or maybe not?), actually writing out the different signatures for each log level and the c/f suffixes would be very advantageous for the documentation and for code completion. It would also make the EBNF unnecessary, which I agree with Johannes looks a little scary. All of the functions could be based on the generic logl/loglf functions, so that there wouldn't be much redundancy. - I'm still really not sure if the c versions of the log functions pull their own weight. They seem to be in line with trivial convenience functions, which are generally discouraged in Phobos (with the same issues, such as additional cognitive load and bigger API size). - The functions error(), info(), fatal(), etc. don't follow the usual rule for functions to start with a verb. The question is if saving three characters over logError() is worth making the code more ambiguous for the outside reader (e.g. does error() throw an exception? or set some internal error state? does fatal() terminate the process?)
Re: Go vs. D vs Java 8
On Saturday, 12 July 2014 at 16:11:46 UTC, Timon Gehr wrote:
On 07/12/2014 05:56 PM, Israel Rodriguez wrote:
On Monday, 7 July 2014 at 15:33:06 UTC, bearophile wrote:
From the blog post:
However, the language itself feels a bit old and a bit too
much like
C++. That's not strange considering its age, but you can’t
help
thinking that time has left D a bit behind.
This is partially true, but it's also a matter of what kind
of style
you use D. If you write it like java, it looks like java.
Bye,
bearophile
As a C# programmer, i feel offended
Why would you feel offended?
My code looks like java bro...
m, that delicious Java
if (File.Exists(gamesave.txt))
{
File.Copy(gamesave.txt, savedworkingdirectory +
\\gamesave2.txt, true);
Console.WriteLine(File processed succesfully);
Console.ReadLine();
}
else
{
Console.WriteLine(Could not find file);
Console.ReadLine();
}
Re: Dub feature [was import from Internet]
On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d wrote: […] verify contributions, version control. Regarding latter I find it quite telling that dub has recently banned usage of ~master as dependency version and only allows explicit tags/releases - good hygienic decision for growing ecosystem. Sad if true, I want the capability to be on the bleeding edge. If the possibility of specifying version exists then people who want hygiene are covered. Removing the facility of ~master stops those of use who like things to break using Dub at all. Oh well back to SCons and manual working. -- 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: import from Internet
On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d wrote: […] Sorry but I am tired of endless appeal to history / usage - by this logic Java and PHP are very good languages full of wisdom. And if someone thinks so we will have a hard time agreeing about anything. Why are you tired of this? History is extremely useful for learning and moving forward. Maybe PHP is an aberration designed to allow broken websites, but many still like it and use it successfully. That PHP and all sites using it should be replaced is seemingly agreed, but conservative management and some developers are unprepared to take risks by replacing that which works. Java may have its faults and it may have gained traction due to massive over-hyping (*), but it does have good stuff in it (**). Java evolves and improves in order to stay relevant. Of course conservative management and a lot of developers refuse to consider a move away from Java as they have systems that work and are unprepared to consider reimplementation. Backward compatibility then becomes an obsession to the detriment of programming language evolution at the bleeding edge. Java suffers this very badly. Kotlin, Ceylon and Scala are trying to achieve forward movement but are not getting the mindshare they deserve. Groovy can be seen as a set of hacks to make creating systems which are Java based nice to write and maintain. Inertia will keep everyone using this feature with no complaints but problems remain : coupling compiler with rather complicated fetching/caching infrastructure, lack of centralized registry to verify contributions, version control. Regarding latter I find it quite telling that dub has recently banned usage of ~master as dependency version and only allows explicit tags/releases - good hygienic decision for growing ecosystem. I suggest that finding ways of dealing with the issues rather than running away from them is what should happen. As an emergent property Maven Central has become the central repository for all JVM artefacts. Maven though failed to really do the job of being a project build and management system. Gradle is doing a lot better job. Similarly JUnit3 → TestNG → Spock also ScalaTest, Cucumber, etc. has shown that inertia can be overcome by providing something that is compatible and yet provably better. So what is the inertia breaker to get Fortran, C and C++ folk to use D? I have no idea, but unless there are active user local groups evangelizing D nothing will change. This email list is important as a central exchange mechanism, but it is useless for marketing and evangelizing. (*) Trust me on this there was massive over-hyping of Java in the 1994 to 2001 period, I was an indirect part of it. (**) Though there is a lot of crap, such as claiming to be object-oriented when clearly it isn't; object-based maybe, but definitely no object-oriented. -- 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: For the adventurous: News from the LDC/Linux front
On 10/07/14 01:35, David Nadlinger via Digitalmars-d wrote: A few lost hairs and an implementation of weak symbols later, this should now be fixed in Git master. In other words, there are currently no known issues with shared libraries, so everybody test away. ;) Hmm, I just rebuild current git master from a fresh pull, and the problem is still there. :-( This is a fresh build on Ubuntu 14.04 with cmake called via: cmake -DCMAKE_INSTALL_PREFIX=/opt/ldc -DBUILD_SHARED_LIBS=ON .. Then if I try to build and run the hap.random benchmark with ldmd2 -I./source -O -inline -release -ofbenchmarknew benchmarknew.d source/hap/random/adaptor.d source/hap/random/distribution.d source/hap/random/generator.d source/hap/random/package.d source/hap/random/traits.d ./benchmarknew the latter falls over with the error previously mentioned: error while loading shared libraries: libphobos2-ldc.so.65: cannot open shared object file: No such file or directory. I note that when make install is run, then after libphobos2-ldc.so is installed, I see the following: -- Removed runtime path from /opt/ldc/lib/libphobos2-ldc.so.2.0.65 -- Installing: /opt/ldc/lib/libdruntime-ldc-debug.so.2.0.65 -- Installing: /opt/ldc/lib/libdruntime-ldc-debug.so.65 -- Installing: /opt/ldc/lib/libdruntime-ldc-debug.so -- Installing: /opt/ldc/lib/libphobos2-ldc-debug.so.2.0.65 -- Installing: /opt/ldc/lib/libphobos2-ldc-debug.so.65 -- Installing: /opt/ldc/lib/libphobos2-ldc-debug.so -- Removed runtime path from /opt/ldc/lib/libphobos2-ldc-debug.so.2.0.65 ... is this relevant?
Re: The constness problem
On Sat, Jul 12, 2014 at 03:03:12PM +, Peter Alexander via Digitalmars-d wrote: http://pointersgonewild.wordpress.com/2014/07/11/the-constness-problem/ I can relate to this. I don't use classes much in D, but I find it frustrating that you need to reach to std.typecons.Rebindable for what I would consider to be a more common usage of const with classes. I really feel that a mutable reference to a const object should be expressible in the core language. +1. This also adversely affects generic code. As soon as you have a const in there, things break. We badly, badly, need tail-const. T -- Let X be the set not defined by this sentence...
Re: Review: std.logger
On Sat, Jul 12, 2014 at 06:13:28PM +0200, Sönke Ludwig via Digitalmars-d wrote: Overall looks good to me. Some points that haven't been mentioned so far in this review round: - Using a class with static members doesn't seem to be very idiomatic. It seems like the three member properties can simply be made global and everything should be fine - the LogManager. prefix doesn't really add information. This has been mentioned in the last review round and it's not a very important point in this particular instance, but we should really make a decision here that will also decide how future modules go about this. [...] +1. If something is a global, just call it a global. There's no need to be ashamed of that. Classes with only static members sound to me like forcing round pegs into square holes. T -- What doesn't kill me makes me stranger.
Re: For the adventurous: News from the LDC/Linux front
On 12/07/14 19:12, Joseph Rushton Wakeling via Digitalmars-d wrote: Hmm, I just rebuild current git master from a fresh pull, and the problem is still there. :-( I'm so sorry, this is completely wrong. I'd just forgotten to put back my /etc/ld.so.conf.d/ldc2.conf file pointing to /opt/ldc/lib. With this in place, everything seems to work fine. (Before, it really was a problem, as I was still getting the error even with the ldc2.conf file in place;-)
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
On Friday, 11 July 2014 at 21:04:05 UTC, H. S. Teoh via Digitalmars-d wrote: On Thu, Jul 10, 2014 at 08:10:36PM +, via Digitalmars-d wrote: Hmm. Seems that you're addressing a somewhat wider scope than what I had in mind. I was thinking mainly of 'scope' as does not escape the body of this block, but you're talking about a more general case of being able to specify explicit lifetimes. Indeed, but it includes what you're suggesting. For most use cases, just `scope` without an explicit lifetime annotation is fully sufficient. [...] A problem that has been discussed in a few places is safely returning a slice or a reference to an input parameter. This can be solved nicely: scope!haystack(string) findSubstring( scope string haystack, scope string needle ); Inside `findSubstring`, the compiler can make sure that no references to `haystack` or `needle` can be escape (an unqualified `scope` can be used here, no need to specify an owner), but it will allow returning a slice from it, because the signature says: The return value will not live longer than the parameter `haystack`. This does seem to be quite a compelling argument for explicit scopes. It does make it more complex to implement, though. [...] An interesting application is the old `byLine` problem, where the function keeps an internal buffer which is reused for every line that is read, but a slice into it is returned. When a user naively stores these slices in an array, she will find that all of them have the same content, because they point to the same buffer. See how this is avoided with `scope!(const ...)`: This seems to be something else now. I'll have to think about this a bit more, but my preliminary thought is that this adds yet another level of complexity to 'scope', which is not necessarily a bad thing, but we might want to start out with something simpler first. It's definitely an extension and not as urgently necessary, although it fits well into the general topic of borrowing: `scope` by itself provides mutable borrowing, but `scope!(const ...)` provides const borrowing, in the sense that another object temporarily takes ownership of the value, so that the original owner can only read the object until it is returned by the borrowed value going out of scope. I mentioned it here because it seemed to be an easy extension that could solve an interesting long-standing problem for which we only have workarounds today (`byLineCopy` IIRC). And I have to add that it's not completely thought out yet. For example, might it make sense to have `scope!(immutable ...)`, `scope!(shared ...)`, and if yes, what would they mean... [...] An open question is whether there needs to be an explicit designation of GC'd values (for example by `scope!static` or `scope!GC`), to say that a given values lives as long as it's needed (or forever). Shouldn't unqualified values already serve this purpose? Likely yes. It might however be useful to contemplate, especially with regards to allocators. [...] Now, for the problems: Obviously, there is quite a bit of complexity involved. I can imagine that inferring the scope for templates (which is essential, just as for const and the other type modifiers) can be complicated. I'm thinking of aiming for a design where the compiler can infer all lifetimes automatically, and the user doesn't have to. I'm not sure if this is possible, but based on what Walter said, it would be best if we infer as much as possible, since users are lazy and are unlikely to be thrilled at the idea of having to write additional annotations on their types. I agree. It's already getting ugly with `const pure nothrow @safe @nogc`, adding another annotation should not be done lightheartedly. However, if the compiler could infer all the lifetimes (which I'm quite sure isn't possible, see the haystack-needle example), I don't see why we'd need `scope` at all. It would at most be a way not to break backward compatibility, but that would be another case where you could say that D has it backwards, like un-@safe by default... My original proposal was aimed at this, that's why I didn't put in explicit lifetimes. I was hoping to find a way to define things such that the lifetime is unambiguous from the context in which 'scope' is used, so that users don't ever have to write anything more than that. This also makes the compiler's life easier, since we don't have to keep track of who owns what, and can just compute the lifetime from the surrounding context. This may require sacrificing some precision in lifetimes, but if it helps simplify things while still giving adequate functionality, I think it's a good compromise. I agree it looks a bit intimidating at first glance, but as far as I can tell it should be relatively straightforward to implement. I'll explain how I think it could be done: The obvious things: The parser needs
Re: Dub feature [was import from Internet]
Am 12.07.2014 18:20, schrieb Russel Winder via Digitalmars-d: On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d wrote: […] verify contributions, version control. Regarding latter I find it quite telling that dub has recently banned usage of ~master as dependency version and only allows explicit tags/releases - good hygienic decision for growing ecosystem. Sad if true, I want the capability to be on the bleeding edge. If the possibility of specifying version exists then people who want hygiene are covered. Removing the facility of ~master stops those of use who like things to break using Dub at all. Oh well back to SCons and manual working. There are still a number of ways to stay on the bleeding edge, just direct ~master/branch dependencies in dub.json are discouraged/deprecated, because they have a destructive effect on the package ecosystem. I'll write up a detailed rationale before the next release, including suggestions how to handle situations where you want to stay on a branch. Related thread: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1020/
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via Digitalmars-d wrote: Along these lines, I'm wondering if turtles all the way down is the wrong way of looking at it. Consider, for example, an n-level deep nesting of aggregates. If obj.nest1 is const, then obj.nest1.nest2.x must also be const, because otherwise we break the const system. So const is transitive downwards. But if obj.nest1 is a scoped reference type with lifetime L1, that doesn't necessarily mean obj.nest1.y only has lifetime L1. It may be a pointer that points to an infinite lifetime object, for example, so it's not a problem that the pointer goes out of scope before the object pointed to. OTOH, if obj.nest1 has scope L1, then obj itself cannot have a longer lifetime than L1, otherwise we may access obj.nest1 after its lifetime is over. So the lifetime of obj.nest1 must propagate *upwards* (or outwards). I'm not so sure about transitivity either, although I started with it. One reason that `const`, `immutable` and `shared` need to be transitive is that we can then use this fact to infer other properties from it, e.g. thread-safety. I don't really see such advantages for `scope`, but instead it would make handling `scope` in aggregates extremely complicated. And it wouldn't make much sense either IMO, because aggregates are usually defined somewhere else than where they are used, and often by a different author, too. Therefore, they come with their own ownership strategies, and it's simply not possible to force a different one onto them from the outside. For this reason, I now tend to intransitivity. There also something else that became clear to me: If an important use case is found that requires transitivity, nothing is really lost. We know all the types that are involved, and we can check whether all references contained in them are marked as `scope` using introspection, even without additional compiler support beyond a simple trait, just as we can today check for things like `hasUnsharedAliasing`! Therefore, we wouldn't even close the doors for further improvements if we decide for intransitivity.
Re: import from Internet
On Saturday, 12 July 2014 at 16:38:35 UTC, Russel Winder via Digitalmars-d wrote: On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d wrote: […] Sorry but I am tired of endless appeal to history / usage - by this logic Java and PHP are very good languages full of wisdom. And if someone thinks so we will have a hard time agreeing about anything. Why are you tired of this? History is extremely useful for learning and moving forward. Because history is never as simple as those referring to it want it to be. Connecting some facts and assuming tight relation between those is annoyingly common fallacy. Maybe PHP is an aberration designed to allow broken websites, but many still like it and use it successfully. This is exactly what I have meant - there is no point to refer to historical language success when discussing technological issues. Saying that some feature is fine simply because language that has it is widely used is an approach that does not cope well with the existence of PHP. Everyone will be happy with this decision until it becomes a real pain but it doesn't make it any better. Don't mix marketing and language design. So what is the inertia breaker to get Fortran, C and C++ folk to use D? I have no idea, but unless there are active user local groups evangelizing D nothing will change. This email list is important as a central exchange mechanism, but it is useless for marketing and evangelizing. Evangelizing is a playing an alien game with starting disadvantage. No way you can over-hype Google. I believe D should stick to its strengths - being versatile, pragmatical and not opinionated. Targeting not folks but senior developers who chose languages for next big application and have already learned their hard lessons of trusting the hype. Whatever marketing strategy is considered, though, does not really matter here. What I am asking here is to stop attacking technological decisions from marketing standpoint. I hate it.
Re: Using D
On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d wrote: In the end it is about community rather than the programming language per se. Java created a huge community that was evangelical. Go has rapidly created an active community that is evangelical. Python has rapidly created a large evangelical community. D has slowly created a small community that hasn't as yet created the outward looking evangelical aspect. Where are the user groups having local meetings is my main metric. Java definitely, Go definitely, C++ sort of, D no. This is the real problem for D I feel. Without local user groups meeting up you don't get exposure and you don't get traction in the market. This seems like an outdated way of looking at things. I've never attended a user group in my life, yet I've picked up several technologies since I left college a while back. When I found out that such user groups existed, I thought they were kind of quaint, a remnant of pre-internet times. As for an evangelical community, did C and C++ have those? I don't think anyone was ever really evangelical about Obj-C as it took off over the last couple years, riding on the coattails of the meteoric rise of iOS. Evangelism can help, but it can be more a sign of the evangelist's enthusiasm than a tech worth using. Maybe D isn't ready for evangelism yet, there's something to be said for getting the product in gear before advertising it. Not saying there's anything wrong with DUGs, higher bandwidth interaction and all, but the current approach of D developers giving talks at outside gatherings or putting DConf talks online seems like a much better way to spread the gospel to me. Certainly both can be done, I just wouldn't use DUGs as the main metric. I've said it a couple times before, but it bears repeating: what D needs is a killer app. Rails showed the ease of use of ruby. iOS made Obj-C a star. D needs to show its utility by spawning a similar killer app, that's what will prove its worth in the market. We can't know what that will be, but if D is any good, it will probably happen at some point.
Re: Opportunities for D
On 7/10/2014 10:53 PM, deadalnix wrote: Most of them never gathered any attention. Sometimes, when the idea is right, you still need to get behind and push it. Build it and they will come is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is. The DIPs were for things that looked obscure and were technically complex, a surefire recipe for a collective yawn even though I knew they were crucial (inferring uniqueness). If you're looking for lots of comments, start a nice bikeshedding thread about whitespace conventions :-)
Re: Opportunities for D
Am Sat, 12 Jul 2014 13:27:26 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 7/10/2014 10:53 PM, deadalnix wrote: Most of them never gathered any attention. Sometimes, when the idea is right, you still need to get behind and push it. Build it and they will come is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is. The DIPs were for things that looked obscure and were technically complex, a surefire recipe for a collective yawn even though I knew they were crucial (inferring uniqueness). If you're looking for lots of comments, start a nice bikeshedding thread about whitespace conventions :-) But you've got some nice bonus: If somebody doesn't like your pull request you can just merge it anyway. But if you veto something the only one who can probably merge anyway is Andrei.
Re: Review: std.logger
On 7/12/14, 4:04 AM, Dicebot wrote: On Saturday, 12 July 2014 at 03:22:10 UTC, Jesse Phillips wrote: On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote: On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David I'm of the opinion we should review for std.* and vote for std.experimental.* Prior to or during beta we vote to move into std.* Agreed. That's nice. Doing laps in std.experimental for one release cycle can only improve form. Let's. -- Andrei
Re: import from Internet
On 7/12/14, 6:47 AM, Russel Winder via Digitalmars-d wrote: On Sat, 2014-07-12 at 13:13 +, Dicebot via Digitalmars-d wrote: On Saturday, 12 July 2014 at 13:10:09 UTC, Katayama Hirofumi MZ wrote: https://github.com/D-Programming-Language/dub/issues/373 What I have meant is that importing from internet functionality is currently provided by dub packages and does not belong to compiler. URL imports in your proposed form are absolutely horrible. It's an idea Go has picked up. The URL must refer to a Git, Bazaar, Mercurial repository. The repository is clone locally so that the actual build is local. To be honest it works quite well. My understanding is there's significant controversy about the feature. -- Andrei
Re: import from Internet
This is a really bad idea. Being able to decide how a dependency gets pulled in for a library you depend on is a blessing, especially when you have to lock versions down. This only works for something like loading JavaScript files, where you can assume only roughly 6 concurrent connections per server are allowed, so you use CDNs more.
Re: The constness problem
On Saturday, 12 July 2014 at 15:03:13 UTC, Peter Alexander wrote:
http://pointersgonewild.wordpress.com/2014/07/11/the-constness-problem/
I can relate to this. I don't use classes much in D, but I find
it frustrating that you need to reach to
std.typecons.Rebindable for what I would consider to be a more
common usage of const with classes.
It seems she laments the lack of both head-const in general and
tail-const for classes. Head-const isn't really an issue, in my
opinion, because it is rarely needed and easily obtained with
existing language features:
struct HeadConst(T)
{
this(T value) { value_ = value; }
alias get this;
private:
@property T get() { return value_; }
T value_;
}
HeadConst!MyClass obj = new MyClass;
obj = new MyClass; // Error!
The lack of tail-const class references, on the other hand, is
one of D's most severe shortcomings.
I really feel that a mutable reference to a const object should
be expressible in the core language.
Michel Fortin once made a working pull request for DMD that
introduced the syntax
const(MyClass) ref thisIsRebindable = new MyClass;
Personally, I would prefer replacing the current object reference
syntax with T$ (or T# if that conflicts with the current dollar
operator), like this:
Foo$ obj1 = new Foo;// Rebindable and mutable
const(Foo)$ obj2 = new Foo; // Rebindable but const
const(Foo$) obj3 = new Foo; // Fully const
The current 'T' reference type would of course have to be
accepted and equivalent to the 'T$' reference type for a long
time before it is eventually deprecated.
Come to think of it, new T could return T$ for non-class
types too, where T$ would then act like a non-dereferentiable
pointer on which it is not allowed to do pointer arithmetics.
Lars
Re: Review: std.logger
On 7/12/14, 10:19 AM, H. S. Teoh via Digitalmars-d wrote: On Sat, Jul 12, 2014 at 06:13:28PM +0200, Sönke Ludwig via Digitalmars-d wrote: Overall looks good to me. Some points that haven't been mentioned so far in this review round: - Using a class with static members doesn't seem to be very idiomatic. It seems like the three member properties can simply be made global and everything should be fine - the LogManager. prefix doesn't really add information. This has been mentioned in the last review round and it's not a very important point in this particular instance, but we should really make a decision here that will also decide how future modules go about this. [...] +1. If something is a global, just call it a global. There's no need to be ashamed of that. Classes with only static members sound to me like forcing round pegs into square holes. I agree. This is not Java. That idiom must go. -- Andrei
Re: import from Internet
On 7/12/14, 12:54 PM, Dicebot wrote: On Saturday, 12 July 2014 at 16:38:35 UTC, Russel Winder via Digitalmars-d wrote: On Sat, 2014-07-12 at 15:41 +, Dicebot via Digitalmars-d wrote: […] Sorry but I am tired of endless appeal to history / usage - by this logic Java and PHP are very good languages full of wisdom. And if someone thinks so we will have a hard time agreeing about anything. Why are you tired of this? History is extremely useful for learning and moving forward. Because history is never as simple as those referring to it want it to be. Connecting some facts and assuming tight relation between those is annoyingly common fallacy. I agree. Adoption of programming languages is a complex phenomenon and reducing its analysis to D must do this one thing to be successful is rather simplistic. Andrei
Re: Rosettacode example collection
Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. Yeah that would indeed be nice to have.
Re: For the adventurous: News from the LDC/Linux front
On 08/07/14 19:54, David Nadlinger via Digitalmars-d wrote: And secondly, proper support for building druntime/Phobos as shared libraries and loading D shared objects dynamically has now arrived in LDC! As you might be aware, Martin Nowak has spent a considerable amount of effort on adding runtime loading capabilities to DMD and druntime during the last year or so. LDC now offers the same level of functionality, to a good part based on Martin's solid work. To build a copy of LDC with druntime/Phobos as a shared library, which is also required for proper runtime loading, simply pass -DBUILD_SHARED_LIBS=ON to CMake. Oh, and for now this is Linux-only too, sorry. So, now that I have this running, I thought I'd give it a go trying out hap.random's benchmarks with shared and with static druntime/phobos. Most of hap.random is pretty standalone apart from reliance on std.range and std.traits (and I think that largely for compile-time checks), so, as can be expected, most functions are not meaningfully affected by being compiled against a shared library. The handful of functions that depend on std.math seem to take a small speed hit that might not be significant. However, the dice() function, which relies on std.algorithm.reduce, takes a substantial speed hit, taking 20% more time to run compared to when the benchmarks are compiled against a static phobos. This is probably within the realm of normalcy, and I guess the speed hit might turn out to be smaller on a larger overall timescale/number of calls, but it seems a shame (and unexpected, as reduce is obviously templated, so I wouldn't expect to have a speed hit because of shared library linkage). Can anyone suggest an explanation?
Re: Opportunities for D
On 7/12/14, 1:38 PM, Johannes Pfau wrote: But you've got some nice bonus: If somebody doesn't like your pull request you can just merge it anyway. That hasn't happened in a really long time, and last time it did is before we had due process in place. But if you veto something the only one who can probably merge anyway is Andrei. Such situations are best resolved by building consensus and a shared vision. Andrei
Re: Opportunities for D
On 7/12/14, 1:27 PM, Walter Bright wrote: On 7/10/2014 10:53 PM, deadalnix wrote: Most of them never gathered any attention. Sometimes, when the idea is right, you still need to get behind and push it. Build it and they will come is a stupid hollywood fantasy. I've also written DIPs, which garnered zero comments. I implemented them, and the PR's sat there for some time, until I finally harangued some people via email to get them pulled. I'm not complaining, I'm just saying that's just how it is. Indeed that's how it is. It's also a quality issue - we can reasonably assume that a perfect slam-dunk DIP would be easily recognized; many of the current DIPs (including mine) need work and dedication, which is more difficult to find. Andrei
git tag --fubar
I should be posting this in dmd-beta but instead I'm posting it here because I am currently locked out of my gmail account, the recovery account for which is yahoo and I'm locked out of that too. Google doesn't trust me because I moved out of the country and then went on a trip... and Yahoo doesn't trust for the same reasons. Problem is, I created my recovery questions for yahoo back in 2008 and the first time they ever ask me for it was back in April of this year. It's so simple I cannot remember it: What is your son's name? and Where did you meet your wife?. Try as I amy I cannot figure out where I met her or whether we ever had a son together. What a second, do I even have a wife? End result, my GMail is locked until 17 July, while my Yahoo account is locked for 12 hours. Damn! G! Ahhh! Sorry about that... That's definitely not the purpose of this post. I had some issues keeping things straight in my head about which repo I visited, which branch I checkout and which ones I tagged. So I decided to automate the process. Starting with v2.066.0-b3 every repo gets tagged correctly and the tag gets pushed automatically to master. I'm in nirvana. No more forgetting to tag things or tagging them in the wrong places. The problem? I screwed up the v2.066.0-b1 tags by placing them in master instead of the 2.066 branch. So when I build the binaries from v2.066.0-b3, it's ignoring changes in the branch. To make matters worse, after visiting both branch and master for all repos, everyone exhibited the same problem with the exception of tools. Tools did not have the v2.066.0-b3 tag and showed the same tag in both master and the branch. I tried removing the tag from master to match the rest of the repos but that did not work, it simply removed all references to the tag. The only way I know to fix this is to remove all the v2.066 tags and just start over with v2.066.b3. Some advice would really be appreciated. Regards, Andrew
What is the Go/NoGo gauge for releases?
Moved from D.announce for further discussion by request: On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David David, I'm sure you are aware that list will never be empty. The last release lasted from mid November to 24 February and that list was never empty once during that entire time. The only way we will empty that list is to prevent people from submitting new regressions during a review. When I checked the list yesterday the count was at 9: right now it is at 12. And at least on of those items on the list has been there since 2011. The reality is that zero emphasis is place on regressions unless it's time for a release, and even then, only a few people pay attention to them. Everyone else just continue on in their happy world doing what's important to them. You you cannot ask that anyone work on anything because if it's not important in their minds, they will not do it. They'd much rather sit around and biker about how you did it incorrectly. Which, in my opinion, is a huge wast of time and resource. So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it?
Re: Opportunities for D
On 7/12/2014 1:38 PM, Johannes Pfau wrote: But you've got some nice bonus: If somebody doesn't like your pull request you can just merge it anyway. I'd only do that in an emergency. I'll also just pull the ones for D1. But if you veto something the only one who can probably merge anyway is Andrei. Andrei and I don't always agree, but we've not gone around overriding each other.
Re: git tag --fubar
On 7/12/2014 5:27 PM, Andrew Edwards wrote: Some advice would really be appreciated. I share your pain. Others here have rescued my github apocalyptic screwups several times.
Re: What is the Go/NoGo gauge for releases?
On 7/12/2014 8:35 PM, Andrew Edwards wrote: Moved from D.announce for further discussion by request: On Saturday, 12 July 2014 at 00:13:47 UTC, David Nadlinger wrote: For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David [...] So I have some questions: What is the magic number that will trigger the release? What happens if we never reach that number? Do we just continue waiting for it or do we make a decision at some point that it's time? If so, how long do we wait? Is there one person who makes the decision, or is it decision automatic? If there is a person, who is it? My understanding (I could be wrong) is the general rule of thumb has been No *new* regressions compared to the previous release.
Re: Software Assurance Reference Dataset
On Friday, 11 July 2014 at 17:28:39 UTC, deadalnix wrote: The compiler can ensure that you hit at least every 4k or so. It doesn't look like a very hard constraint to have a volatile load per untouched 4k of stack (which should be very rare). Sure, it should be possible to work it into the backend at the code-gen level. For fibers without recursion I think the most powerful approach would be to do whole program analysis to establish a minimum of N for the typical case (without unbounded recursion). Of course, then alloca also have to extend the stack and do book keeping of the additional storage taken by alloca() or simply have a separate alloc-stack.
Re: Software Assurance Reference Dataset
On 7/11/2014 10:28 AM, deadalnix wrote: The compiler can ensure that you hit at least every 4k or so. And it already does.
Re: Using D
.On 12 July 2014 20:55, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 12 July 2014 at 10:27:12 UTC, Russel Winder via Digitalmars-d wrote: In the end it is about community rather than the programming language per se. Java created a huge community that was evangelical. Go has rapidly created an active community that is evangelical. Python has rapidly created a large evangelical community. D has slowly created a small community that hasn't as yet created the outward looking evangelical aspect. Where are the user groups having local meetings is my main metric. Java definitely, Go definitely, C++ sort of, D no. This is the real problem for D I feel. Without local user groups meeting up you don't get exposure and you don't get traction in the market. This seems like an outdated way of looking at things. I've never attended a user group in my life, yet I've picked up several technologies since I left college a while back. When I found out that such user groups existed, I thought they were kind of quaint, a remnant of pre-internet times. As for an evangelical community, did C and C++ have those? I don't think anyone was ever really evangelical about Obj-C as it took off over the last couple years, riding on the coattails of the meteoric rise of iOS. Evangelism can help, but it can be more a sign of the evangelist's enthusiasm than a tech worth using. Maybe D isn't ready for evangelism yet, there's something to be said for getting the product in gear before advertising it. Not saying there's anything wrong with DUGs, higher bandwidth interaction and all, but the current approach of D developers giving talks at outside gatherings or putting DConf talks online seems like a much better way to spread the gospel to me. Certainly both can be done, I just wouldn't use DUGs as the main metric. We are social creatures, and the fact is that people just get more done when they are in a room together. The beer probably helps more in agreeing also. ;-) I've said it a couple times before, but it bears repeating: what D needs is a killer app. Rails showed the ease of use of ruby. iOS made Obj-C a star. D needs to show its utility by spawning a similar killer app, that's what will prove its worth in the market. We can't know what that will be, but if D is any good, it will probably happen at some point. Killer... app... ugh, how evangelical.
Raw Binary into the console
How Can I Print Raw Binary Into The Console? I Have Variable Of Type ubyte which equals 0b011 How Can I Get The Variable To Print Out As 011
Re: Raw Binary into the console
On 07/11/2014 10:56 PM, Sean Campbell wrote: How Can I Print Raw Binary Into The Console? Taking a step back, a D program prints to stdout, not console. However, in most cases a D program's output ends up on the console when it is started in a console. So, one can print any byte value to the stdout, which usually ends up on the console. Now, the question is how that value will be interpreted by the console. On some consoles (e.g. Linux) the byte stream is interpreted as a UTF-8 stream or a control character in the case of 0b011. I Have Variable Of Type ubyte which equals 0b011 How Can I Get The Variable To Print Out As 011 That is different though. You seem to want to print the value 0b011 as the string 011. %b format specifier does that. However, in most cases it is also useful to zero-pad the output: writefln(%08b, 0b011); Ali
Const problems
In case you have missed the thread: http://www.reddit.com/r/programming/comments/2ag8qe/the_constness_problem/ Bye, bearophile
Something like Python's psutils for D?
The Subject says it all, is something like psutils available in D? [1] I need it to measure memory usage of a process. [1] https://github.com/giampaolo/psutil thank you Thomas
Re: Something like Python's psutils for D?
I also need to get the user and system time of a process, doesn't seem to be available in Phobos. (e.g. getrusage in Linux but platform independent)
Re: Value Reference Type Traits
On Friday, 11 July 2014 at 16:22:37 UTC, anonymous wrote: There's http://dlang.org/phobos/std_traits.html#hasIndirections Thx.
Help to find crash in simple stack type?
I've created a simple stack type using calloc/free which seems to
work nicely. Then instead of using C functions i've tried to
implement the same type using the GC. However i'm experiencing a
crash. I've been staring at this snippet for hours now any help
would be appreciated. This is a simplified snippet showing the
crash:
import std.stdio;
import core.memory;
class Stack(T)
{
private T* _data;
private T* _pointer;
private immutable size_t _minimumSize;
private size_t _size;
private size_t _count;
public this()
{
this._minimumSize = 32_000;
this._size = this._minimumSize;
this._data = cast(T*)GC.calloc(this._size, GC.BlkAttr.NO_MOVE);
this._pointer = this._data;
this._pointer--;
}
public void push(T value)
{
this._pointer++;
if ((this._size / T.sizeof) (this._count + 1))
{
this._size *= 2;
writefln(realloc to %s bytes, this._size);
this._data = cast(T*)GC.realloc(this._data, this._size,
GC.BlkAttr.NO_MOVE);
this._pointer = (this._data + this._count);
}
this._count++;
*this._pointer = value;
}
}
unittest
{
auto stack = new Stack!(int);
for (int x = 1; x = 300_000 ; x++)
{
stack.push(x);
}
}
It seems to crash when the loop iteration is at about 260,000 and
i've no idea why. I'm using Ubuntu 64bit latest DMD.
Re: Help to find crash in simple stack type?
On 12.07.2014 16:24, anonymous wrote:
No explanation or solution, but a reduction:
import core.memory;
void main()
{
alias T = ubyte;
enum size1 = 2_049; /* 2_048 = 2^^11 */
enum size2 = 1_048_577; /* 1_048_576 = 2^^20 */
T* _data;
_data = cast(T*)GC.calloc(size1, GC.BlkAttr.NO_MOVE);
_data = cast(T*)GC.realloc(_data, size2, GC.BlkAttr.NO_MOVE);
T* _pointer = _data;
foreach(i; 0 .. size2)
{
*_pointer = 0; /* segfault at i = 1_048_576 */
_pointer++;
}
}
Thanks for the reduction. GC.realloc seems broken for reallocations to
sizes larger than the current GC pool.
Please file a bug report.
Re: Help to find crash in simple stack type?
On 12.07.2014 19:05, Rainer Schuetze wrote: Thanks for the reduction. GC.realloc seems broken for reallocations to sizes larger than the current GC pool. Please file a bug report. Actually done that myself: https://issues.dlang.org/show_bug.cgi?id=13111
OSX, Need help with Compiling and linking errors
Ive been reading the OSX notes for the DMD compiler but not everything is clear to me as i dont know how exactly the compiler looks for things. i wanted to test it out first using this package from code.dlang.org http://code.dlang.org/packages/colorize I downloaded the zip, extracted it, and dub was able to spit out a static library with the .a extension. What do i do with it now? Where do i place it? I have imported the library like it says import colorize : colorize, fg; After i call dmd in the terminal like $ dmd main.d, All i get are linker errors but no compile errors even if i reference the static library in the same drectory as my main.d source file like so, $ dmd main.d libcolorize.a Then the package mentions adding colorize as a dependency to my projects json file so i used the -X switch to generate it but i dont know exactly where the dependencies section goes. As for the linker errors, they mention mostly: === Undefined symbols for architecture x86_64: _D4dlib4math6matrix16__T6MatrixTdVi4Z6Matrix11__xopEqualsFKxS4dlib4math6matrix16__T6MatrixTdVi4Z6MatrixKxS4dlib4math6matrix16__T6MatrixTdVi4Z6MatrixZb, referenced from: _D52TypeInfo_S4dlib4math6matrix16__T6MatrixTdVi4Z6Matrix6__initZ in main.o ld: symbol(s) not found for architecture x86_64 === Does this mean this library is just not compatible with OSX? Extra Notes: I have Xcode Installed along with the command line tools so GCC is in there too. OSX 10.9.4 X11 - XQuartz
DStyle: Braces on same line
Hi, I noticed that in Andrei's talks and his book, he used braces on the same line of delcaration, however Phobos and other D libraries I know use braces on their own line. Now I'm in a position where I need to take decision on coding style of my library and I get accustomed to use braces on same line but I'm worried if that would make my library less readable to other D users. Should I worry about it? Or is that's just a debatable style that won't really matter if it's persistent throughout library? Thanks
