Re: DConf 2013 Day 3 Talk 3: D-Specific Design Patterns by David Simcha
On 6/15/13 2:36 AM, Andrei Alexandrescu wrote: On 6/14/13 10:08 PM, Nick Sabalausky wrote: On Fri, 14 Jun 2013 11:15:08 +0200 Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Please vote and discuss on the social channels. The [HD] archive.org link doesn't appear to be working. Or is that just a delay on their end? It's a delay on my end. I am currently traveling to NDC 2013 (where I gave a talk on D, see http://ndcoslo.oktaset.com/Agenda/friday) and I need a stable connection to upload the file. Stay tuned. Andrei Uploaded: archive.org/details/dconf2013-day03-talk03 Andrei
Re: LDC 0.11.0 has been released!
David Nadlinger c...@klickverbot.at wrote in message news:qikvjtuajorstsxhh...@forum.dlang.org... Derp. Turns out that actually calling the newly added Expression::init during startup might be a good idea. That must have been interesting. They are never dereferenced, so no immediate crash, you'd just get whichever code path was tested first...
Re: DConf 2013 Day 3 Talk 3: D-Specific Design Patterns by David Simcha
On Fri, 14 Jun 2013 11:15:08 +0200 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Please vote and discuss on the social channels. Torrents/links up: http://semitwist.com/download/misc/dconf2013/
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Slowly catching up with published videos :) This has kind of convinced me that once D gets wider usage, tools similar to AnalyzeD may become de-facto standard part of any production toolchain, with a configurable rule set. D is complex and multi-paradigm language (which rocks) and any single project is likely to use only specific style subset (which is kind of hard to enforce). Once front-end parses becomes less coupled with rest of the compiler it should become more and more popular approach.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 2013-06-12 14:50, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle? -- /Jacob Carlborg
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 2013-06-14 17:13, Steven Schveighoffer wrote: With @UDAs, we have a lot of unrealized power for unit tests. I have asked for ModuleInfo to contain an rtInfo member [1], like TypeInfo does. With that, and possibly splitting the unit tests into individual functions (if not done already, I don't know), you have all you need to completely re-design the unit testing framework. It can even be runtime selectable. It would also be nice to not have to change the druntime to use RTInfo. Is that part of what you're suggesting? -- /Jacob Carlborg
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 2013-06-14 23:09, Leandro Lucarella wrote: Yes, I know. BTW, how many people is using it (if any)? If some could share the experience it would be appreciated. I use it :). My experience so far is if you don't take advantage of these buffers it can be a bit annoying. The reason is that most functions either return T[] or const(T)[]. If you use string in the rest of your code you cannot easily store a returned value to a string variable. I guess some of those could be fixed by returning inout(T)[] instead. Otherwise I think it's working good. -- /Jacob Carlborg
Re: LDC 0.11.0 has been released!
On Saturday, 15 June 2013 at 06:32:13 UTC, Daniel Murphy wrote: That must have been interesting. They are never dereferenced, so no immediate crash, you'd just get whichever code path was tested first... It was – especially because I was looking for a cause in the DMD/LDC diff first before actually starting to debug the CTFE code. Thinking about it, it might actually be a good idea to add in an assertion: https://github.com/D-Programming-Language/dmd/pull/2184 David
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/14/2013 11:03 AM, bearophile wrote: Don: I don't think contracts can be much use to a static analyzer if they can contain arbitrary code. The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few other systems that use the type system for similar reasons (Liquid Haskell, etc), use a very restricted expression language to state contracts. D is the only that uses free form D code. Eiffel can call arbitrary methods in contracts. I presented this problem to Walter lot of time ago in a post. He answered me that analysing a loop is not harder than analysing the all/any/exists used in those systems. I was never convinced by that. I still think there's one D design problem here. ... I disagree. The only problem is the verboseness of the contract system.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/15/2013 05:14 PM, Jacob Carlborg wrote: On 2013-06-12 14:50, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle? It bails out.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
Timon Gehr: Eiffel can call arbitrary methods in contracts. This is surprising. Maybe the Modern Eiffel is more strict. I disagree. The only problem is the verboseness of the contract system. If your contracts contain arbitrary D code, I don't think a static analyser will be able to use them. So it will give you a compilation error, or it will give a warning and then keep the contract as run-time test. In both cases this makes the static analysis much less useful. So you end using a subsed of the D syntax and D semantics. But then compilation becomes a try-and-guess, and different static analysers will digest different amounts of D syntax and semantics, causing those contracts to be not portable across static analysers. Both Ada and Liquid Haskell avoids all this. Bye, bearophile
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/16/2013 12:07 AM, bearophile wrote: Timon Gehr: Eiffel can call arbitrary methods in contracts. This is surprising. Maybe the Modern Eiffel is more strict. It's design isn't finished, but IIRC it enforces purity, contracts can be arbitrarily complex, and manual proofs are required. I disagree. The only problem is the verboseness of the contract system. If your contracts contain arbitrary D code, I don't think a static analyser will be able to use them. Why not? The static analyser obviously needs to analyse arbitrary D code anyway, unless it only analyses contracts, which is not useful. So it will give you a compilation error, or it will give a warning and then keep the contract as run-time test. It's unreasonable to expect that the static analyser will automatically prove all correct programs correct without manually provided evidence. This holds true independently of the format the contracts are specified in. In both cases this makes the static analysis much less useful. Than what? So you end using a subsed of the D syntax and D semantics. But then compilation becomes a try-and-guess, and different static analysers will digest different amounts of D syntax and semantics, Obviously. But not closely related to the way contracts are specified. causing those contracts to be not portable across static analysers. If those analysers all follow the same specification, they will be portable in any case. Both Ada Reference? and Liquid Haskell avoids all this. ... It does not make any sense to claim that Liquid Haskell avoids all this. It is not a programming language but a static verifier, AFAIK based on predicate abstraction.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
I don't understand this topic well enough, so I am not saying useful things. Thank you for your comments Timon... Bye, bearophile
Re: std.signals regressions
14.06.2013 18:31, David пишет:
This code currently fails with a RangeError (used to work in 2.062)
// http://dpaste.dzfl.pl/332a71ec
import std.stdio;
import std.signals;
struct X {
mixin Signal!();
}
class O {
void m() {}
}
void main() {
O o = new O();
X[string] aa;
aa[o] = X.init;
aa[o].connect(o.m);
/*{ // 20
X x = aa[o];
}*/
}
If you take the uncomment the block at line 20 you end up with a
segmentation fault, also worked in 2.062. Both times the problem is in
the __dtor (segfault happens in the call to _d_toObject(stor.ptr).
Changing struct to class and X.init to new X() it seems to work
as it should.
Is this worth a bugreport or was the old behaviour never intended?
This bug (I consider it one) broke quite a few lines of code... If the
old behaviour was never intended, why wasn't it documentated then... oh
well I am drifting into another D rant here...
http://dlang.org/phobos/std_signals.html#Signal
Mixin to create a signal within a class object.
So your `X` must be a class.
Also don't use std.signals - it's an incorrect and dangerous mess (see
bug tracker).
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Effective D book?
On 6/15/13 5:43 AM, Szymon Gatner wrote: Btw: Not sure if effective series isn't somehow propertiary and linked to Herb Sutter. I know he is not only responsible for c++ but also for c# version The Effective series at AWL is directed by Scott Meyers and would not preclude one from using the title elsewhere. That being said, I mentioned the book last night to Scott and he said if the author wants to publish it in that series, he'd be glad to look into it. Andrei
Re: reddit discussion on replacing Python in 0install
On 6/14/2013 10:45 PM, deadalnix wrote: I don't think any of the proposed fixes is a good idea. With he one you are pushing for, the program can fail behind the feet of the programmer, which is not better. Please explain.
Re: Effective D book?
On 06/14/2013 07:17 PM, Jonathan M Davis wrote: It'll probably be the first book ever to be written entirely in ddoc. The first ddoc book was a D book as well: ;) http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opapply.d Ali
Re: Effective D book?
On Saturday, June 15, 2013 00:26:55 Ali Çehreli wrote: On 06/14/2013 07:17 PM, Jonathan M Davis wrote: It'll probably be the first book ever to be written entirely in ddoc. The first ddoc book was a D book as well: ;) http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opa pply.d So, you wrote your book with ddoc? I didn't know that. That's cool. It's a lot more versatile than you'd initially think. - Jonathan M Davis
Another company using D
Just viewed on reddit: –]peterlundgren 6 points 10 heures de ça I keep getting more and more jealous of the few developers out there who are getting paid to write software in D. perma-liensignalergive goldrépondre [–]MrJNewt 7 points 10 heures de ça I write D all day at Economic Modeling Specialists (www.economicmodeling.com) and we're always interested in resumes from experienced developers who know or want to learn D. I wonder how many companies are using the language in production right now. Should we start a page They're using D somewhere ?
Re: Another company using D
On Saturday, 15 June 2013 at 08:04:08 UTC, SomeDude wrote: Just viewed on reddit: Forgot: http://www.reddit.com/r/programming/comments/1gbu3c/dconf_2013_dspecific_design_patterns_by_david/ (super interesting talk BTW)
Re: Effective D book?
On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not D Best Practices? Or D Patterns and Practices ? With some David Simcha content in it (if he agrees with that of course).
Presentation from conference
Where I can download PowerPoint presentations from DConf?
Re: Presentation from conference
On Saturday, 15 June 2013 at 08:20:22 UTC, Suliman wrote: Where I can download PowerPoint presentations from DConf? See the slides links here: http://dconf.org/schedule/index.html
Re: reddit discussion on replacing Python in 0install
On Saturday, 15 June 2013 at 06:49:00 UTC, Walter Bright wrote: On 6/14/2013 10:45 PM, deadalnix wrote: I don't think any of the proposed fixes is a good idea. With he one you are pushing for, the program can fail behind the feet of the programmer, which is not better. Please explain. The solution that consist in flushing at first use is a surprising behavior, and look more like a weird hack than a solution. The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote.
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that would use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I presume a,
b and c are defined somewhere and eval solves for x?
Re: Why doesn't symbol wheelbarrowing work with function templates?
On Friday, 14 June 2013 at 05:36:32 UTC, Timon Gehr wrote:
On 06/13/2013 11:53 AM, TommiT wrote:
symbol wheelbarrowing = making symbols in other module(s)
local to
the current module
(described in TDPL at page 148)
The problem:
---
...
1. alias main.bar conflicts with alias main.bar
Compiler bug.
Would you also go as far as to say that you'd expect the
following to be perfectly valid D code?
-
module a;
void foo(T : int)() { }
-
module b;
void foo(T : string)() { }
-
module main;
import std.stdio;
import a;
import b;
alias foo = a.foo;
alias foo = b.foo; // [1]
void main()
{
foo!int();
foo!string();
}
-
1) Error: alias main.foo conflicts with alias main.foo
Re: reddit discussion on replacing Python in 0install
On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended?
Re: reddit discussion on replacing Python in 0install
On Saturday, 15 June 2013 at 09:48:59 UTC, Walter Bright wrote: On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended? From programmer's perspective.
Re: reddit discussion on replacing Python in 0install
On 6/15/2013 3:04 AM, deadalnix wrote: On Saturday, 15 June 2013 at 09:48:59 UTC, Walter Bright wrote: On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended? From programmer's perspective. I'm sorry, that makes no sense to me. In fact, this thread started out reporting an article by a programmer who was unhappy that the program exited normally but the output didn't happen. Defaulting to ignoring errors and blithely proceeding is not usually considered a best practice.
Re: reddit discussion on replacing Python in 0install
On Saturday, 15 June 2013 at 10:08:38 UTC, Walter Bright wrote: On 6/15/2013 3:04 AM, deadalnix wrote: On Saturday, 15 June 2013 at 09:48:59 UTC, Walter Bright wrote: On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended? From programmer's perspective. I'm sorry, that makes no sense to me. That is because you aren't reading what is written. See 2/ Defaulting to ignoring errors and blithely proceeding is not usually considered a best practice. I have never written that. That explains 1/
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 08:46:13 UTC, John Colvin wrote:
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that would use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I presume
a, b and c are defined somewhere and eval solves for x?
algor.brute does the work. IF you know that algorithm you would
know what it does.
Another question would be if this way of coding makes sense to
you.
This is what the eval function does ( in theory ), It takes The
words : Real, Rational, Irrational or R, Q , Q' and from there is
defined which numerical group is going to be used for the
evaluation. Then it identifies the operators and variables and
defines the equation in a format like a text format with a end
file character in the end so equations can be as long as you
want. After that between {algor.(name)} in name you call the
algorithm you want to use for the evaluation there can be
predefined algorithm with D but maybe you can define your own
algorithms.
What do you think does this makes sense or would you implement it
other way ?
Re: Formal Review of std.serialization
On 2013-06-10 18:11, Jesse Phillips wrote: Today we start the formal review of std.serialization (Orange). This library is authored by Jacob Carlborg and has been around through the D1/Tango days. Please take some time in the next 2 weeks to provide feedback on the library. Some things to know (from http://forum.dlang.org/thread/kinpnv$ven$1...@digitalmars.com) I have finally been able to generate the documentation with the proper styles: file:///Users/doob/Dropbox/Public/docs/std.serialization/index.html -- /Jacob Carlborg
Re: Formal Review of std.serialization
On 2013-06-15 13:53, Jacob Carlborg wrote: file:///Users/doob/Dropbox/Public/docs/std.serialization/index.html Of course I copied the wrong link :( Here's the correct one: https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html -- /Jacob Carlborg
Re: reddit discussion on replacing Python in 0install
On 6/15/13 12:04 PM, deadalnix wrote: On Saturday, 15 June 2013 at 09:48:59 UTC, Walter Bright wrote: On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended? From programmer's perspective. You may want to discuss alternative solutions in the bug report: http://d.puremagic.com/issues/show_bug.cgi?id=10344 Thanks, Andrei
Re: Presentation from conference
Watch out though, the power point's were butchered into PDF files! ;) On 15 June 2013 18:27, simendsjo simend...@gmail.com wrote: On Saturday, 15 June 2013 at 08:20:22 UTC, Suliman wrote: Where I can download PowerPoint presentations from DConf? See the slides links here: http://dconf.org/schedule/**index.htmlhttp://dconf.org/schedule/index.html
Re: Effective D book?
On 06/15/2013 03:02 AM, Walter Bright wrote: On 6/14/2013 11:29 AM, monarch_dodra wrote: In particular, while *stable*, it *is* still evolving, which means that while the old code still works, the patterns are still shifting. One example of that is Andrei and I have been discussing the idea of moving import declarations from their traditional place at the top of the file to being in the most nested scope in which they are referenced. One issue with local imports is that they hide local symbols.
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 11:44:03 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 08:46:13 UTC, John Colvin wrote:
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that would
use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I presume
a, b and c are defined somewhere and eval solves for x?
algor.brute does the work. IF you know that algorithm you would
know what it does.
Another question would be if this way of coding makes sense to
you.
This is what the eval function does ( in theory ), It takes
The words : Real, Rational, Irrational or R, Q , Q' and from
there is defined which numerical group is going to be used for
the evaluation. Then it identifies the operators and variables
and defines the equation in a format like a text format with a
end file character in the end so equations can be as long as
you want. After that between {algor.(name)} in name you call
the algorithm you want to use for the evaluation there can be
predefined algorithm with D but maybe you can define your own
algorithms.
What do you think does this makes sense or would you implement
it other way ?
D provides no such thing. AFAIK, there is nothing in Phobos
provided that does it either.
It should be doable, where the second argument is a string.
Something like:
auto eq = Equation(Real, a+b^^x+c=56);
auto result = Equation.brute();
I think it would quite a specialized numerical library though, so
I don't think it would find its way into the standard library.
I'm not sure any such D Library exists. You'll either have to
port an existing library, or link with a C/C++ existing library.
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 12:36:26 UTC, monarch_dodra wrote:
On Saturday, 15 June 2013 at 11:44:03 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 08:46:13 UTC, John Colvin wrote:
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that would
use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I
presume a, b and c are defined somewhere and eval solves for
x?
algor.brute does the work. IF you know that algorithm you
would know what it does.
Another question would be if this way of coding makes sense to
you.
This is what the eval function does ( in theory ), It takes
The words : Real, Rational, Irrational or R, Q , Q' and from
there is defined which numerical group is going to be used for
the evaluation. Then it identifies the operators and variables
and defines the equation in a format like a text format with a
end file character in the end so equations can be as long as
you want. After that between {algor.(name)} in name you call
the algorithm you want to use for the evaluation there can be
predefined algorithm with D but maybe you can define your own
algorithms.
What do you think does this makes sense or would you implement
it other way ?
D provides no such thing. AFAIK, there is nothing in Phobos
provided that does it either.
It should be doable, where the second argument is a string.
Something like:
auto eq = Equation(Real, a+b^^x+c=56);
auto result = Equation.brute();
I think it would quite a specialized numerical library though,
so I don't think it would find its way into the standard
library.
I'm not sure any such D Library exists. You'll either have to
port an existing library, or link with a C/C++ existing library.
OK but if developed it would be included in D ? Right ? It would
be very useful I think.
Re: std.signals regressions
15.06.2013 14:19, David пишет: http://dlang.org/phobos/std_signals.html#Signal Mixin to create a signal within a class object. So your `X` must be a class. Oh right I have totally overseen that, still used to work really well with 2.063 It can work only by accident iff the struct isn't moved in memory no matter what compiler version you use. Also don't use std.signals - it's an incorrect and dangerous mess (see bug tracker). Provide me something better in phobos and so far it works pretty good (except the update breaking struct-signals) Currently there is no working signals implementation in Phobos. The worst thing about the current implementation is it will fail you program accidentally in rare cases. Don't use it. For issues, see: http://d.puremagic.com/issues/show_bug.cgi?id=4150 http://d.puremagic.com/issues/show_bug.cgi?id=9606 http://d.puremagic.com/issues/show_bug.cgi?id=9603 Also post to NG instead of emailing directly to allow others to follow the discussion. Also if you _do_ need working signals I can help a with implementation. -- Денис В. Шеломовский Denis V. Shelomovskij - Regarding E-mailing, sorry about that, I hate the thunderbird answer button It can work only by accident iff the struct isn't moved in memory no matter what compiler version you use. This worked for at least 3 compiler versions now I am aware of all of these bugs, none are critical if you know them 4150: use only class methods as event handlers 9606: emitting signals from a different thread would segfault in my application anayways (opengl code) 9603: basically same as 4150 Also wasn't there a std.signals2 somewhere...
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 13:23:07 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 12:36:26 UTC, monarch_dodra wrote:
On Saturday, 15 June 2013 at 11:44:03 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 08:46:13 UTC, John Colvin wrote:
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that would
use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I
presume a, b and c are defined somewhere and eval solves for
x?
algor.brute does the work. IF you know that algorithm you
would know what it does.
Another question would be if this way of coding makes sense
to you.
This is what the eval function does ( in theory ), It takes
The words : Real, Rational, Irrational or R, Q , Q' and from
there is defined which numerical group is going to be used
for the evaluation. Then it identifies the operators and
variables and defines the equation in a format like a text
format with a end file character in the end so equations can
be as long as you want. After that between {algor.(name)} in
name you call the algorithm you want to use for the
evaluation there can be predefined algorithm with D but maybe
you can define your own algorithms.
What do you think does this makes sense or would you
implement it other way ?
D provides no such thing. AFAIK, there is nothing in Phobos
provided that does it either.
It should be doable, where the second argument is a string.
Something like:
auto eq = Equation(Real, a+b^^x+c=56);
auto result = Equation.brute();
I think it would quite a specialized numerical library though,
so I don't think it would find its way into the standard
library.
I'm not sure any such D Library exists. You'll either have to
port an existing library, or link with a C/C++ existing
library.
OK but if developed it would be included in D ? Right ? It
would be very useful I think.
Depends what you mean by included in D ? In the standard
library, I wouldn't know (but I don't think so). But that doesn't
mean it couldn't be distributed as a trusted and reliable third
party library.
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 13:23:07 UTC, Carlos wrote: OK but if developed it would be included in D ? Right ? It would be very useful I think. It could be useful, but only in a very specific type of program, so it's unlikely that it would be bundled with the D compiler. It would almost certainly be distributed as a separate download from its own site.
Re: Effective D book?
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
Re: Effective D book?
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
void writeln(string) {}
void main()
{
import std.stdio;
writeln(foo);
std.stdio.writeln(bar);
}
?
Re: Effective D book?
On Fri, Jun 14, 2013 at 11:15:14PM -0400, Jonathan M Davis wrote: On Friday, June 14, 2013 19:57:52 Walter Bright wrote: Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc so that it can easily be converted into latex, html, and e-book formats rather than being tied to any particular format (I was going to use latex, but Andrei thought that a macro language would be better as latex is very tied to physical print and fixed layouts). It'll probably be the first book ever to be written entirely in ddoc. This is just being a win all around! My one major complaint about using ddoc is the need for the $(P ) macro everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should probably create an enhancement request for that (and maybe even try and implement it), but I have enough to do right now that I decided that I'd just put up with it for now. But aside from the need for $(P ) macros, it's actually quite pleasant to work with. I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of .\ after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type? I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. [...] Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output? T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius
Re: Effective D book?
On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander
wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
void writeln(string) {}
void main()
{
import std.stdio;
writeln(foo);
std.stdio.writeln(bar);
}
Oh, but that's not a local symbol, that's a module level symbol.
The import is more local that the module level writeln, so that
works as you would expect.
It also isn't a problem at all, because you can easily refer to
the module level symbol by fully qualifying it.
module thismodule;
void writeln(string) {}
void main()
{
import std.stdio;
thismodule.writeln(foo);
std.stdio.writeln(bar);
}
In any case, I'd recommend explicitly choosing which symbols to
import in the local import to avoid name clashes.
Re: reddit discussion on replacing Python in 0install
On 6/15/2013 3:24 AM, deadalnix wrote: On Saturday, 15 June 2013 at 10:08:38 UTC, Walter Bright wrote: On 6/15/2013 3:04 AM, deadalnix wrote: On Saturday, 15 June 2013 at 09:48:59 UTC, Walter Bright wrote: On 6/15/2013 1:36 AM, deadalnix wrote: The solution that consist into flushing in main at the end of the program is problematic as well. At this point, from programmer perspective, the program ran fun and is terminated successfully. Still the whole stuff will explode under its feet, in the runtime. That isn't something we should promote. If the output failed to happen, how could the program have successfully behaved as intended? From programmer's perspective. I'm sorry, that makes no sense to me. That is because you aren't reading what is written. See 2/ Defaulting to ignoring errors and blithely proceeding is not usually considered a best practice. I have never written that. That explains 1/ I have no idea what you're talking about.
Re: Expression evaluation order
On Friday, 14 June 2013 at 09:59:07 UTC, Iain Buclaw wrote: Interesting, that certainly doesn't flag up as a regression in the 2.063 merge in GDC... :o) However yes, the behaviour relies on the order the sucky X86 ABI pushes arguments onto the stack (which for this array op is from right to left). Whereas on *all* other architectures it will execute the parameters in left to right order, which would be a, c, b in this case. In LDC, the actual evaluation order is completely separate from the target ABI (you simply pass the SSA vales to a function call in LLVM, and you can decide the order in which to create them yourself). Turns out that for array operations, we actually need to reverse the order compared to our normal one (left to right), as their signatures have specifically been chosen for the evaluation order in DMD that is intertwined with the backend ABI/function call implementation details. David
Re: Automatic Equation and Inequation evaluation.
On Saturday, 15 June 2013 at 14:42:38 UTC, monarch_dodra wrote:
On Saturday, 15 June 2013 at 13:23:07 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 12:36:26 UTC, monarch_dodra wrote:
On Saturday, 15 June 2013 at 11:44:03 UTC, Carlos wrote:
On Saturday, 15 June 2013 at 08:46:13 UTC, John Colvin wrote:
On Saturday, 15 June 2013 at 02:05:00 UTC, Carlos wrote:
I'm interested in this kind of functionalities; Does D have
something on this ?
I thought about something like a eval function that
would use
specified algorithms.
something likes this
import std.stdio, std.math, std.eval;
void main()
{
eval(Real; a+b^^x+c=56){
algor.brute(result);
}
writeln(Positive value is : , result);
}
It's not clear what that would do from your example. I
presume a, b and c are defined somewhere and eval solves
for x?
algor.brute does the work. IF you know that algorithm you
would know what it does.
Another question would be if this way of coding makes sense
to you.
This is what the eval function does ( in theory ), It
takes The words : Real, Rational, Irrational or R, Q , Q'
and from there is defined which numerical group is going to
be used for the evaluation. Then it identifies the operators
and variables and defines the equation in a format like a
text format with a end file character in the end so
equations can be as long as you want. After that between
{algor.(name)} in name you call the algorithm you want to
use for the evaluation there can be predefined algorithm
with D but maybe you can define your own algorithms.
What do you think does this makes sense or would you
implement it other way ?
D provides no such thing. AFAIK, there is nothing in Phobos
provided that does it either.
It should be doable, where the second argument is a string.
Something like:
auto eq = Equation(Real, a+b^^x+c=56);
auto result = Equation.brute();
I think it would quite a specialized numerical library
though, so I don't think it would find its way into the
standard library.
I'm not sure any such D Library exists. You'll either have to
port an existing library, or link with a C/C++ existing
library.
OK but if developed it would be included in D ? Right ? It
would be very useful I think.
Depends what you mean by included in D ? In the standard
library, I wouldn't know (but I don't think so). But that
doesn't mean it couldn't be distributed as a trusted and
reliable third party library.
I mean that anyone with the code can use it without installing
anything but the compiler package. And third party could be the
first choice before it could be included.
Re: Expression evaluation order
On 06/15/2013 04:21 AM, Jonathan M Davis wrote: On Saturday, June 15, 2013 01:46:49 Timon Gehr wrote: On 06/14/2013 02:13 AM, Jonathan M Davis wrote: ... Personally, I would expect it to fully evaluate the right-hand side of an assignment expression before evaluating anything on the left, and I'd expect the same of any operator which is right-associative, ... Why? Associativity is unrelated to evaluation order. It seems natural to me that the stuff on the associated side would be evaluated before the stuff on the other, but that doesn't mean that it's the best way to go. It's just what I would have expected. So, if there's a good reason to do it differently, then I don't necessarily have a problem with that. - Jonathan M Davis Well, I can't think of a _good_ reason now. :) Since Walter once stated that evaluation is supposed to be LTR, this is what I have implemented for CTFE. The stack-based bytecode interpreter already relies on having the address-related information pushed before the value, and changing the evaluation order would therefore imply a little work.
Re: Expression evaluation order
On 15 June 2013 18:16, David Nadlinger c...@klickverbot.at wrote: On Friday, 14 June 2013 at 09:59:07 UTC, Iain Buclaw wrote: Interesting, that certainly doesn't flag up as a regression in the 2.063 merge in GDC... :o) However yes, the behaviour relies on the order the sucky X86 ABI pushes arguments onto the stack (which for this array op is from right to left). Whereas on *all* other architectures it will execute the parameters in left to right order, which would be a, c, b in this case. In LDC, the actual evaluation order is completely separate from the target ABI (you simply pass the SSA vales to a function call in LLVM, and you can decide the order in which to create them yourself). Turns out that for array operations, we actually need to reverse the order compared to our normal one (left to right), as their signatures have specifically been chosen for the evaluation order in DMD that is intertwined with the backend ABI/function call implementation details. We don't have that luxury, but as I said in the last thread brought up on this some time ago, for extern(D) we just make temporaries and compound them all together (_a = a(), _b = b(), _c = c(), _arrayop(_a, _b, _c)); There's no reason why this can't be done for extern (C) - other than it will break a load of code that relies on X86 ABI behaviour (such as what array operations apparently do...) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Expression evaluation order
On 06/15/2013 07:44 PM, Timon Gehr wrote: ... It seems natural to me that the stuff on the associated side would be evaluated before the stuff on the other, but that doesn't mean that it's the best way to go. It's just what I would have expected. So, if there's a good reason to do it differently, then I don't necessarily have a problem with that. - Jonathan M Davis Well, I can't think of a _good_ reason now. :) ... Correction: The conditional operator is right-associative, but evaluation necessarily proceeds LTR.
Re: Expression evaluation order
On 6/13/2013 11:14 PM, monarch_dodra wrote: 3) specifically unspecified 3.5) error when compiler sees ambiguity I'm personally in favor of 3, with some 3.5 as a warning. Having a warning for that is boy who cried wolf, as most functions have side effects and any expression like: f() + g() would generate such a warning.
Re: Expression evaluation order
On Saturday, 15 June 2013 at 17:50:39 UTC, Walter Bright wrote: On 6/13/2013 11:14 PM, monarch_dodra wrote: 3) specifically unspecified 3.5) error when compiler sees ambiguity I'm personally in favor of 3, with some 3.5 as a warning. Having a warning for that is boy who cried wolf, as most functions have side effects and any expression like: f() + g() would generate such a warning. Well, why would that throw a warning? I didn't mean expressions that *could* raise an ambiguity, but when the compiler *catches* that there *will* be ambiguity.
Re: Request for review - std.serialization (orange)
On Sunday, 24 March 2013 at 21:03:59 UTC, Jacob Carlborg wrote: std.serialization (orange) is now ready to be reviewed. I'm fundatemtaly agaisnt the integration of Orange into the std lib. The basic problem is that there is no flag in the D object model for the serialization (e.g: the published attribute in Pascal). In the same order of idea, the doc about RTI is null. In fact there's even no RTI usefull for an academic serialization system. No no no.
Re: Effective D book?
On Saturday, June 15, 2013 08:55:11 H. S. Teoh wrote: I'm curious about how you manage to factor out / abstract away the niggling details of LaTeX, like the use of .\ after an abbreviation (to make it produce only an inter-word space, as opposed to the extra space at the end of a sentence), m-dash vs. n-dash, etc., some of which are quite specific to LaTeX but are quite necessary if you're going for print-quality typesetting. And what about embedded \footnote's? Section references? Do you have macros for all of them? Does it make it a bit cumbersome to type? I'm early enough in the process that I haven't done much with those yet, and I'm likely to have to go back and fix that sort of thing up later (especially since about all I've done with LaTeX previously is write papers for college, and I didn't necessarily have to get everything as nice and exact as you would for a published book, so I'd likely be screwing some of that up even if I were writing directly in LaTeX). I expect to be using macros for them, but since you have to mark them up when writing in LaTeX anyway, it's not like I lose much using ddoc instead. It's just that the syntax changed. But it may be that if some of those can be automated, I'll end up doing something in the build script to manipulate the text to add that markup for me rather than using macros directly. I'll worry about that level of typesetting later. I wouldn't be worrying about that now even if I were writing directly in LaTeX. And ddoc macros will easily allow me to add it all later. It's just that the ddoc files for stuff like html and epub will ignore them. I don't really need to create something which is completely target-agnostic. I just need to create something that easily converts to all of the target formats that I need. And ddoc will do that just fine. I do have to process the ddoc before giving it to the compiler in order to generate the table of contents and index macros (since you can't generate those with just macros), but since I'm using a D script to do the build, that was actually pretty easy. [...] Isn't \tableofcontents enough to auto-generate the table of contents? Or are you talking about doing that for HTML output? LaTeX will autogenerate the table of contents and the index, but html won't (and I don't think that something like epub will either, but I haven't gotten around to generating that yet). So, I have to generate the whole thing as macros, which the latex.ddoc file mostly gets rid of, and the html.ddoc file replaces with the appopriate text and links. - Jonathan M Davis
Re: Request for review - std.serialization (orange)
On 2013-06-15 20:54, Baz wrote: I'm fundatemtaly agaisnt the integration of Orange into the std lib. The basic problem is that there is no flag in the D object model for the serialization (e.g: the published attribute in Pascal). Why does that matter? -- /Jacob Carlborg
Re: Request for review - std.serialization (orange)
On Saturday, 15 June 2013 at 18:54:35 UTC, Baz wrote: The basic problem is that there is no flag in the D object model for the serialization Yep, and std.serialization adds it, via UDA. In the same order of idea, the doc about RTI is null. In fact there's even no RTI usefull for an academic serialization system. RTI (rtti) is hardly relevant here, as far as I can see, std.serialization does static reflection.
Re: ARM targetting cross-toolchain with GDC
Am Thu, 13 Jun 2013 22:19:10 +0200 schrieb Andrey vangelisfore...@yandex.ru: On Thursday, 13 June 2013 at 16:00:34 UTC, Johannes Pfau wrote: Am Thu, 13 Jun 2013 16:28:19 +0200 schrieb Andrey vangelisfore...@yandex.ru: I have the same trouble. And I don't know how resolve it.. If you want to build a cross compiler targeting ARM/Linux follow these instructions: http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG This way you don't need to patch crosstool-NG and you can use the latest crosstool-NG release. Make sure to use gcc-4.7 (gcc-4.8 will work as well as soon as crosstool-NG supports it). I don't have a ready to use config though. Thank you for answer. The compilation of GDC for ARMv5TE has been done without any errors, and now I can't find native ARM libphobos to make my small ARM test. What shall I do? Сould you help me? Thanks. The linked howto explicitly disables phobos and druntime. To build phobos and druntime do not use the --disable-libphobos switch as said in the howto. However libphobos currently doesn't build for ARM, this patch is needed: https://github.com/D-Programming-Language/druntime/pull/521 Once it's accepted into upstream I'll backport it to gdc but this might take some time. You could of course apply these changes by yourself, then remove the --disable-libphobos switch and you should get a basically working phobos.
Re: Effective D book?
I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-)
Re: Effective D book?
On Saturday, 15 June 2013 at 19:52:45 UTC, matovitch wrote: I am referring to the beginning of this thread, but definitly wating for such a book to come out I have open a SO question (interactive media for a yet evolving langage) about effective design patterns and best practice in D. So if you have some clever methods you want to share, I am waiting for your answers. :-) the link : http://stackoverflow.com/questions/tagged/d (forget the obvious)
Re: Effective D book?
the 'true' link : http://stackoverflow.com/questions/17127251/effective-d-best-practices-and-design-patterns
Re: Effective D book?
On 06/15/2013 05:09 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
So does this:
void main(){
void writeln(string) {}
writeln(foo);
{
import std.stdio;
writeln(bar);
}
}
Re: Effective D book?
On 06/15/2013 06:06 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
void writeln(string) {}
void main()
{
import std.stdio;
writeln(foo);
std.stdio.writeln(bar);
}
Oh, but that's not a local symbol, that's a module level symbol. The
import is more local that the module level writeln, so that works as you
would expect.
It also isn't a problem at all, ...
It sure is, the module system is supposed to provide hijacking protection.
Re: Why doesn't symbol wheelbarrowing work with function templates?
On 06/15/2013 11:34 AM, TommiT wrote: On Friday, 14 June 2013 at 05:36:32 UTC, Timon Gehr wrote: On 06/13/2013 11:53 AM, TommiT wrote: symbol wheelbarrowing = making symbols in other module(s) local to the current module (described in TDPL at page 148) The problem: --- ... 1. alias main.bar conflicts with alias main.bar Compiler bug. Would you also go as far as to say that you'd expect the following to be perfectly valid D code? ... Yes, sure.
Re: Effective D book?
On 06/15/2013 05:09 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
More peculiar example:
void main(){
import std.stdio;
void writefx(string s){writeln(s);}
{
import std.stdio;
writefx(bar); // error: writefx is private
}
}
'writefx' happens to be a private symbol in std.stdio.
Feature request: Optional, simplified syntax for simple contracts
Simple things should be simple, complex things should be
possible. -Alan Kay
I'd like to simplify the syntax of function pre- and
post-conditions when the contract block consists of a single
assert statement. A special syntax for this special case would
omit all of the following:
1) the block's curly braces
2) the assert keyword
3) the semi-colon ending the assert statement
4) the body keyword (if and only if it follows right after the
block)
So, instead of writing this:
int func(int i)
in
{
assert(i 5);
}
out(r)
{
assert(r 9);
}
body
{
return i * 2;
}
...you'd be able to write this:
int func(int i)
in (i 5)
out(r) (r 9)
{
return i * 2;
}
Re: Why doesn't symbol wheelbarrowing work with function templates?
On Saturday, 15 June 2013 at 21:38:57 UTC, Timon Gehr wrote: On 06/15/2013 11:34 AM, TommiT wrote: Would you also go as far as to say that you'd expect the following to be perfectly valid D code? ... Yes, sure. I'll go ahead and file a bug report then if no-one tells me otherwise.
Re: Effective D book?
15-Jun-2013 12:07, SomeDude пишет: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not D Best Practices? Or D Patterns and Practices ? With some David Simcha content in it (if he agrees with that of course). IMHO D Cookbook sounds about right. -- Dmitry Olshansky
Re: Effective D book?
On Saturday, 15 June 2013 at 21:35:20 UTC, Timon Gehr wrote:
On 06/15/2013 05:09 PM, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln(foo);
std.stdio.writeln(bar);
}
This writes only bar.
More peculiar example:
void main(){
import std.stdio;
void writefx(string s){writeln(s);}
{
import std.stdio;
writefx(bar); // error: writefx is private
}
}
'writefx' happens to be a private symbol in std.stdio.
You might want to open a bug report for this.
David
Re: Effective D book?
On Sunday, June 16, 2013 01:55:35 Dmitry Olshansky wrote: 15-Jun-2013 12:07, SomeDude пишет: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not D Best Practices? Or D Patterns and Practices ? With some David Simcha content in it (if he agrees with that of course). IMHO D Cookbook sounds about right. Cookbook is in a similar situation with Effective, if not worse, as O'Reilly has a whole line of programming books with that name, and AFAIK, every programming book with Cookbook in its name has been published though them. So, an author who wanted to use that title would probably have to publish specifically through O'Reilly to get it into that series. However, from the looks of how the Cookbook books are supposed to be laid out, they really aren't intended for discussing best practices. They're for giving solutions to specific programming problems, with the idea that they contain a list of such recipes that you can look up to figure out how to solve common programming problems in the language or domain that the book covers. It would certainly be useful to have that sort of book for D, but I believe that it would be fundamentally different from what a book which might be published in the Effective series would contain. For the book that I'm working on, I'm really not going to worry about the title at this point. I'm just going to write it, and I'll worry about stuff like the title and who might publish it or anything along those lines once it's much closer to completion. - Jonathan M Davis
Re: Effective D book?
On Saturday, 15 June 2013 at 08:07:23 UTC, SomeDude wrote: On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not D Best Practices? Or D Patterns and Practices ? +1
Re: ARM targetting cross-toolchain with GDC
On Saturday, 15 June 2013 at 19:15:51 UTC, Johannes Pfau wrote: However libphobos currently doesn't build for ARM, this patch is needed: I independently did pretty much the same thing earlier today to build an arm cross compiler and got a working druntime (two more minor changes too, making a const object.toString and toHash was required to link, not sure why though) working ...except for one thing: throwing exceptions just ends the program with Aborted. It is possible I still did something wrong, since I built the druntime piece by piece after the fact instead of with crosstool-ng, but have you experienced this before?
Re: Effective D book?
On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is.
Re: ARM targetting cross-toolchain with GDC
nvm, I figured it out. I didn't pass the right ABI version when building runtime, so my fault. This is pretty exciting though, D is working and it wasn't really *that* much effort!
Re: Feature request: Optional, simplified syntax for simple contracts
Super awesome idea! How about coma separated expressions to perform
multiple asserts?
int func(int i, int j) in(i5, j10)
{
return i + j;
}
On 16 June 2013 07:45, TommiT tommitiss...@hotmail.com wrote:
Simple things should be simple, complex things should be possible. -Alan
Kay
I'd like to simplify the syntax of function pre- and post-conditions when
the contract block consists of a single assert statement. A special syntax
for this special case would omit all of the following:
1) the block's curly braces
2) the assert keyword
3) the semi-colon ending the assert statement
4) the body keyword (if and only if it follows right after the block)
So, instead of writing this:
int func(int i)
in
{
assert(i 5);
}
out(r)
{
assert(r 9);
}
body
{
return i * 2;
}
...you'd be able to write this:
int func(int i)
in (i 5)
out(r) (r 9)
{
return i * 2;
}
Re: Feature request: Optional, simplified syntax for simple contracts
On 06/16/2013 02:19 AM, Manu wrote:
Super awesome idea! How about coma separated expressions to perform
multiple asserts?
int func(int i, int j) in(i5, j10)
{
return i + j;
}
...
Use .
Re: Effective D book?
On 06/16/2013 01:36 AM, Walter Bright wrote: On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is. A module can introduce a new symbol and silently change what some identifier lookup refers to, where the previous symbol referred to resides in a different module.
Re: ARM targetting cross-toolchain with GDC
On 16 June 2013 01:05, Adam D. Ruppe destructiona...@gmail.com wrote: nvm, I figured it out. I didn't pass the right ABI version when building runtime, so my fault. This is pretty exciting though, D is working and it wasn't really *that* much effort! It's been a few years in the making. And there are still one or two things that need to be pushed upstream to the D front end. The last few months has been hugely beneficial for being architecture agnostic code generation. So every problem you encounter when targeting a new platform would hopefully be in relation to the druntime C interface, which if you have patches for please send my way. ;) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: ARM targetting cross-toolchain with GDC
On 16 June 2013 02:13, Iain Buclaw ibuc...@ubuntu.com wrote: On 16 June 2013 01:05, Adam D. Ruppe destructiona...@gmail.com wrote: nvm, I figured it out. I didn't pass the right ABI version when building runtime, so my fault. This is pretty exciting though, D is working and it wasn't really *that* much effort! It's been a few years in the making. And there are still one or two things that need to be pushed upstream to the D front end. The last few months has been hugely beneficial for being architecture agnostic code generation. So every problem you encounter when targeting a new platform would hopefully be in relation to the druntime C interface, which if you have patches for please send my way. ;) I would also invite you to run the test suite as well ( make check-d ) and post all failed and unresolved tests as new bugs, where possible providing minimal test cases that trigger the issue. Thanks -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Feature request: Optional, simplified syntax for simple contracts
On Sunday, 16 June 2013 at 00:19:37 UTC, Manu wrote:
Super awesome idea! How about coma separated expressions to
perform
multiple asserts?
int func(int i, int j) in(i5, j10)
{
return i + j;
}
Do you mean ...to get more specific error messages than with
in(i5 j10) ?
Re: Another company using D
On Saturday, 15 June 2013 at 08:04:08 UTC, SomeDude wrote: Should we start a page They're using D somewhere ? This page has been the only remaining red link on the new D wiki for a while, so I created it: http://wiki.dlang.org/Current_D_Use Feel free to add to it. However, is it OK to add companies to such a list just because one person mentioned their company was using D?
More Linux love?
Hi, I've been following D development for quite a bit of years now and it have always been the case that Linux was a second (or even third) class citizen in D-Lang world. I've always wondered when D is going to mature and gain more popularity and always attributed the problems with D catching up mostly for two things: * that it's was essentially developed by one man only; * that it neglected Linux; The first issue have changed some while ago, and I was very happy to hear that finally Walter somewhat embraced more distributed and open development model. D on github? Hell must have frozen over. -- I thought. And I think everyone could quickly see the results. Each of the latest releases seem like a big leap forward, not just small set improvements. But the later seems to be the same as it was. Yeah, DMD can generate x86_64 nowadays which I remember was a long time pending issue some while back and I can find `gdc` in the Ubuntu repository, which is huge improvement, but overall the impression is the same: D is Windows-centric. It seems to me that because historically D was Windows-centric, because Walter is Windows user, for all this years Windows developers had easier time when playing with D, than Linux devs. And after all this years, D community is mostly Windows-centric. Have anyone did any poll regarding this? I am guessing, I may be wrong. Each time I fell the urge to play with D in the free time and want to test newest, coolest features and projects written in D, I am constantly hitting some Linux-related issues. Library incompatibilities, path incompatibilities. I toy with a lot of languages and I never hit issues like this with eg. Rust or Go, which fall into similar category of programming languages. Both of them seem to be developed for Linux/Unix - first, Windows later. So I'd really like to ask all Windows-users D-developers: please install Virtual Box, latest Ubuntu guest inside, maybe Fedora too and see for yourself is your project is easy to install and working each time you release it. In my opinion in the last 15 years most of the noticeable, long lasting programming software improvements came from Linux/Mac world (Unix, generally speaking), but I am biased. But the fact is: Open Source and Linux is where young, eager to learn and risk devs and cool kids are. In great numbers. Embrace them, just like Open, Collaborative development model and you'll quickly see a lot of new cool projects, developers, bug fixes and buzz. :) PS. Kudos for whole D community, the language is even better and more impressive then it used to be.
Re: Effective D book?
On Sunday, 16 June 2013 at 00:42:15 UTC, Timon Gehr wrote: On 06/16/2013 01:36 AM, Walter Bright wrote: On 6/15/2013 2:34 PM, Timon Gehr wrote: It sure is, the module system is supposed to provide hijacking protection. Inner scopes override outer scopes. That isn't what hijacking is. A module can introduce a new symbol and silently change what some identifier lookup refers to, where the previous symbol referred to resides in a different module. It happen to me recently; the bug was very puzzling. I do think that identifier lookup should turtle down in the module before looking at imports.
Re: More Linux love?
But the later seems to be the same as it was. Yeah, DMD can generate x86_64 nowadays which I remember was a long time pending issue some while back and I can find `gdc` in the Ubuntu repository, which is huge improvement, but overall the impression is the same: D is Windows-centric. It seems to me that because historically D was Windows-centric, because Walter is Windows user, for all this years Windows developers had easier time when playing with D, than Linux devs. And after all this years, D community is mostly Windows-centric. Have anyone did any poll regarding this? I am guessing, I may be wrong. Each time I fell the urge to play with D in the free time and want to test newest, coolest features and projects written in D, I am constantly hitting some Linux-related issues. Library incompatibilities, path incompatibilities. I toy with a lot of languages and I never hit issues like this with eg. Rust or Go, which fall into similar category of programming languages. Both of them seem to be developed for Linux/Unix - first, Windows later. Well, there's at least a significant chunk of the community on Linux, judging by the LDC and GDC projects. I haven't had any major problems on Linux (I use Arch Linux), and DMD gets regular testing on Linux: http://d.puremagic.com/test-results/ (it even gets tested on FreeBSD =D). LDC's CI (travis-ci) only supports Linux, and Windows support is in an alpha state. A while ago I tried D on Windows and it wasn't nearly as nice as running on Linux. I don't use very many libraries (just some C bindings) and my projects aren't very complicated, so perhaps I haven't gotten to the point you're describing. So I'd really like to ask all Windows-users D-developers: please install Virtual Box, latest Ubuntu guest inside, maybe Fedora too and see for yourself is your project is easy to install and working each time you release it. I can agree with this, but there also aren't very many high-profile D libraries. Most developers seem to write something to scratch their own itch, and kudos if it happens to work for you. I would like to see a stronger library management solution, but there currently isn't a standard build tool (except maybe DSSS, but it seems abandoned). There's also dub (https://github.com/rejectedsoftware/dub), which looks promising or orbit (https://github.com/jacob-carlborg/orbit). Maybe the community will settle on one and this problem will magically go away? In my opinion in the last 15 years most of the noticeable, long lasting programming software improvements came from Linux/Mac world (Unix, generally speaking), but I am biased. But the fact is: Open Source and Linux is where young, eager to learn and risk devs and cool kids are. In great numbers. Embrace them, just like Open, Collaborative development model and you'll quickly see a lot of new cool projects, developers, bug fixes and buzz. :) I agree, but this also depends on your target market. For Windows, I guess you've forgotten .NET? A lot of the D community came from C++, and AFAICT Windows nearly dominates the commercial C++ market. All those C++ developers who got tired of C++'s warts came to D. Many other languages (Go, Ruby, Python, etc) are developed for users coming from C, Perl and Java, which have traditionally been *nix or cross-platform, so naturally development would happen on the platform they know better. That being said, D has pretty strong Linux support, and from what I've seen in the community, even the Windows users have a pretty solid knowledge of Linux; moreso than many other open-source programming language projects (many are ignorant of everything Windows). Personally, I think it's refreshing to have such strong Windows support, so when I need to make my project work on Windows, I know there's solid support in the community. Moving a node.js app from Linux to Windows was a bug-riddled experience because many of the libs didn't have proper Windows support (paths were just the tip of the iceburg). PS. Kudos for whole D community, the language is even better and more impressive then it used to be. I'm in a similar boat. I come back to the D community every few months and check back, and each time I run into less and less problems. There are still a lot of annoying things (CTFE, the garbage collector, no package manager), but these seem to be under pretty heavy development. Anyway, with the last couple of releases, I now feel comfortable recommending D to my friends. If D had a nice, stupid-simple build process (like Go's), then I may even become a fanboy. =D
Re: More Linux love?
On Sunday, 16 June 2013 at 03:25:19 UTC, Dawid Ciężarkiewicz wrote: So I'd really like to ask all Windows-users D-developers: please install Virtual Box, latest Ubuntu guest inside, maybe Fedora too and see for yourself is your project is easy to install and working each time you release it. Hi, no offense but your post comes to me like overly-biased flamebait. As a Windows user, my experience is quite opposite - most D users and developers are not using Windows, so Windows support was lagging behind in many instances. x64 came to Windows last. The Windows compiler is up to twice as slow than the Linux compiler (because it's compiled with DMC). The coverage of the OS API in the standard library/Druntime is underwhelming. GDC and LDC are starting to officially support Windows only just now. In contrast, deploying my D software on Linux servers is quite painless and straight-forward. Saying that D is neglecting Linux is an outright fabrication.
Re: More Linux love?
On Sunday, 16 June 2013 at 03:25:19 UTC, Dawid Ciężarkiewicz wrote: Hi, I've been following D development for quite a bit of years now and it have always been the case that Linux was a second (or even third) class citizen in D-Lang world. My main use of D has been Linux. Work is being done on shared libraries which has probably been the biggest missing support, but I think Windows has also had to bear some of it. Is it merely the lack of a dmd package in different distributions? Linux receive 64-bit support long before Windows. As for third party libraries, I'd say if it doesn't work for you in Linux, it also isn't working in Windows (Assuming it isn't a Windows library like Juno).
Re: More Linux love?
I use D on both Windows and Linux and I've *never* felt that D seemed Windows-centric, nor have I ever had Linux-centric problems with it.
Re: More Linux love?
Well, I can't tell much about the Windows experience, so might be that my experiences are misleading. Maybe I should try D on Windows and compare. I don't want to start a flamewar or anything. That's not my point.
hash for floating
Hi all, How to implement a proper hash method for a struct/class having as a base one or more floating point? When I compile with the -w flags, dmd 2.063 tells me that the function must be size_t toHash() const nothrow @safe. The point is that the nothrow doesn't permit the std.conv.to conversions, while the @safe does not permit the cast(). So how to perform a little math on the floating and then turning the result to a proper integer hash? Suggestions welcome! Thank! Paolo Invernizzi
Re: how should I implement this list?
Bedros:
I have a node of struct { ulong mask; ulong value};
now I need to create a list and insert that node; but first I
don't need duplicates, so, I first check if node already exists
in list.
I also need to traverse the list, and remove a node
currently I'm using dynamic array in D, but it's not efficient;
is there a better way to do the following
insert with no duplicates
remove
traverse
find
I read about containers in D, but the documentation is
confusing; and not sure if container implementation is mature.
BTW, my code will generate 100s of millions of nodes, and each
node on average is used once or twice then removed
Is the average number of items in the whole data structure
constant? How much do you have to transverse the data structure
(beside finding the duplications)? During such transversal do you
need to display items in some order?
Your needs are special, so I think you will have to try several
different data structures before finding the best one. Generally
linked lists are slow in transversals, have less cache coherence,
and give troubles to the GC making it work slowly.
A possible data structure for your needs is some kind of array of
pointers to short fixed sized arrays that also keep a count of
how many items each of them keeps, and keep them in a freelist.
But first try something simpler, like a dynamic array with
periodic holes, like on library shelves.
Bye,
bearophile
Re: hash for floating
On 06/15/2013 03:13 AM, Paolo Invernizzi wrote:
Hi all,
How to implement a proper hash method for a struct/class having as a
base one or more floating point?
When I compile with the -w flags, dmd 2.063 tells me that the function
must be size_t toHash() const nothrow @safe.
The point is that the nothrow doesn't permit the std.conv.to
conversions, while the @safe does not permit the cast().
So how to perform a little math on the floating and then turning the
result to a proper integer hash?
Suggestions welcome! Thank!
Paolo Invernizzi
I don't know whether it works correctly, but can you try calling
typeid(f).getHash(f):
import std.stdio;
struct S
{
float f;
int i;
const hash_t toHash() nothrow @safe
{
return typeid(f).getHash(f);
}
}
void main()
{
string[S] aa = [ S(0.5) : half, S(0.25) : quarter ];
aa[S(0.5)] = one over two;
aa[S(0.25)] = one over four;
writeln(aa);
}
Of course I have used exactly representable values 0.5 and 0.25 instead
of any other float value. Maybe you can afford to store such a value (in
addition to your actual float value) to be used for hashing.
Ali
Re: Fibers vs Async/await
*bump* On Tuesday, 11 June 2013 at 19:57:27 UTC, Jonathan Dunlap wrote: I was listening to one of the DConf sessions and where was some talk about implementing async from C# into D someday in the far future. Recently I learned about D's fibers... and it looks like the same thing to me. What are the major differences in principle? -Jonathan @jonathanAdunlap
Finalize GC memory
With the knowledge that 'delete' will be deprecated soon: Is there then still a way to finalize GC memory? I know it's unsafe etc. but is there a way? I know of 'destroy' but it does not finalize anything and AFAIK it's not safe and has also side effects. And it does not call the DTor if any struct is allocated with 'new'. I tried GC.free, GC.collect, destroy and a few other things, but except of 'delete' nothing finalize the memory. Thoughts?
Regarding Issue 9923
Don has rightly closed down this issue, but do you think here there's something worth opening a new Phobos issue here? http://d.puremagic.com/issues/show_bug.cgi?id=9923 Bye, bearophile
Why is this increasing memory consumption on every iteration?
I expected the memory to ramp up in the first couple iterations and eventually reach a stable point, but for some reason, windows task manager shows it increases on every iteration. Compiling with -m64 doesn't seem to change this issue. http://pastebin.com/G5JXR9AA
[Issue 10362] New: deprecation for enum members
http://d.puremagic.com/issues/show_bug.cgi?id=10362
Summary: deprecation for enum members
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2013-06-15 01:38:55 PDT ---
The obvious use case is to deprecate a renamed enum member.
enum Foo
{
bar,
deprecated(please use Foo.bar) Bar = bar,
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9662] rdmd should have a test suite
http://d.puremagic.com/issues/show_bug.cgi?id=9662 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-06-15 02:13:08 PDT --- (In reply to comment #2) Guys, how do I ignore the first line in the D tester when comparing against TEST_OUTPUT? I need to ignore the first line of --help here: rdmd build 20130614 Usage: rdmd [RDMD AND DMD OPTIONS]... program [PROGRAM OPTIONS]... Builds (with dependents) and runs a D program. Example: rdmd -release myprog --myprogparm 5 ... Because the build time changes often. In dmd/test/d_do_test.d, similar thing is already done. https://github.com/D-Programming-Language/dmd/blob/master/test/d_do_test.d#L434 Debug build DMD will print DMD v2.0xx DEBUG as the first compiler output. To skip it, d_do_test uses std.regex.replace. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10326] Disallow 'invariant' for immutable, allow class/struct invariants without (), and later disallow usage of ()
http://d.puremagic.com/issues/show_bug.cgi?id=10326 --- Comment #2 from github-bugzi...@puremagic.com 2013-06-15 02:55:27 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5479162eed97bd7107485437f15d426658e25a76 fix Issue 10326 - Change old `invariant` usage to error deprecation - error https://github.com/D-Programming-Language/dmd/commit/a9fa72432981719fa88a042d3f4649fca7ddf0fe Merge pull request #2160 from 9rnsr/fix10326 Issue 10326 - Change old `invariant` usage to error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10023] Add rtInfo (or equivalent) to ModuleInfo
http://d.puremagic.com/issues/show_bug.cgi?id=10023 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-06-15 04:29:04 PDT --- I think this is a significant feature, so I think it's better to explain better its advantages and usages (like for a unittest system). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10362] deprecation for enum members
http://d.puremagic.com/issues/show_bug.cgi?id=10362 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-06-15 08:00:30 PDT --- *** This issue has been marked as a duplicate of issue 9395 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
