Re: the disadvantage of D currently
On Fri, 15 May 2009 04:13:06 +0200, zsxxsz zhengshu...@hexun.com wrote: [...] Of course, all the disadvantages above may be solved in future, these are just the time problems. Well, and what do you do to help to solve these? -- Robert M. Münch Management IT Freelancer http://www.robertmuench.de
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
BCS wrote: Hello BLS, (I think it is not really top secret to talk about what is in use. 1) OCAML, 2) C and 3) ADA ... ) The only surprise there (if any) is OCAML. *Everyone* uses C and, last I heard, Ada is still the #1 choice for Bugs==DeadBodiesOrWorse development. From what I've heard, it's actually a darn nice language to work in if you are going to be doing all the engineering process stuff anyway. Hello BCS :) http://www.astree.ens.fr/ This is something Walter definitely should read too. What's the story : ASTRÉE is written in Objective Caml and is about 44000 lines long (plus external libraries). We needed a language with good performance (speed and memory usage) on reasonable equipment, easy support for advanced data structures, and type and memory safety. OCaml also allows for modular, clear and compact source code and makes it easy to work with recursive structures such as syntax trees Björn
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Georg Wrede wrote: It'd be nice if some of them came to this NG. will meet one of the leading guys this summer, let's see. (FWIW, I'd sure prefer to fly with ADA or D, than with C.) :-) So you better fly with Boeing ! ASTREE is a static analyzer for C programs that proves the absence of run-time errors in critical embedded software. It has been applied to the flight control software of the Airbus 340 and 380 airplanes. ASTREE is written in OCAML. // http://www.astree.ens.fr/ Björn
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Hello BLS, Georg Wrede wrote: (FWIW, I'd sure prefer to fly with ADA or D, than with C.) :-) So you better fly with Boeing ! ASTREE is a static analyzer for C programs that proves the absence of run-time errors in critical embedded software. It has been applied to the flight control software of the Airbus 340 and 380 airplanes. ASTREE is written in OCAML. // http://www.astree.ens.fr/ If you can *prove* it's correct, I don't care if it's in BF I'll fly on it over something you can't. OTOH I /think/ Ada programs can be written so they won't compile if they can't be proven to be correct, at some level.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
BLS wrote: Georg Wrede wrote: It'd be nice if some of them came to this NG. will meet one of the leading guys this summer, let's see. Excellent!! (FWIW, I'd sure prefer to fly with ADA or D, than with C.) :-) So you better fly with Boeing ! LOL ASTREE is a static analyzer for C programs that proves the absence of run-time errors in critical embedded software. It has been applied to the flight control software of the Airbus 340 and 380 airplanes. ASTREE is written in OCAML. // http://www.astree.ens.fr/ Yeah. In the old days there was an entire industry selling lint programs for C coders, and some of them cost more than a mid-size car. Then came C++, and the number of code lines written (in several languages) for the sole purpose of checking that the C++ program even remotely tries to do what it's supposed to, is simply disgusting. A programming language should make it possible to write code where the immediate purpose is clearly visible at a glance. I believe D is such a language. A professional programmer who /wants/ to code clearly, can do it. But with C++, I really don't think so.
Re: project oriented
On Tue, 12 May 2009 21:12:51 +, BCS wrote: Hello davidl, The module package system still stays in the state of the C age. It's file oriented. I think there's no more sound package system than C# one. The namespace and distributed packaging is a must nowadays and the compiler should be project oriented and take project information as the compiling base. Also an IDE is quite useful for providing project templates. The up side to file based packaging is that the compiler can find the files without needing extra information. There are several tools that can build a project from nothing but a set of .d files. With the c# type of system, the compiler/build system needs to have a metadata file that list all the .d files to be built adding yet another piece of redundant complexity. The c# solution works well if you will *only* develop from the IDE but is a total pain as soon as you need to work with non-language aware tools. Good point. I like the current system's simplicity, and changing it as suggested would add a lot of hassle.
Re: std.string and std.algorithm: what to do?
Andrei Alexandrescu wrote:
Daniel Keep wrote:
Steven Schveighoffer wrote:
On Thu, 14 May 2009 09:55:08 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Also, I dislike the signature int find() that returns -1 if not found.
Time and again experience shows that find() returning a range is much
better in real code because it works seamlessly when the
substring/element was not found (no more need for an extra test!)
Ech, returning -1 is the bane of Java and C#. The return value should
be the end of the string, regardless of whether it is a range or
index. I could never understand the mentality of returning -1 versus
end of
string.
-Steve
int idx = find(str);
if( idx == -1 ) doStuff;
- or -
if( idx == str.length ) doStuff;
I think Steve's point is that often you want to do something like:
auto before = str[0 .. find(str, something)];
or
auto after = str[find(str, something) .. $];
which behave nicely at limit conditions (when something isn't found). In
contrast, the version with -1 needs a separate varible and a test - a mess.
But most time, you want to know both _if_ something was found, and
where. Returning the length of the string makes checking if something
was found harder. That's also quite a mess.
Maybe a good way would be to return a pair of slices, before and after
something was found (ignoring that there are no MRVs):
(char[], char[]) myfind(char[] str, char[] tofind) {
int index = find(str, tofind); //returns str.length if not found
return str[0..index], str[index..$];
}
This would give the user lots of flexibility, without having to declare
useless temporaries, especially not for the first argument passed to
myfind().
For example: was something found?
bool found = myfind(bla, blubb)[1].length;
(That's still more elegant than to compare lengths.)
Andrei
Re: bmp/png libs?
Nick Sabalausky wrote: div0 d...@users.sourceforge.net wrote in message news:guirpq$m7...@digitalmars.com... Nick Sabalausky wrote: Can anyone suggest good up-to-date D libs or bindings for loading/saving bmp and png files? http://www.ssTk.co.uk/png.php Import is for d2, but changing it for d1 would be trivial. Ah, cool. -- My enormous talent is exceeded only by my outrageous laziness. Heh, I'm gonna have to steal that line, but slightly changed (disclaimer: this is not intended as an insult to you (only an insult to me ;) )): My enormous talent is exceeded only by my sheer arrogance. (Again, that's not intended as a jab at you, I just think that line would be hilarious :) ) :) share and enjoy. -- My enormous talent is exceeded only by my outrageous laziness.
Re: bmp/png libs?
Nick Sabalausky wrote: au was lossy? Yes, to the extend that it was compressed at all. Each 16 bit sample was independently reduced to 8 bits using a logarithmic scale. -- Rainer Deyke - rain...@eldwood.com
Re: bmp/png libs?
Nick Sabalausky wrote: div0 d...@users.sourceforge.net wrote in message news:guirpq$m7...@digitalmars.com... Nick Sabalausky wrote: Can anyone suggest good up-to-date D libs or bindings for loading/saving bmp and png files? http://www.ssTk.co.uk/png.php Import is for d2, but changing it for d1 would be trivial. Ah, cool. Thinking about it, if you do modify it for d1, send me the changed version and I'll merge it with a version block. Got a version of jpeg6b freeType as well. I'll upload them later once ftp access stops being a pig. -- My enormous talent is exceeded only by my outrageous laziness.
Re: Please Vote: Exercises in TDPL?
Sean Kelly wrote: I never bother to solve the exercises either, but then I've read most tech books on my own time. I think if you're hoping this might be used in an academic setting at some point (and I have no idea what the requirements are for that) then it would be good to have exercises. By the way, does TCPL have them? I'm pretty sure TC++PL doesn't. That's a good point, it will be helpful for courses. (but not a requirement) TC++PL does have exercises - at least the 3rd edition does, although they are not so prominent. I like to use exercises as review questions or summary, looking at them helps to get a feel for how much you've understood. Also, fun or really good exercises I will take, like the ones in SICP.
Re: Please Vote: Exercises in TDPL?
Brad Roberts wrote: BCS wrote: Hello Nick, (and double the price (or more) from what would typically be reasonable) I have been told (without supporting evidence) that the price of text books is so high because about 10 times as many are printed as sold. This is because they don't have time between when they know what they need and when they need it, to print what they need. The other 90% of the books you end up paying for get pulped. (That and the fact most profs never worry about what a book costs when they spend your money) The cost of printing, shipping, etc.. on a per-book basis is actually very very low. In the neighborhood of a few dollars. No where near the around $100 that a lot of textbooks sell for. One of the reasons they cost so much is that many of them are rev'ed every couple years, meaning that they have to make whatever profit they want to make _fast_. They're rev'ed so fast at least in part to kill off the used market. There's also an awful lot of effort that goes into producing them. Authors, Editors, fact checking, copy setting, etc. Anyway, it's an ugly cycle that's bound to implode eventually. Later, Brad Another contributing factor is that experts typically not want to write textbooks (boring), so they get paid very well to do it.
Re: Real Close to the Machine: Floating Point in D
Don wrote: Lars T. Kyllingstad wrote: Don wrote: Lars T. Kyllingstad wrote: Don wrote: Luís Marques wrote: A naive binary chop doesn't work correctly. The fact that there are hundreds or thousands of times as many representable numbers between 0 and 1, as there are between 1 and 2, is problematic for divide-and-conquer algorithms. A naive binary chop would divide the interval [0 .. 2] into [0 .. 1] and [1 .. 2]. Unfortunately, this is not a true binary chop, because the interval [0 .. 1] contains more than 99% of the representable numbers from the original interval! How about adding a template to do a binary chop (binary search?) to std.algorithm? findRoot() (which needs to be updated to take advantage of compiler improvements) does the job in the most important case. I'm quite proud of it; as far as I know, it's uses a better algorithm than anything else on the planet. g Awesome! I hadn't even noticed the std.numeric module before. :) Just a small comment: I think that the type of the function parameter should be templated as well, so that one can pass both functions, delegates and functors to it. Just now I tried to apply findRoot to an actual problem I'm working on, and immediately failed because I tried to pass a free function to it. A trivial thing to work around, but annoying nevertheless. How do you choose/limit what to put in std.numeric? I don't suppose you're going to put all of NETLIB in there... ;) Already, it seems to me that findRoot is somewhat niche for a standard library. I think it's one of a very small number of primitive math algorithms. It shows up _very_ frequently. In Tango, it's in tango.math.Bracket, along with a 1-D maximizer. (math.Bracket isn't a name I like very much). There's definitely an issue with Phobos' flat module organisation; it's not clear that Phobos can sensibly grow to be much more extensive than (say) the C standard library or the STL with that kind of structure. I'm convinced that implementation modules, at least, will need to go somewhere else. In my numerics library (which I've, in all modesty, named SciD) I'm converging on a package structure I'm fairly pleased with: scid.core: Internal modules, such as scid.core.traits, scid.core.tests, scid.core.exception, etc. scid.ports: Here I put ports of various packages from NETLIB and other sources. Examples of subpackages are scid.minpack, scid.quadpack, etc. These have, for the most part, rather nasty APIs, and should normally not be used directly. scid: In the root package I've placed the most ubiquitous modules, i.e. scid.vector, scid.transformation, etc. scid.calculus scid.calculus.differentiation scid.calculus.integration ... scid.linalg ... scid.nonlinear ... Specific problem areas get their own subpackages. At the moment these mostly just contain nicer interfaces to the routines in scid.ports -- drivers, if you will. I've tried a lot of setups, and this is the one I've found most flexible. The hierarchy isn't as shallow (and inextensible) as Phobos', nor is it as deep (and unwieldly) as Tango's. That sounds about right. But you might even consider dropping it down one level. For example, everyone knows that differentiation is calculus.differentiation; I think you only need a level when the module name is ambiguous on its own. (std.integration might be about Product Integration or something; but math.integration is unambiguous). Thanks, I'll keep that in mind. At one point I had to use several levels because I kept interfaces and implementations in the same modules, and the source files quickly became very large. Now that I've put the implementations in scid.ports, using one level is a lot more manageable. Whether I choose to use one or two levels, the idea is to mimic the structure of the GAMS classification tree. -Lars
Re: Please Vote: Exercises in TDPL?
Hello Nick, BCS n...@anon.com wrote in message news:a6268ff5d238cba2e80afc1...@news.digitalmars.com... Hello Nick, (and double the price (or more) from what would typically be reasonable) I have been told (without supporting evidence) that the price of text books is so high because about 10 times as many are printed as sold. This is because they don't have time between when they know what they need and when they need it, to print what they need. The other 90% of the books you end up paying for get pulped. I find that difficult (though not impossible) to believe. Most of the academic texts out there are just new editions that have barely anything changed, and not much content that really needs to be particularly timely either I'm referring to it going the other way, that the printing houses can't print and ship enough books between the time they known how many of what books they need and the start of classes to fill all the orders they get. So they have to have already printed and stocked everything before the orders come in. (Because of that, BTW, I'm convinced the updates are primarily done to curb the second-hand market. I've had plenty of profs require the latest edition when the last few editions turned out to be nearly identical). And even those updates don't happen every single school year. The same edition is usually still the newest for at least a couple years in a row, usually more. If they're ending up with so much extra stock, why not just sell that stock in the following years instead of pulping and printing new? It's not the ones that sell that they pulp, it the flops that no one would buy. Given than many (most?) books sold are sure things, that paints a very sad picture regarding the failure rate of new textbooks. If my numbers are correct, then each year (or three) 9 times as many new text book offerings flop as the number of books that sell, new and old. Or, if they really are ending up with 90% extra on such a regular basis, mabb it's time to re-evaluate how many they choose to print? It just doesn't seem to add up. But then again, nether do most things regarding academia. I'm probably repeating my self but, it's not that 90% of each title doesn't sell, it 90% of the titles offered don't sell and the rest sell out. Now if someone could find a better way to guess what new offerings would be flops
Re: Please Vote: Exercises in TDPL?
Hello Sean, Nick Sabalausky wrote: Cons: I've never been much of a fan of them. Rarely look at them, and never do them. But more than that, I find opening a book and seeing of bunch of exercises and end of chapter quizzes rather off-putting. I have a few books I bought largely for reference material where stuff was omitted and left as an exercise to the reader (I'm looking at you, Sedgewick!) Regardless of how easy some of these exercises may be for me to solve, it isn't something I'm generally in the mood for when I pick up the book at work to check something. However, this isn't a book about algorithms so perhaps this isn't an issue really. If the book has solutions, then they can server double duty as code examples.
Re: Migrating to Shared
Walter Bright wrote: bobef wrote: __gshared, __etc. These look ugly IMHO. :) They're only allowed in safe mode, and are meant to inspire people to use them only when there's no other choice. Hence the unattractiveness g Agreed. Yet as others have said, __traits deserves a beautiful keyword.
Re: std.string and std.algorithm: what to do?
Daniel Keep wrote: http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx Heh, that's a funny story. I didn't know that one. (I do think the sensible developer was a bit of a killjoy, though.) But how about coming up with some actual arguments here? What are the `gloves' in this situation? Don't say `modules' without explaining how they offer the same advantages as tags. I can imagine a similar discussion having taken place when someone thought of higher-level control-flow constructs (you know, `if' and `while'). I imagine most people were perfectly happy with goto's and conditional jumps. -- Michiel Helvensteijn
Re: Please Vote: Exercises in TDPL?
Nick Sabalausky wrote: You know, you've consistently been getting me impressed with your school ;) Caltech was it? I've been to a big public state university, a small supposedly well-respected private university, and a community college (that was highly-regarded, at least for a community college). I had many major issues with all of them (of course, I had major issues with K-12 as well ;) ). But, tech schools, I've never been to one (never got in, and they tend to be expensive anyway). I wonder if these things are specific to Caltech or if they tend to be typical of tech schools? I don't know if Caltech is typical or not. I went there kind of by happenstance, and was very lucky because their style suited my personality.
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu wrote: By the way. Is d2 focused? is it like a textbook or a reference book? D2 exclusively. Textbook modeled after KR. Will there be any GUI sections in D2 ? (or is that why they call it a textbook) --anders
Re: std.string and std.algorithm: what to do?
Michiel Helvensteijn wrote: Daniel Keep wrote: http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx Heh, that's a funny story. I didn't know that one. (I do think the sensible developer was a bit of a killjoy, though.) But how about coming up with some actual arguments here? What are the `gloves' in this situation? Don't say `modules' without explaining how they offer the same advantages as tags. You're proposing taking a simple, easy to understand module system and replacing it with a poor version of Google. Your idea requires that all modules be registered with the compiler somehow since there's now no correlation between module and file. Then you go on to suggest that you could use the filesystem, something which is blatantly not possible: WinXP doesn't support symbolic links. And this still means you can't simply drop a folder with source files into a project: you've got to screw around setting up symbolic links. Even then, what exactly does this get you? The ability to say: import std string; Now you have absolutely NO idea what you've just imported. You can't possibly look it up because anything could silently be included in that. And what happens when two libraries define two conflicting symbols? Now you've got to have some sort of disambiguation system. The tag system is the complicator's gloves: you're solving a problem which already has a simple working solution with the most complex system possible for no discernible benefit. Tags are great for when you have only a vague idea of what you're looking for. This might be pretty useful for searching docs, but it's completely unsuitable for actual code: you have to know what a function is called and what its arguments are before you call it. In order to find that out, you look up its documentation which ALSO tells you what module its in. And once you know what module a function's in, the tag system becomes completely superfluous and counter-productive. I can imagine a similar discussion having taken place when someone thought of higher-level control-flow constructs (you know, `if' and `while'). I imagine most people were perfectly happy with goto's and conditional jumps. You must be joking. Unstructured programming was a complete mess. You're actually proposing taking a structured system and replacing it with an unstructured one... the complete opposite of the introduction of flow control structures. -- Daniel
Re: Please Vote: Exercises in TDPL?
BCS n...@anon.com wrote in message news:a6268ff5d5a8cba307ba676...@news.digitalmars.com... Hello Nick, Or, if they really are ending up with 90% extra on such a regular basis, mabb it's time to re-evaluate how many they choose to print? It just doesn't seem to add up. But then again, nether do most things regarding academia. I'm probably repeating my self but, it's not that 90% of each title doesn't sell, it 90% of the titles offered don't sell and the rest sell out. Now if someone could find a better way to guess what new offerings would be flops Ahh, I see what you're saying. In that case, that (and the well-being of student's backs/spines everywhere) would be good reason for school textbooks to finally move to an electronic format (but of course, that has plenty of other downsides...)
Re: D1 and Phobos Fixes
Walter Bright wrote: Spacen Jasset wrote: This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. Many compiler patches get posted to bugzilla. About half of them are correct, the other half aren't (often fixing the symptom rather than the cause of the problem). Essentially, the compiler is fairly complicated and not well commented; I want to review any changes before they're committed. Otherwise I'll lose track of how it works and how it's supposed to work. Yes fair enough. What about phobos? Do many patches for phobos come in?
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:guitu0$op...@digitalmars.com... Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Looks like I'm not the only one that gets those books confused :). When Exceptional C++ was mentioned, I thought it was that C++ book you wrote. I think I breifly browsed through one or two of those E* C++ books before. Was very impressed with them (and also a similar book from a different publisher geared towards game dev), but I think my biggest take-away from all of them was, Alright, that's it, screw C++. ;) Then I found D. Not that the books were difficult or anything, in fact they did a great job of making an extremely complicated language as easy as possible. But they just made it finally click in my mind just what a PITA/POS C++ had become. Shit, I'm rambling again... ;)
A case for opImplicitCast: making string search work better
Consider this type:
struct StringPosition {
size_t pos;
void opImplicitCast(out size_t sz) {
sz = pos;
}
void opImplicitCast(out bool b) {
b = pos != -1;
}
}
Wouldn't that effectively sidestep most problems people have with find
returning -1?
Or am I missing something?
Of course, this would require a way to resolve ambiguities, i.e.
functions/statements with preferences - for instance, if() would prefer bool
over int. I don't know if this is possible.
Re: Wrt. threadlocal by default: shared module constructors
Christopher Wright wrote: Brad Roberts wrote: An interesting side effect of these changes is that thread startup cost is going to increase. Yet more reasons to avoid globals and global initialization. -- Brad It'll further promote use of threadpools. This isn't terribly safe because the globals for that thread are left in some arbitrary state -- yet more reason to avoid globals. Introspection would solve this. Just define a function initThread(), then use introspection to iterate over the module graph, find all static functions by that name, and call them whenever a thread needs to be cleaned up.
asm code and an inout function argument
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
Re: asm code and an inout function argument
Vladimir A. Reznichenko wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
Inout variables are pointers.
Re: asm code and an inout function argument
On Fri, 15 May 2009 22:29:07 +1200, Robert Fraser
fraseroftheni...@gmail.com wrote:
Vladimir A. Reznichenko wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
Inout variables are pointers.
Why is it 'inout' and not 'ref' ?
Re: asm code and an inout function argument
On Fri, 15 May 2009 14:24:16 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
I believe your code is incorrect. This is how it should be done:
import std.stdio;
void test (out uint a)
{
asm
{
mov EDX, a;
mov [EDX], 0x25;
}
}
void main()
{
uint a = 0;
test(a);
writefln(0x%x, a);
}
Perhaps, errors like yours could be flagged at compile time? If so, an
enhancement request would be nice.
Re: asm code and an inout function argument
Denis Koroskin Wrote:
On Fri, 15 May 2009 14:24:16 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
I believe your code is incorrect. This is how it should be done:
import std.stdio;
void test (out uint a)
{
asm
{
mov EDX, a;
mov [EDX], 0x25;
}
}
void main()
{
uint a = 0;
test(a);
writefln(0x%x, a);
}
Perhaps, errors like yours could be flagged at compile time? If so, an
enhancement request would be nice.
Thank you, Denis.
Re: asm code and an inout function argument
Tim Matthews Wrote:
On Fri, 15 May 2009 22:29:07 +1200, Robert Fraser
fraseroftheni...@gmail.com wrote:
Vladimir A. Reznichenko wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
Inout variables are pointers.
Why is it 'inout' and not 'ref' ?
Aren't they the same?
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. Well, you're not the average reader. :-) Reasons for including excercises o they're really needed for those who actually /study/ the stuff o KR, Stroustrup, Knuth had them!! Nobody's ever complained o when reading stuff /new/ to you, they're needed o the only way to get schools and unviersities to use the book o make them well, and it'll double the value of the book o increases sales and revenue o some learn by doing, especially the not-supertalented o no excercises is an obvious omission, attracts competitors Reasons against excercises o they take longer to write, if done well o you may need to test some of the excercises on people o done sloppily they'll reduce the value of the book o the answers need to explain stuff, not only be a listing The more people buy the book, the more money you get. And for us, the more D gets recognition inside and outside the academia, the better!! As a teacher, I'd never choose one without excercises. (Hell, then I'd have to invent them all, not just some. If that's a chore to you, it sure is a drag for the teacher!) IMO, it is *utterly* important that the book is usable in universities. The better universities pick it up, the others follow, and eventually we may have a chance of having D taught as the first computing language. (It certainly is better for that than the others, IMNSHO.) People also tend to have a mother tongue, even with computer languages. In 5..10 years, we want D to be *The* language, right? PS: write in the preface that you'd love teacher comments. You won't regret it, come time for the second edition!! You'll want to /maintain/ the head start you got, by refining the quality.
Re: asm code and an inout function argument
On Fri, 15 May 2009 14:41:35 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
Denis Koroskin Wrote:
On Fri, 15 May 2009 14:24:16 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
I believe your code is incorrect. This is how it should be done:
import std.stdio;
void test (out uint a)
{
asm
{
mov EDX, a;
mov [EDX], 0x25;
}
}
void main()
{
uint a = 0;
test(a);
writefln(0x%x, a);
}
Perhaps, errors like yours could be flagged at compile time? If so, an
enhancement request would be nice.
Thank you, Denis.
You are wellcome.
But I stand corrected - your original code was correct, it just didn't do what
you expected (I replaced inout with pointer for clarity):
void test (uint* a)
{
writefln(0x%x, a); // prints 0x12FE88, may differ
asm {
mov a, 0x25;
}
writefln(0x%x, a); // prints 0x25, i.e. you were modifying 'a', not '*a'
}
The following would be correct, but it is disallowed and silently ignored:
void test (uint* a)
{
asm {
mov [a], 0x25; // no warning is issued, works as if there were no
brackets around a, is that correct behavior?
}
}
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu wrote: Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Andrei I confused Herb Sutter with Herbert Schildt, and thought you were using irony.
Re: asm code and an inout function argument
Denis Koroskin Wrote:
On Fri, 15 May 2009 14:41:35 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
Denis Koroskin Wrote:
On Fri, 15 May 2009 14:24:16 +0400, Vladimir A. Reznichenko
kales...@gmail.com wrote:
I have a function:
void test (inout uint a)
{
asm
{
mov a, 0x25;
}
}
The trouble is that the function's call doesn't change the a variable.
Any ideas?
I believe your code is incorrect. This is how it should be done:
import std.stdio;
void test (out uint a)
{
asm
{
mov EDX, a;
mov [EDX], 0x25;
}
}
void main()
{
uint a = 0;
test(a);
writefln(0x%x, a);
}
Perhaps, errors like yours could be flagged at compile time? If so, an
enhancement request would be nice.
Thank you, Denis.
You are wellcome.
But I stand corrected - your original code was correct, it just didn't do
what you expected (I replaced inout with pointer for clarity):
void test (uint* a)
{
writefln(0x%x, a); // prints 0x12FE88, may differ
asm {
mov a, 0x25;
}
writefln(0x%x, a); // prints 0x25, i.e. you were modifying 'a', not '*a'
}
The following would be correct, but it is disallowed and silently ignored:
void test (uint* a)
{
asm {
mov [a], 0x25; // no warning is issued, works as if there were no
brackets around a, is that correct behavior?
}
}
It looks like inout/ref uint a is equal to uint* a but the situation when
we write D's code a = 5 means *a = 5. This is not obvious, at all. So when
I wrote asm code, it wouldn't work.
Interesting implementation of inout arguments )
What's more interesting is that it wasn't reflected in inline asm documentation.
Re: D1 and Phobos Fixes
Spacen Jasset wrote: Walter Bright wrote: Spacen Jasset wrote: This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. Many compiler patches get posted to bugzilla. About half of them are correct, the other half aren't (often fixing the symptom rather than the cause of the problem). Essentially, the compiler is fairly complicated and not well commented; I want to review any changes before they're committed. Otherwise I'll lose track of how it works and how it's supposed to work. Yes fair enough. What about phobos? Do many patches for phobos come in? Not many Phobos patches have been posted. Phobos is quite different to the compiler, several of us have write access to it. It's well worth submitting patches for it.
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? Depends on the exercise. In Knuth, some of the best bits are in the exercises. But I think he was using them as a form of compression, reducing the size of the book to reasonable length g. I don't think I've bothered trying to solve the exercises in any other textbook, except in some rare cases where the exercise was so interesting that I really wanted to know what the answer was. I've never done an exercise for the sake of doing an exercise. But I'm weirder than you.
Re: std.string and std.algorithm: what to do?
On Thu, 14 May 2009 18:15:01 -0400, Derek Parnell de...@psych.ward wrote: On Thu, 14 May 2009 17:33:40 -0400, Steven Schveighoffer wrote: On Thu, 14 May 2009 17:21:02 -0400, Derek Parnell de...@psych.ward wrote: Not really. What could funcA possibly do with the index without the string itself? If it's just a flag (uint.max or not), then funcA should be: funcA(bool found, ...) and you call it with funcA(find(needle, haystack) haystack.length, xyzzy) This doesn't cause any problems with people who use Tango, which returns the length if not found. In other words, if you find yourself writing code to morph the length into uint.max or -1, you are thinking about the problem incorrectly. Who said that I had control of how funcA() was implemented? Then I guess the rebuttal to that is, why should we make the design of std.string suffer to support a poorly designed legacy function? It's easy enough to write a wrapper around the properly designed string function to return what you wish. -Steve
Re: Please Vote: Exercises in TDPL?
On Thu, 14 May 2009 20:05:04 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? I personally never did exercises unless they were assigned. Generally when I'm reading a text book on my own, it's to get going on a project. So I'm not interested in solving puzzles :) But examples are good to help with understanding, so as long as you put the answers in the book, I think it's a good idea. -Steve
Re: A case for opImplicitCast: making string search work better
downs wrote:
Consider this type:
struct StringPosition {
size_t pos;
void opImplicitCast(out size_t sz) {
sz = pos;
}
void opImplicitCast(out bool b) {
b = pos != -1;
}
}
Wouldn't that effectively sidestep most problems people have with find
returning -1?
Or am I missing something?
Could work, but it looks overcomplicated. It could be intuitive, but
even then someone new would not be able to figure out what is actually
going on, without digging deep into the internals of the library (or the
D language).
I like my way better (returning two slices for search). Also, it
wouldn't require this:
Of course, this would require a way to resolve ambiguities, i.e. functions/statements
with preferences - for instance, if() would prefer bool over int. I don't
know if this is possible.
...and with my way, it's very simple to check if the search was successful.
e.g.
void myfind(char[] text, char[] search_for, out char[] before, char[]
after);
char[] before, after;
myfind(text, something, before, after);
//was it found?
bool was_found = !!after.length;
//where was it found?
int at = before.length;
Both operations are frequently needed and don't require you to reference
text or something again, which means they can be returned by other
functions, and you don't need to break the flow by putting them into
temporary variables.
With multiple return values, the signature of myfind() could become
nicer, too:
auto before, after = myfind(text, something);
(Or at least allow static arrays as return values for functions.)
Am _I_ missing something?
Re: Please Vote: Exercises in TDPL?
On Fri, 15 May 2009 17:13:40 +0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 14 May 2009 20:05:04 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? I personally never did exercises unless they were assigned. Generally when I'm reading a text book on my own, it's to get going on a project. So I'm not interested in solving puzzles :) But examples are good to help with understanding, so as long as you put the answers in the book, I think it's a good idea. -Steve Well, I'd wouldn't recommend putting solutions into a book for a couple of reasons: 1) Most people would jump to answers right after reading the question, without caring to thing a little 2) Good questions deserve good answers (with explanation etc), but it takes time and books size grows significantly 3) Teachers won't be able to use these exercises to teach D in the classes because everyone can cheat by looking at answers But I do believe that answers are very useful (unless they are no-brainers). I great solution to the problem would be to provide answers on a dedicated web-site. This way you can keep them comprehensive, they won't take up any space in the book, you may even write (and update) them *after* book is shipped.
Re: A case for opImplicitCast: making string search work better
On Fri, 15 May 2009 09:36:51 -0400, grauzone n...@example.net wrote:
downs wrote:
Consider this type:
struct StringPosition {
size_t pos;
void opImplicitCast(out size_t sz) {
sz = pos;
}
void opImplicitCast(out bool b) {
b = pos != -1;
}
}
Wouldn't that effectively sidestep most problems people have with find
returning -1?
Or am I missing something?
Could work, but it looks overcomplicated. It could be intuitive, but
even then someone new would not be able to figure out what is actually
going on, without digging deep into the internals of the library (or the
D language).
I like my way better (returning two slices for search). Also, it
wouldn't require this:
Of course, this would require a way to resolve ambiguities, i.e.
functions/statements with preferences - for instance, if() would
prefer bool over int. I don't know if this is possible.
...and with my way, it's very simple to check if the search was
successful.
e.g.
void myfind(char[] text, char[] search_for, out char[] before, char[]
after);
char[] before, after;
myfind(text, something, before, after);
//was it found?
bool was_found = !!after.length;
//where was it found?
int at = before.length;
Both operations are frequently needed and don't require you to reference
text or something again, which means they can be returned by other
functions, and you don't need to break the flow by putting them into
temporary variables.
With multiple return values, the signature of myfind() could become
nicer, too:
auto before, after = myfind(text, something);
(Or at least allow static arrays as return values for functions.)
Am _I_ missing something?
Your solution actually goes the opposite direction than I'd like. That
is, it looks more complicated than simply returning an index or a slice.
I don't want to have to declare return values ahead of time and I'm not
holding my breath for multiple return values. You may be able to return a
pair struct, but still, what could be simpler than returning an index?
It's easy to construct the value you want (before or after), and if you
both multiple values, that is also possible (and probably results in
simpler code).
-Steve
Re: A case for opImplicitCast: making string search work better
to return a pair struct, but still, what could be simpler than returning an index? It's easy to construct the value you want (before or after), and if you both multiple values, that is also possible (and probably results in simpler code). All what you can do with the index is 1. compare it against the length of the searched string to test if the search was successful 2. slice the searched string 3. do something rather special What else would you do? You'd just have to store the searched string as a temporary, and then you'd slice the searched string (for 2.), or compare it against the length of the searched string. You always have to keep the searched string in a temporary. That's rather unpractical. Oh sure, if you _really_ need the index (for 3.), then directly returning an index is of course the best way. With my approach, you don't need to grab the passed searched string again. All of these can be done in a single, trivial expression (for 3. getting the index only). Actually, compared to your approach, this would just eliminate the trivial but annoying slicing code after the search call, that'd you'd type in... what, 90% of all cases? The thing about multiple return values is true (sadly), but in this case, you could simply return a static array (char[][2]). At least that should be possible in D2 at some point. Maybe a struct would work fine too. But I don't like it, because the programmer had to look up the struct members first. He had to memorize the struct members, and couldn't tell what the function returns just by looking at the function signature. (Yay bikeshed issues.)
Re: Please Vote: Exercises in TDPL?
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:guitu0$op...@digitalmars.com... Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Looks like I'm not the only one that gets those books confused :). When Exceptional C++ was mentioned, I thought it was that C++ book you wrote. Oh... oops! The Scott Meyers titles are really similar! *blush*
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu wrote: Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Ouch! I think I actually have both Exceptional C++ and More Exceptional C++ around somewhere, though I think a lot of the same stuff can be found in his GOTW archives. And these days I'm using C at work, so... :-p
Re: asm code and an inout function argument
On Fri, 15 May 2009 07:14:50 -0400, Vladimir A. Reznichenko wrote: It looks like inout/ref uint a is equal to uint* a but the situation when we write D's code a = 5 means *a = 5. This is not obvious, at all. So when I wrote asm code, it wouldn't work. Isn't that the point of a reference, that you don't have to dereference it? In fact I believe *a = 5 would be an error when using references.
Re: asm code and an inout function argument
On Fri, 15 May 2009 19:11:55 +0400, Jesse Phillips jessekphill...@gmail.com wrote: On Fri, 15 May 2009 07:14:50 -0400, Vladimir A. Reznichenko wrote: It looks like inout/ref uint a is equal to uint* a but the situation when we write D's code a = 5 means *a = 5. This is not obvious, at all. So when I wrote asm code, it wouldn't work. Isn't that the point of a reference, that you don't have to dereference it? In fact I believe *a = 5 would be an error when using references. Isn't it an error right now?
Re: Please Vote: Exercises in TDPL?
Anders F Björklund wrote: Andrei Alexandrescu wrote: By the way. Is d2 focused? is it like a textbook or a reference book? D2 exclusively. Textbook modeled after KR. Will there be any GUI sections in D2 ? (or is that why they call it a textbook) If you're asking whether TDPL will contain discussions on GUIs, it won't. The hope is that it will teach one D well enough to write programs effectively using any library, GUI or otherwise. Andrei
Re: Please Vote: Exercises in TDPL?
Hello Nick, Ahh, I see what you're saying. In that case, that (and the well-being of student's backs/spines everywhere) would be good reason for school textbooks to finally move to an electronic format (but of course, that has plenty of other downsides...) what I want to see (as a first step) is a printing press build to be installed at the schools. Then they just need to get a PDF and a license to print X copies: Oh we ran out of that title, but we'll have a batch hot off the press in 10 minuets.
Re: Please Vote: Exercises in TDPL?
Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:guitu0$op...@digitalmars.com... Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Looks like I'm not the only one that gets those books confused :). When Exceptional C++ was mentioned, I thought it was that C++ book you wrote. I think I breifly browsed through one or two of those E* C++ books before. Was very impressed with them (and also a similar book from a different publisher geared towards game dev), but I think my biggest take-away from all of them was, Alright, that's it, screw C++. ;) Then I found D. Not that the books were difficult or anything, in fact they did a great job of making an extremely complicated language as easy as possible. But they just made it finally click in my mind just what a PITA/POS C++ had become. Shit, I'm rambling again... ;) One reason I like Exceptional C++ is that most of the points made in it transcend the language and are just good programming tips. It also does a good job of presenting complex topics as well as basic topics. Additionally, the 'exceptional' part isn't just about using exceptions in the language. :) Later, Brad
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu Wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? Thanks, Andrei Andrei, Do you have a publisher yet? They will probably give you quite a definitive answer. They usually have quite strong ideas about the market they are aiming for. If is is to be a university text book, then Yes! I realize that doing it is a pain in the ass. You have to test every little thing to the limit, which takes forever. But if you do it you will sort out bugs in the book. Don't envy you, especially given the moving target of D2 ;=) But the best of luck. Steve
Re: Please Vote: Exercises in TDPL?
On Fri, 15 May 2009 22:09:17 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steve Teale wrote: Andrei Alexandrescu Wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? Thanks, Andrei Andrei, Do you have a publisher yet? They will probably give you quite a definitive answer. They usually have quite strong ideas about the market they are aiming for. The publisher, Addison-Wesley, is leaving such details to me. If is is to be a university text book, then Yes! I realize that doing it is a pain in the ass. You have to test every little thing to the limit, which takes forever. But if you do it you will sort out bugs in the book. Don't envy you, especially given the moving target of D2 ;=) But the best of luck. Thanks! One nice thing is I've written (in D!) a little script that extracts the code from all of my examples, compiles it, and runs it comparing the output with the expected output. The book will definitely have a number of faults, but code that doesn't work will not be one of them. It's amazing how much I need to rewrite in wake of recent improvements to D and Phobos. My initial draft of Chapter 1 used char[] for strings! I think D couldn't have claimed being much more than a step forward from C if it stayed with that approach to strings. There's still stuff that doesn't compile (Walter is working on that), and looking forward I'm so excited about the forgotten __traits(allMembers) and the reflection capabilities it begets, I can't stand myself. Andrei Will you mention __traits as a __traits keyword, or it will be renamed (or, better, the whole feature re-implemented) to something better-looking one, by the time TDPL is ready? I really hope it will be fixed in one way or another soon. We need a better compile-time introspection and I assume __traits is just a starting point. It is too hack-ish and there is definitely a room for improvement.
Re: A case for opImplicitCast: making string search work better
On Fri, 15 May 2009 10:30:17 -0400, grauzone n...@example.net wrote:
to return a pair struct, but still, what could be simpler than
returning an index? It's easy to construct the value you want (before
or after), and if you both multiple values, that is also possible (and
probably results in simpler code).
All what you can do with the index is
1. compare it against the length of the searched string to test if the
search was successful
2. slice the searched string
3. do something rather special
What else would you do? You'd just have to store the searched string as
a temporary, and then you'd slice the searched string (for 2.), or
compare it against the length of the searched string. You always have to
keep the searched string in a temporary. That's rather unpractical. Oh
sure, if you _really_ need the index (for 3.), then directly returning
an index is of course the best way.
With my approach, you don't need to grab the passed searched string
again. All of these can be done in a single, trivial expression (for 3.
getting the index only). Actually, compared to your approach, this would
just eliminate the trivial but annoying slicing code after the search
call, that'd you'd type in... what, 90% of all cases?
I hadn't thought of the case where you are calling *on* a temporary, I
always had in mind that the source string was already declared, this is a
good point. The only drawback in this case is you are constructing
information you sometimes do not need or care about. If all you want is
whether it succeeded or not, then you don't need two ranges constructed
and returned. But therein lies a fundamental tradeoff that cannot be
avoided. The very basic information you get is the index, and with that,
you can construct any larger pieces from the pieces you have, but not
always easily, and not without repeating identifiers.
I like your approach, but with the single return type, not out
parameters. Having out parameters would be a deal breaker.
I'd prefer not to have two strings but a string that has an identified
pivot point. You could generate the desired left and right hand sides
dynamically, and it would work without any changes to the current syntax.
for example:
struct partition(R)
{
R range;
uint pivot;
R lhs() {return range[0..pivot];}
R rhs() {return range[pivot..$];}
bool found() {return pivot range.length;}
}
partition!string indexOf(string haystack, dchar needle);
usage:
string s = str.find(hi).rhs; // or .lhs or .found or .pivot
Maybe a struct would work fine too. But I don't like it, because the
programmer had to look up the struct members first. He had to memorize
the struct members, and couldn't tell what the function returns just by
looking at the function signature.
If this were implemented, the return type would be very common. At some
point you have to look up everything (what's a range?).
-Steve
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu Wrote: Steve Teale wrote: Andrei Alexandrescu Wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? Thanks, Andrei Andrei, Do you have a publisher yet? They will probably give you quite a definitive answer. They usually have quite strong ideas about the market they are aiming for. The publisher, Addison-Wesley, is leaving such details to me. If is is to be a university text book, then Yes! I realize that doing it is a pain in the ass. You have to test every little thing to the limit, which takes forever. But if you do it you will sort out bugs in the book. Don't envy you, especially given the moving target of D2 ;=) But the best of luck. Thanks! One nice thing is I've written (in D!) a little script that extracts the code from all of my examples, compiles it, and runs it comparing the output with the expected output. The book will definitely have a number of faults, but code that doesn't work will not be one of them. It's amazing how much I need to rewrite in wake of recent improvements to D and Phobos. My initial draft of Chapter 1 used char[] for strings! I think D couldn't have claimed being much more than a step forward from C if it stayed with that approach to strings. There's still stuff that doesn't compile (Walter is working on that), and looking forward I'm so excited about the forgotten __traits(allMembers) and the reflection capabilities it begets, I can't stand myself. Andrei Not being able to stand yourself goes with the job - there's worse to come. Addison-Wesley must have got more relaxed since I dealt with them, or possibly you are better known than I was at the time. Can I review? Even if only on an informal basis - I do speak the language from both sides of the pond, have some experience of the process, and I can be a real pain in the ass ;=) Steve
JSON in D
I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? Steve
std.regex
Perl 6 is completely redesigning the regex syntax. It's now a lot clearer, more flexible and more optimizable. Can we use (a subset of) this in the std.regex library? For an overview, see http://www.perl.com/pub/a/2002/06/04/apo5.html http://svn.pugscode.org/pugs/docs/Perl6/Spec/S05-regex.pod is more up-to-date, but it has less rationale and fewer examples.
Re: Please Vote: Exercises in TDPL?
Denis Koroskin wrote: Well, I'd wouldn't recommend putting solutions into a book for a couple of reasons: 1) Most people would jump to answers right after reading the question, without caring to thing a little 2) Good questions deserve good answers (with explanation etc), but it takes time and books size grows significantly 3) Teachers won't be able to use these exercises to teach D in the classes because everyone can cheat by looking at answers Many books have answers only to the odd numbered excercises.
Re: Please Vote: Exercises in TDPL?
Sean Kelly wrote: Nick Sabalausky wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:guitu0$op...@digitalmars.com... Sean Kelly wrote: Brad Roberts wrote: There's only one book that I can remember ever working through the exercises on.. and that's even a stretch of the term exercise: Exceptional C++. For any of you that develop c++ code and haven't read that book.. I highly recommend it. Scott Meyers is an excellent technical writer--he's one of the few authors whose books I'd pick up without ever cracking the cover. So is Herb Sutter, the author of Exceptional C++. Are you sure you cracked that one even after you bought it? Nyuk, nyuk... :o) Looks like I'm not the only one that gets those books confused :). When Exceptional C++ was mentioned, I thought it was that C++ book you wrote. Oh... oops! The Scott Meyers titles are really similar! *blush* Well, anyhow, reading a couple fo Scott Meyers books really kills the last inch of even trying to start coping with C++. They really make you see what a piece of manure the language is. Without even trying.
Re: Please Vote: Exercises in TDPL?
Andrei Alexandrescu Wrote: Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. If they're so cool, I think, they are worth adding. May be you didn't solve exercises because they were boring?
Re: std.regex
Steve wrote: Perl 6 is completely redesigning the regex syntax. It's now a lot clearer, more flexible and more optimizable. Can we use (a subset of) this in the std.regex library? For an overview, see http://www.perl.com/pub/a/2002/06/04/apo5.html http://svn.pugscode.org/pugs/docs/Perl6/Spec/S05-regex.pod is more up-to-date, but it has less rationale and fewer examples. Sure, go ahead and implement it :o). Andrei
Re: Real Close to the Machine: Floating Point in D
Lars T. Kyllingstad wrote: ... Specific problem areas get their own subpackages. At the moment these mostly just contain nicer interfaces to the routines in scid.ports -- drivers, if you will. I've tried a lot of setups, and this is the one I've found most flexible. That's what I call user friendly. Of course, that way several (small things) things may end up being in more than one package, but that should be okay.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment.
Re: Please Vote: Exercises in TDPL?
Steve Teale wrote: Can I review? Even if only on an informal basis - I do speak the language from both sides of the pond, have some experience of the process, and I can be a real pain in the ass ;=) Steve, I've known you for what, 20+ years? and you've never been a pain the ass. I hope you can come to our (as yet theoretical) next D conference so we can heft a pint!
Re: Please Vote: Exercises in TDPL?
== Quote from Georg Wrede (georg.wr...@iki.fi)'s article Well, anyhow, reading a couple fo Scott Meyers books really kills the last inch of even trying to start coping with C++. They really make you see what a piece of manure the language is. Without even trying. I have a lot of issues with C++, but I find C to be positively maddening. If there were a version of D that didn't contain a GC and ran on SPARC I'd jump for joy right about now.
Re: Please Vote: Exercises in TDPL?
Brad Roberts wrote:
There's only one book that I can remember ever working through the exercises
on.. and that's even a stretch of the term exercise: Exceptional C++.
The short attention span version of Exceptional C++:
int main()
{
*(char*)0 = 0;
return 0;
}
Re: Please Vote: Exercises in TDPL?
BCS n...@anon.com wrote in message news:a6268ff5db58cba35a2dda2...@news.digitalmars.com... Hello Nick, Ahh, I see what you're saying. In that case, that (and the well-being of student's backs/spines everywhere) would be good reason for school textbooks to finally move to an electronic format (but of course, that has plenty of other downsides...) what I want to see (as a first step) is a printing press build to be installed at the schools. Then they just need to get a PDF and a license to print X copies: Oh we ran out of that title, but we'll have a batch hot off the press in 10 minuets. There are some schools that already either have or have access to a local print shop. I know of at least a couple schools where a few of the classes have books (usually small ones) that were written by the instructor or by the department and printed by the local/official/semi-official school print shop. What you suggest would be a great next step.
Re: Please Vote: Exercises in TDPL?
Brad Roberts bra...@puremagic.com wrote in message news:mailman.73.1242407451.13405.digitalmar...@puremagic.com... Nick Sabalausky wrote: Looks like I'm not the only one that gets those books confused :). When Exceptional C++ was mentioned, I thought it was that C++ book you wrote. I think I breifly browsed through one or two of those E* C++ books before. Was very impressed with them (and also a similar book from a different publisher geared towards game dev), but I think my biggest take-away from all of them was, Alright, that's it, screw C++. ;) Then I found D. Not that the books were difficult or anything, in fact they did a great job of making an extremely complicated language as easy as possible. But they just made it finally click in my mind just what a PITA/POS C++ had become. Shit, I'm rambling again... ;) One reason I like Exceptional C++ is that most of the points made in it transcend the language and are just good programming tips. It also does a good job of presenting complex topics as well as basic topics. Additionally, the 'exceptional' part isn't just about using exceptions in the language. :) I guess I didn't get too good of a look at that particular one then. There are number of other great books though that transcend the language and are just good programming tips. The Pragmatic Programmer, Code Craft, and Writing Solid Code. The other one I mentioned above was C++ for Game Programmers. That's one that anyone who writes videogames in C++ should read.
Re: Please Vote: Exercises in TDPL?
Walter Bright newshou...@digitalmars.com wrote in message
news:gukg9f$n1...@digitalmars.com...
Brad Roberts wrote:
There's only one book that I can remember ever working through the
exercises
on.. and that's even a stretch of the term exercise: Exceptional C++.
The short attention span version of Exceptional C++:
int main()
{
*(char*)0 = 0;
return 0;
}
I went through a phase where I was really big on making custom sound schemes
for my system. I loved the clip I had picked for program crash so much, I
wrote a program where the entire intent was to dereference null, just so I
could listen to my nifty error sound whenever I wanted.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
On Fri, May 15, 2009 at 12:22 PM, Georg Wrede georg.wr...@iki.fi wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Well you'd better call your lawyer then. :-) The usage terms on the classic Numerical Recipes are terrible. Basically you're only allowed to use their code if you purchased a copy of the book. Which basically means if you use their code, then you are not allowed to share the NR portion of your code with anyone who does not own the book. Their code is not so pretty anyway, so much better to just read the ideas and implement it yourself, thus avoiding any potential legal hassle. SciPy has recently done a sweep through their code purging anything that looks like it was derived from NR code for this reason. They also went through and made it clear in all comments which refer to NR for explanations of algorithms that they did NOT use NR code as a basis for the code in SciPy. --bb
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Georg Wrede wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. Andrei
Re: JSON in D
== Quote from Steve Teale (steve.te...@britseyeview.com)'s article I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/
Inlining Ref Functions
The fact that DMD does not inline functions with ref parameters has come up several times deep in threads on this NG before, but it's never really received proper attention. After changing a few swaps in performance-critical areas of my code to manually inlined swaps and seeing significant speedups, I'm kind of curious what the rationale is for not inlining functions w/ ref params. Is there a good technical reason for this or is it simply a matter of having higher priorities? Is inlining functions w/ ref params on the to do eventually list?
Re: Inlining Ref Functions
On Fri, May 15, 2009 at 1:36 PM, dsimcha dsim...@yahoo.com wrote: The fact that DMD does not inline functions with ref parameters has come up several times deep in threads on this NG before, but it's never really received proper attention. After changing a few swaps in performance-critical areas of my code to manually inlined swaps and seeing significant speedups, I'm kind of curious what the rationale is for not inlining functions w/ ref params. Is there a good technical reason for this or is it simply a matter of having higher priorities? Is inlining functions w/ ref params on the to do eventually list? +1 on bumping up the priority on it. Even if it it can't be made to work in every case, if it could at least be made to work in simple cases like swap() then it would be great boon for DMD benchmarks. --bb
Re: Inlining Ref Functions
== Quote from Bill Baxter (wbax...@gmail.com)'s article On Fri, May 15, 2009 at 1:36 PM, dsimcha dsim...@yahoo.com wrote: The fact that DMD does not inline functions with ref parameters has come up several times deep in threads on this NG before, but it's never really received proper attention. After changing a few swaps in performance-c ritical areas of my code to manually inlined swaps and seeing significant speed ups, I'm kind of curious what the rationale is for not inlining functions w/ r ef params. Is there a good technical reason for this or is it simply a ma tter of having higher priorities? Is inlining functions w/ ref params on the to do eventually list? +1 on bumping up the priority on it. Even if it it can't be made to work in every case, if it could at least be made to work in simple cases like swap() then it would be great boon for DMD benchmarks. --bb Just to clarify: I actually don't think this is a terribly high priority item. Now that D2 is apparently pretty much feature complete, I'd rather bug fixes for functionality bugs than relatively mild performance bugs. My question was purely out of curiosity.
Dual D2/D1 code base
I don't know what made me think of it, but could a feature very similar to Descent's compile-time view be used for generating D1 code from D2 code? It should allow striping of const, immutable, nothrow, shared, and pure from D2 code with relative ease. It obviously would not solve everything, but I think it could allow Tango to use a single code base... Several Tango-based D1 libraries could then follow and support both D1 and D2. Thoughts?
Re: Inlining Ref Functions
Well it was shown before in a demo ray-tracer that the inability to
inline funcs with refs caused a significant speed hit under DMD. And
now we're seeing it's causing a significant speed hit for sorting
because of swap routines.
There may be some thorny issues regarding inlining with refs in the
general case but with code like this:
float lengthSqr(const ref vec3 v) { return v.x*v.x + v.y*v.y + v.z*v.z; }
it really should be trivial for the compiler to figure out that
direct substitution is possible in a simple case like:
vec3 w;
...
auto len2 = lengthSqr(w);
Maybe I'm missing something, but that looks pretty darn straightforward.
--bb
On Fri, May 15, 2009 at 2:01 PM, dsimcha dsim...@yahoo.com wrote:
== Quote from Bill Baxter (wbax...@gmail.com)'s article
On Fri, May 15, 2009 at 1:36 PM, dsimcha dsim...@yahoo.com wrote:
The fact that DMD does not inline functions with ref parameters has come
up
several times deep in threads on this NG before, but it's never really
received proper attention. After changing a few swaps in performance-c
ritical
areas of my code to manually inlined swaps and seeing significant speed
ups,
I'm kind of curious what the rationale is for not inlining functions w/ r
ef
params. Is there a good technical reason for this or is it simply a ma
tter of
having higher priorities? Is inlining functions w/ ref params on the
to do
eventually list?
+1 on bumping up the priority on it.
Even if it it can't be made to work in every case, if it could at
least be made to work in simple cases like swap() then it would be
great boon for DMD benchmarks.
--bb
Just to clarify: I actually don't think this is a terribly high priority
item.
Now that D2 is apparently pretty much feature complete, I'd rather bug fixes
for
functionality bugs than relatively mild performance bugs. My question was
purely
out of curiosity.
Re: A case for opImplicitCast: making string search work better
downs wrote:
Consider this type:
struct StringPosition {
size_t pos;
void opImplicitCast(out size_t sz) {
sz = pos;
}
void opImplicitCast(out bool b) {
b = pos != -1;
}
}
Wouldn't that effectively sidestep most problems people have with find
returning -1?
Or am I missing something?
Of course, this would require a way to resolve ambiguities, i.e. functions/statements
with preferences - for instance, if() would prefer bool over int. I don't
know if this is possible.
Just use two functions: find and contains.
Re: JSON in D
Sean Kelly wrote: == Quote from Steve Teale (steve.te...@britseyeview.com)'s article I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/ Dude, tango.text.json?
Re: A case for opImplicitCast: making string search work better
Christopher Wright: Just use two functions: find and contains. Or better, define a built in operator, you may call it in :-) 'e' in hello = true (The compiler may even cache the resulting position somewhere, so a successive find can be very fast). Bye, bearophile
Re: Fun with allMembers
Shin Fujishiro: For example, using allMembers with enums, I could implement enumToString and enumFromString without defineEnum. Code: http://codepad.org/HVvPjoI7 Nice. With better unit testing, and docs this seems good to go into Phobos. Bye, bearophile
Re: std.partition is fucked
Sean Kelly:
The built-in sort uses an internal stack rather than recursion, which makes
its performance on a best-case dataset hard to beat.
The built-in sort is snail slow, and its stack overflows if your array isn't
small:
void main() {
auto a = new uint[0x8F_];
a.sort;
}
So the current built-in sort is bad, and it must be fixed or removed.
Bye,
bearophile
(Sorry for the answering delay, I was busy for about a week. Tons of posts to
catch up!)
Re: project oriented
BCS: The c# solution works well if you will *only* develop from the IDE but is a total pain as soon as you need to work with non-language aware tools. I think Microsoft thinks that an IDE is a part of a modern language. So they have tried to design a language that almost needs an IDE. Fortress language looks to need an IDE even more. There are languages (most Smalltalk, and some Forth and some Logo) that are merged with their development environment. Bye, bearophile
Re: What's the current state of D?
Leandro Lucarella: I think this is another problem with D, version naming is really confusing and lame. You can't know anything from a D version number. Yes, improving such small things is positive. So I suggest to start using a language.version.releaseStatus numbering scheme for D2 (and maybe for D2 too). So the current D2 becomes: 2.0.30alpha and the current D1 becomes: 1.0.45 Once D2 gets out of alpha it may become: 2.1.0 Bye, bearophile
Re: assignment: left-to-right or right-to-left evaluation?
Georg Wrede: arra[i] = arrb[i++]; arra[i++] = arrb[i]; I'm not sure that such dependences are good code. By stating a definite order between lvalue and rvalue, you would actually encourage this kind of code. I agree that putting such things in code is bad, but nowadays the solution adopted by C is Just Wrong. To help avoid bugs from your programs the language has to avoid undefined behaviors (this is one of the lessons of Java). So the solutions are to define such behaviors as Andrei suggests, or to forbid such code. I can accept both ways. I am used to Python and I think I can appreciate the Python solution better, but the Java solution too is better than having undefined behavior in a modern language. So thank you Andrei for this work. Bye, bearophile
Re: Please Vote: Exercises in TDPL?
Nick Sabalausky wrote: Sean Kelly s...@invisibleduck.org wrote in message I also don't understand why professors seem to always choose academic textbooks on the subject when I know there are infinitely better trade books available (which I generally already own). Hear hear!! There's also another phenomenon I've noticed: Classes that never use the book, *except* for heavy use of it during the first two weeks. Call me paranoid, but I can't imagine any realistic explanation for that other than trying to trick students who have learned not to buy books until they see the class *really does* require it (as opposed to the classes that merely claim to require it.) It could also be that the professor is new to teaching and wanted to try out the book, but did not end up liking it. Heck, one of the schools I went to, I know for a fact that the instructors were *required* to choose a required book for their course and have the bookstore order it. A handful of instructors would say on the first day of class Did you get the required book for this course? No? Good. Don't. And if you have, go take it back. They just required me to pick one. We won't use it, so don't get it. My university's bookstore refused to accept returns without proof that you dropped the course.
Re: Please Vote: Exercises in TDPL?
On Thu, May 14, 2009 at 5:05 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: A chunky fragment of TDPL will hit Rough Cuts soon enough. I'm pondering whether I should be adding exercises to the book. Some books have them, some don't. Pros: As I'm writing, I've come up with some pretty darn cool exercise ideas. Cons: The book gets larger, takes longer to write, and I never solved the exercises in the books I've read, but then I'm just weird. What do you think? I learned Scheme on my own using SICP and I found the exercises there to be quite valuable in verifying that I actually understood* what was going on. [*] or didn't understand, as was frequently the case. :-)
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Andrei Alexandrescu wrote: Georg Wrede wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Actually I seem to remember that Numerical recipes in C was widely criticized for having incredibly strong restrictions on the published code. Exactly. So, what's the point? Here's a bone, widely available on the sidewalk!!! But my god, just try to chew on it, and I'll sue your [butt]. And that's one more reason to lose respect for a certain judicial system. The mere hint of such practices, really should make the law makers take a serious look at themselves. (But then again, to even become a law maker in such a system, you'd have gone throug such a chewing that the last bit of decency, sense of right, fairness, and a few other characteristics, simply have to have been erased from your mind. Heck, lawyers in even honest countries aren't respected for righteousness, fairness, integrity, or respect.) I've seen software houses in America publish their library code. And that code contained passages like this is the unpublished source code [...] copyright witheld [...] all rights reserved. Publishing freaking Unpublished can only happen in the New World.
Re: What's the current state of D?
Walter Bright: As far as I can tell, nobody cared about array ops. So that leaves contract inheritance. I find it hard to see how not having it is a showstopper for using D1. Contracts in D haven't been the big win I thought they might be at first. They aren't use much at all. There are a lot of other issues that do make a big difference, and those are the issues that get attention. This is interesting. Some features are a failure because they need to be tried and tested before knowing they are not good, because you can't tell everything from theory. Once you know they aren't good you can remove them. Other features are good, but in practice they aren't much used. Such low usage may come from various sources: - They aren't part of the culture of most D programmers (I am thinking about useful things like typedef, nested functions and closures). This can be partially solved adding the D site tutorial pages about the usefulness purposes several usage examples of typedef, nested functions and closures. - They are clumsy to use, maybe because their syntax is long, ugly or not easy to understand. This can be solved with a better design, like asking the community to design the syntax of a feature before implementing it. And before that, asking people what features they want/need more in the first place. We'll have to create another thread of the most wanted things. - They aren't well integrated with other features of the D language, so such features become like islands, so they can't become much useful, and in the D body such feature-transplant has a reject. In a language like Chapel array operations are natural, and in a language like Eiffel contracts are natural, because in both language such features are well integrated with other features of the language. This can be solved adding more bridges from such features to other parts of the language and making the syntax of the new features better merged with the other parts of the language. I have never used array ops yet, but for example I'd like to have array comprehensions (lazy too), they are something I'd use every day in D (Walter is currently focused in adding features that allow to write big programs with D. But it's good to also improve the language to make it fitter for small things too. It's the difference between scaling up and scaling down. Both directions are useful, because big programs are written of small chunks of code. And an array comprehension allows you to write smaller class methods/functions, reducing the overall line count of the program). - Few more mixed things that I'd like to see done regarding D: - A simpler, cleaner and easier to use site. The current site is a mess. I am able to list where I think it needs to be improved. - Having dmd source code online on Git. - Remove some things that are less useful from D2. - To give more attention to what D programmers want and ask for. From what I have seen the community here is quite smart, so it's often better to implement what many of them ask for, instead of other things few/none ask for. Often smart people are right in asking for faster horses instead of a car. - Having an official D front-end written in D is something good, but now it's too much early, I think. - Reducing the number of D newsgroups, and renaming few of them can be good. Bye, bearophile
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
Bill Baxter wrote: On Fri, May 15, 2009 at 12:22 PM, Georg Wrede georg.wr...@iki.fi wrote: Lars T. Kyllingstad wrote: 2. I have to figure out some licensing issues. Some algorithms are clearly public domain, while some things -- like code I've ripped off Numerical Recipes, for instance -- is more questionable. (Although the NR guys do quite a lot of off-ripping themselves. ;) If you're talking about any one of the books that come up when entering Numerical Recipes in the Amazon search box, I'd say that those recipes are freely usable. That's why they're in the books. Checking, of course may be good, but if anyone publishes recipes in a book and then sues people for actually using them, I'd sue *them* for entrapment. Well you'd better call your lawyer then. :-) The usage terms on the classic Numerical Recipes are terrible. Basically you're only allowed to use their code if you purchased a copy of the book. Which basically means if you use their code, then you are not allowed to share the NR portion of your code with anyone who does not own the book. Damn. It's a shame that I currently don't have a company of, say, 20 coders. Then I'd have enough slack in my turnover to take on issues like this. Here in Europe, some of those things aren't all too favorably looked upon. Just last week I read that Intel had got a fine of millions of dollars, just because they had twisted the arm of some wholeseller so that they entirely excluded AMD. Their code is not so pretty anyway, so much better to just read the ideas and implement it yourself, thus avoiding any potential legal hassle. Yes, if the algorithm is published in a book, then it's a lot easier for us to implement it, instead of translating /their/ C[++] implementation. SciPy has recently done a sweep through their code purging anything that looks like it was derived from NR code for this reason. They also went through and made it clear in all comments which refer to NR for explanations of algorithms that they did NOT use NR code as a basis for the code in SciPy. The *first* half of this century belongs to the RIAA, and their friends. And similarily, like the Soviet Union thought socialism /everywhere/ is the answer, seems like some other countries think free market /everywhere/, unhindered, is the answer. For example, TV was originally thought of as a superior medium to educate the masses, to bring equality to citizens by enabling everyone access to the same education. Today, one watches Oprah, Dr Phil, etc. and sees 3 minutes of programming, 6 minutes of commercials, and the same all over again. Watching those shows overseas, makes one cry of compassion. Here we see the shows at least a half hour at a time, interspersed (sometimes) with brief flashes, saying put commercial here. And we have jingles between programming and commercials. During the *second* half of this century, most countries and continents have adopted a more pragmatical way. (Just as in programming languages, full OOP sucks, full Purely Functional sucks, etc.) The entities will have adopted a pragmatic mix of state controlled, free market, branch cooperated, and third sector, economic systems. For example, deciding what should be showed to kids before 9am, is not a choice left to who makes programming that the average 2-second channel hopper sticks to, or who is audacious enough to have 95% of an hour commercials and only 5% programming because the audience seems to cope. That decision has to be with the FCC, or some other authority, not guided by quartal revenue. Just yesterday I watched a documentary from China. Seems like the Central Government (or whatever they're called) have adopted a way of thinking about economical issues, that kind-of strides the socialist and the market economy. Most things are according to market economy, but some things are tightly controlled. (Yes, I know, they censor the Internet heavily, but the commentators and the interviewees (some of which were economics students at regular Chinese, Shanhai, or Hong Kong universities) seemed to think that some censorship is a small price to pay for economic stability, long-term predictability, and reason in administration. Which they (according to them) couldn't have with a revolution or a shift of power.) We don't need to copy NR. All we need is to glipse at their algorithms. And anyway, D is so much more powerful that those algorithms would be, implemented in another way, anyhow.
Re: JSON in D
== Quote from Christopher Wright (dhase...@gmail.com)'s article Sean Kelly wrote: == Quote from Steve Teale (steve.te...@britseyeview.com)'s article I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/ Dude, tango.text.json? That's a decent option if you aren't inclined to write one.
Re: assignment: left-to-right or right-to-left evaluation?
bearophile wrote: Georg Wrede: arra[i] = arrb[i++]; arra[i++] = arrb[i]; I'm not sure that such dependences are good code. By stating a definite order between lvalue and rvalue, you would actually encourage this kind of code. I agree that putting such things in code is bad, but nowadays the solution adopted by C is Just Wrong. To help avoid bugs from your programs the language has to avoid undefined behaviors (this is one of the lessons of Java). If Walter had ulimited time, the of course I'd favor either defining the precedence, or then enforcing errors on them, and not leaving them undefined. Or, probably, with Walter's unlimited time, I'd vote for a system that is the Theoretically Best mix of programming praxis and compiler enforcement. So the solutions are to define such behaviors as Andrei suggests, or to forbid such code. I can accept both ways. I am used to Python and I think I can appreciate the Python solution better, but the Java solution too is better than having undefined behavior in a modern language.
Re: SciD (Was: Real Close to the Machine: Floating Point in D )
On Fri, May 15, 2009 at 5:15 PM, Georg Wrede georg.wr...@iki.fi wrote: We don't need to copy NR. All we need is to glipse at their algorithms. And anyway, D is so much more powerful that those algorithms would be, implemented in another way, anyhow. THe NR in C code is basically a translated version of the NR in Fortran code. Right down to using 1-based indexing. THe NR in C++ code is the C code with a few token classes thrown in for vectors. Still using 1-based indexing. It's not something you'd really want to emulate, especially not in D. Unless you just happen to love Fortran-style code. :-) --bb
Re: assignment: left-to-right or right-to-left evaluation?
Georg Wrede: If Walter had ulimited time, the of course I'd favor either defining the precedence, or then enforcing errors on them, and not leaving them undefined. Or, probably, with Walter's unlimited time, I'd vote for a system that is the Theoretically Best mix of programming praxis and compiler enforcement. Java is currently the most used language because it gives a big help in avoiding bugs or fixing them. And today Java is not a slow language. Java shows why having undefined things is bad for productivity and doesn't give much performance or portability. Bye, bearophile
OT: on IDEs and code writing on steroids
bearophile wrote: BCS: The c# solution works well if you will *only* develop from the IDE but is a total pain as soon as you need to work with non-language aware tools. I think Microsoft thinks that an IDE is a part of a modern language. So they have tried to design a language that almost needs an IDE. Fortress language looks to need an IDE even more. There are languages (most Smalltalk, and some Forth and some Logo) that are merged with their development environment. Hmm. Come to think of it, that's not totally unreasonable. One might even admit, it's modern. In the Good Old Days (when it was usual for an average programmer to write parts of the code in ASM (that was the time before the late eighties -- be it Basic, Pascal, or even C, some parts had to be done in ASM to help a bearable user experience when the mainframes had less power than today's MP3 players), the ASM programing was very different on, say, Zilog, MOS, or Motorola processors. The rumor was that the 6502 was made for hand coded ASM, whereas the 8088 was more geared towards automatic code generation (as in C commpilers, etc.). My experiences of both certainly seemed to support this. Precisely the same thinking can be applied to programming languages and whether one should use them with an IDE or independent tools. (At the risk of flame wars, opinion storms, etc.) I'd venture to say, that the D programming language is created for the Hand Coder. (Meaning somebody with an independent text editor (Notepad, vi, Emacs, or whatever), and a command line compile invocation. The opposite might be C# (if I understand the rumors here correctly, I'm not familiar with the language itself), or Java, as an even better example. Java, as a language, is astonishingly trivial to learn. IMHO, it should take at most half the time that D1 does. The book The Java Programming Language (by Arnold and Gosling, 3p 1996), is a mere 300 pages, printed in a huge font, with plenty of space before and after subheadings, on thick paper (as opposed to the 4 other books published at the same time, that Sun presumed (quite right) folks would order together, so it wouldn't look inferior in the book shelf. But, to use Java at any productive rate, you simply have to have an IDE that helps with class and method completion, class tree inspection, and preferably two-way UML-tools. So, in a way, Microsoft may be right in assuming that (especially when their thinking anyway is that everybody sits at a computer that's totally dedicated to the user's current activity anyhow) preposterous horse power is (or, should be) available at the code editor. It's not unthinkable that this actually is The Way of The Future. If we were smart with D, we'd find out a way of leapfrogging this thinking. We have a language that's more powerful than any of C#, Java or C++, more practical than Haskell, Scheme, Ruby, co, and more maintainable than C or Perl, but which *still* is Human Writable. All we need is some outside-of-the-box thinking, and we might reap some overwhelming advantages when we combine *this* language with the IDEs and the horsepower that the modern drone takes for granted. Easier parsing, CTFE, actually usable templates, practical mixins, pure functions, safe code, you name it! We have all the bits and pieces to really make writing + IDE assisted program authoring, a superior reality. Ain't nobody gonna catch us never!
Re: std.string and std.algorithm: what to do?
Derek Parnell wrote: On Thu, 14 May 2009 17:33:40 -0400, Steven Schveighoffer wrote: On Thu, 14 May 2009 17:21:02 -0400, Derek Parnell de...@psych.ward wrote: Not really. What could funcA possibly do with the index without the string itself? If it's just a flag (uint.max or not), then funcA should be: funcA(bool found, ...) and you call it with funcA(find(needle, haystack) haystack.length, xyzzy) This doesn't cause any problems with people who use Tango, which returns the length if not found. In other words, if you find yourself writing code to morph the length into uint.max or -1, you are thinking about the problem incorrectly. Who said that I had control of how funcA() was implemented? Well, if you wrote funcA(find(needle, haystack) haystack.length, xyzzy) then it is you, who decided to use funcA. Now, if that wasn't to your liking, you'd of course write your own funcA (or use another function), that works as you want. Therefore, you're in control of funcA() here.
asm trouble
Asm trouble, again. There is a function in a programm.
void test (inout uint a, uint sh, uint b)
{
version (X86)
{asm {
mov EAX, a;
mov EBX, sh;
mov ECX, b;
push EAX; //a adress saved
//EAX = rotateLeft (a, sh) + b
push [EAX];
push EBX;
call rotateLeft;
add EAX, ECX;
pop EDX; //a adress restored
mov [EDX], EAX;
}}
}
void main ()
{
uint a = 1;
test (a, 5, 25);
writeln (a);
}
When launched the executable,got this: Error: Access Violation
What's intresting, if i change asm code to
(save a address in the stack removed, forcing register values after the call
instraction), it works just fine
...
call rotateLeft;
//force registers values
mov EDX, a;
mov ECX, b;
..
So the question is why the call instruction drops register values?
It have to save registers state and restore it after the rotateLeft finished
(EAX of course will store a function call result).
Re: std.string and std.algorithm: what to do?
Michiel Helvensteijn wrote: Daniel Keep wrote: http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx Heh, that's a funny story. I didn't know that one. (I do think the sensible developer was a bit of a killjoy, though.) But how about coming up with some actual arguments here? What are the `gloves' in this situation? Don't say `modules' without explaining how they offer the same advantages as tags. I can imagine a similar discussion having taken place when someone thought of higher-level control-flow constructs (you know, `if' and `while'). I imagine most people were perfectly happy with goto's and conditional jumps. I used to work in a software house where half of the projects contained at least one sub project, of the Glove kind. The funniest thing is, these folks didn't understand the notion of Gloves, even when explained about it. (Of course, at the time I didn't have the word Gloves, nor Wikipedia or www.c2.com to help me.)
Re: Inlining Ref Functions
== Quote from Michel Fortin (michel.for...@michelf.com)'s article Which makes me think: now that this in structs is now a ref parameter, does that mean that all non-static member functions of a struct won't be inlined? Oddly enough, based on looking at some disassembly, DMD apparently inlines ref in this special case. Go figure. If there are any explicit parameters that are ref, though, it doesn't inline.
Re: Please Vote: Exercises in TDPL?
Walter Bright wrote:
Brad Roberts wrote:
There's only one book that I can remember ever working through the
exercises
on.. and that's even a stretch of the term exercise: Exceptional C++.
The short attention span version of Exceptional C++:
int main()
{
*(char*)0 = 0;
return 0;
}
Sometimes I fear my C[++] bashing is grossly insufficient. I feel I'm
crying wolf all over town, when I should cry crocodile.
(I'm not scared of wolves. We actually have wolves around here. But in
1973 I was in Konstanz, Germany, studying the language, and somebody had
an 18 inch baby crocodile on the campus lawn, tethered to a tree. You'd
never guess what scare and panic the reptile caused. It could run as
fast as a human, and its jaws were half its length. And it sure wasn't
waiting for people to come and cuddle it.)
Re: std.partition is fucked
bearophile wrote:
Sean Kelly:
The built-in sort uses an internal stack rather than recursion, which makes its
performance on a best-case dataset hard to beat.
The built-in sort is snail slow, and its stack overflows if your array isn't
small:
void main() {
auto a = new uint[0x8F_];
a.sort;
}
So the current built-in sort is bad, and it must be fixed or removed.
That pretty much settles it. Seeing sort's fixed stack, I had this
feeling for a while, but only now I saw the proof :o).
Andrei
