Re: std.regexp vs std.regex [Re: RegExp.find() now crippled]
Steve Teale wrote:
> KennyTM~ Wrote:
>
>> On Nov 15, 10 14:58, Steve Teale wrote:
>> > Some time ago in phobos2, the following:
>> >
>> > RegExp wsr = RegExp("(\\s+)");
>> > int p = wsr.find("");
>> > writefln("%s|%s|%s %d",wsr.pre(), wsr.match(1), wsr.post(), p);
>> >
>> > would print:
>> >
>> > 7
>> >
>> > Now it prints
>> >
>> > 1
>> >
>> > The new return value is pretty useless, equivalent to returning a bool.
>> > It seems to me that the 'find' verb's subject should be the string, not
>> > the RegExp object.
>> >
>> > This looks like a case of the implementation being changed to match the
>> > documentation, when in fact it would have been better to change the
>> > documentation to match the implementation.
>> >
>> > Either that, or RegExp should have an indexOf method that behaves like
>> > string.indexOf.
>> >
>> > Steve
>> >
>>
>> Isn't std.regexp replaced by std.regex? Why are both of them still in
>> Phobos 2?
>>
>> (oh, and std.regex is missing a documented .index (= .src_start)
>> property.)
>
> I guess std.regexp is still there because not all of us necessarily want
> to iterate a range to simply find out the position of the first whitespace
> in a string. Part of the expressiveness of languages is that one should be
> free to use the style that suits, and not have to read the documentation
> every time one uses it. Give me options in Phobos by all means.
>
> D2 is not going to succeed by forcing its users to use unfamiliar, and
> maybe not yet very fashionable constructions.
>
> I'm pissed off because this change broke a lot of my code, which I had not
> used for some time, but now have a paying customer for. The code did not
> break because of D language evolution. It broke because somebody decided
> they did not like the style of std.regexp. All I wanted was plain old
> regular expressions, similar to JavaScript, or PHP, or other popular
> languages, and std.regexp did that pretty well at one time.
>
> Steve
I'm pretty sure that can be filed as a bug. The behavior is still documented
as returning index of match, and the standalone std.regexp.find works that
way. Patch:
@@ -1045,7 +1045,7 @@
{
int i = test(string);
if (i)
-i = pmatch[0].rm_so != 0;
+i = pmatch[0].rm_so;
else
i = -1; // no match
return i;
Re: Principled method of lookup-or-insert in associative arrays?
Andrei Alexandrescu wrote:
> TDPL has an example that can be reduced as follows:
>
> void main() {
>uint[string] map;
>foreach (line; stdin.byLine()) {
> ++map[line];
>}
> }
>
> byLine reuses its buffer so it exposes it as char[]. Therefore,
> attempting to use map[line] will fail. The program compiled and did the
> wrong thing because of a bug.
>
> The challenge is devising a means to make the program compile and work
> as expected. Looking up an uint[string] with a char[] should work, and
> if the char[] is to be inserted, a copy should be made (via .idup or
> to!string). The rule needs to be well defined and reasonably general.
>
> The effect is something like this:
>
> void main() {
>uint[string] map;
>foreach (line; stdin.byLine()) {
> auto p = line in map;
> if (p) ++*p;
> else map[line.idup] = 1;
>}
> }
>
> Ideally the programmer would write the simple code (first snippet) and
> achieve the semantics of the more complex code (second snippet). Any
> ideas?
>
> Andrei
What I don' t understand is why it is allowed to use mutable types where the
key type is immutable. This way you can get immutable references to mutable
data back without explicit casting (via the .keys property for example). The
example would not compile if this wasn't allowed.
Re: Review: A new stab at a potential std.unittests
I'm not particularly fond of this interface and think that a solution with a delegate / lazy or alias template parameter would be more convenient. However, until we have ast macros I do see the added value in this approach. Some remarks about the api, not a proper review of the code itself: - core.exception and std.string must be imported to use the module, relevant symbols should be selectively and publicy imported instead. - exception would be better abbreviated as ex instead of exc, I believe this is more conventional. (assertExThrown instead of assertExcThrown) - assertExcThrown should fail if an exception is thrown that is not T or a subclass of T. (catch and throw AssertError) - assertEqual and assertNotEqual is inconsistent in naming with the assertOpFoo class of functions I believe these assertions should be added: - assertExcThrown and assertExcNotThrown with a default T (should be Exception, not Throwable) - something equivalent to std.algorithm.equal, the latter is very useful in unittests - assertOpBinary, assertTrue and perhaps assertPred (where the predicate is an template alias parameter)
Re: Review: A new stab at a potential std.unittests
Jonathan M Davis wrote: > On Saturday 20 November 2010 10:16:55 Lutger Blijdestijn wrote: >> I'm not particularly fond of this interface and think that a solution >> with a delegate / lazy or alias template parameter would be more >> convenient. However, until we have ast macros I do see the added value in >> this approach. >> >> Some remarks about the api, not a proper review of the code itself: >> >> - core.exception and std.string must be imported to use the module, >> relevant symbols should be selectively and publicy imported instead. > > I hadn't thought of that. Good idea. > >> - exception would be better abbreviated as ex instead of exc, I believe >> this is more conventional. (assertExThrown instead of assertExcThrown) > > I'll think about it. I don't think that I've often seen it abbreviated at > all. But if Ex really is more common, then that would be better. I know of std.exception.enforceEx, and catch(Exception ex) is also regularly used in examples. >> - assertExcThrown should fail if an exception is thrown that is not T or >> a subclass of T. (catch and throw AssertError) > > It currently catches the exact exception (well, throwable) that you tell > it to. The others are let through exactly like they would be with an > assert. It also means that you get to see exactly what the erroneous > exception was so that you can deal with it. An AssertError would be less > informative, maybe even misleading. You get an AssertError because it > didn't throw any exception, whereas you get the wrong exception if it > threw the wrong one. Suppose you want assert that a FileNotFoundException is thrown. Now if you get an Exception then: - technically the unittest has passed because no AssertError has been thrown (splitting hairs) - if for whatever reason you catch this error in the unittest, things will get screwed up - You (or possibly some other script) won' t get the same command line output, it's then harder to correlate the exception with the assertion I agree about wanting to know the original Exception though. I think this is possible by setting the .next field of AssertError with that exception. ... > >> I believe these assertions should be added: >> >> - assertExcThrown and assertExcNotThrown with a default T (should be >> Exception, not Throwable) > > That's not a bad idea, though personally, I tend to think that if someone > used an Exception rather than a derived type that they aren't be specific > enough (I'm sure that many would argue with me on that one though). It > might work to just give it a default parameter (and I do agree that the > default should be Exception rather than Throwable). I agree but it doesn't matter for general use, people will want this and this is also practice in phobos (mostly through the use of enforce I think). ... > >> - assertOpBinary, assertTrue and perhaps assertPred (where the predicate >> is an template alias parameter) > > I decided that assertTrue() was a waste of time, because that's what a > bare assert does. The same goes for assertFalse(), because all you have to > do is add ! in front of the expression. All of the functions that I have > are there to either improve the output (such as printing out the actual > values of the two values being compared in assertEqual()), or they get rid > of boilerplate code (such as the try-catch block and other details in > assertExcThrown!()). Except that assert does not print the expression which resulted in the assertion like all other functions do, so assertTrue does improve the output too. > As for assertOpBinary, are you suggesting a function which does the given > binary operation and then compares the result with the given expected > result? That would be a good addition. > > As for assertPred. I don't know what that would do. Would that take a > predicate and its parameters and then assert that the result was true? If > that's what you're looking for, then assertPredTrue and assertPredFalse > would be better. I think that you need to clarify quite what you meant > though. bool isSorted(); int[] numbers = getSortedNumbers(); assertPred!isSorted(numbers); It's the same as assert(isSorted(numbers)), except it allows for improved output. Not very important, but I find it common to use such predicates for testing so it might help. Alternatively assertTrue and assertFalse could take an optional predicate, defaulting to the identity and negation respectively: assertTrue!isSorted(numbers);
Re: Review: A new stab at a potential std.unittests
Jacob Carlborg wrote:
> On 2010-11-21 01:23, Jonathan M Davis wrote:
>> On Saturday 20 November 2010 08:03:52 Jacob Carlborg wrote:
>>> Why don't you use delegates instead of string mixins? For example,
>>> assertExcThrown, could take a delegate which calls the function you want
>>> to test instead of a string that represents the call. The mixin want be
>>> needed as well. Am I missing something?
>>
>> Well, delegates wouldn't be a bad idea, but they're unwieldy too. Would
>> you rather write
>>
>> assertExcThrown!Exception((){func(param1, param2);});
>>
>> or
>>
>> mixin(assertExcThrown!(Exception, `func(param1, param2)`));
>
> I would go with the delegate, but when you format the code like that it
> doesn't look any good (btw, no need for the extra pair of empty
> parentheses). I think this looks better:
>
> assertExcThrown!Exception({
> func(param1, param2);
> });
>
> And BTW, D needs a better way to pass a delegates to a function,
> something like the syntax that can be used in Scala:
>
> assertExcThrown!Exception {
> func(param1, param2);
> }
This is possible, but too surprising:
assertExcThrown!Exception = {
func(param1, param2);
};
with lazy:
assertExcThrown!Exception = func(param1, param2);
Re: std.algorithm.remove and principle of least astonishment
Andrei Alexandrescu wrote: ... > > I agree except for the fact that in my experience you want to iterate > over code points much more often than over code units. Iterating by code > unit by default is almost always wrong. That's why D's strings offer the > bidirectional interface by default. I have reasons to believe it was a > good decision. > > > Andrei Is there a plan to make std.string and std.algorithm more compatible with this view? Nearly all algorithms in std.string work with slices or substrings rather than code unit or points. I found it sometimes hard to mix and match that approach with the api that std.algorithm offers. Maybe I'm missing something.
future of std.process?
Some time ago a new std.process branch was made, which included support for pipes. Is there still a plan to integrate this in phobos? Does it depend on a decision regarding the io design?
Re: future of std.process?
Lars T. Kyllingstad wrote: > On Sun, 05 Dec 2010 15:51:18 +0100, Lutger Blijdestijn wrote: > >> Some time ago a new std.process branch was made, which included support >> for pipes. Is there still a plan to integrate this in phobos? Does it >> depend on a decision regarding the io design? > > That is still the plan, yes. The new std.process is pretty much done, > and has been for a while, but its incorporation in Phobos is being > blocked by bug 3979. (The bug was fixed a while ago, but the changes > were almost immediately reverted by another bug fix...) > > -Lars Thanks. I've noticed your personal copy at github, is it useable in the meantime? It doesn't suffer from the same issue?
Re: future of std.process?
Lars T. Kyllingstad wrote: > On Tue, 07 Dec 2010 08:49:07 -0500, Steven Schveighoffer wrote: > >> On Tue, 07 Dec 2010 03:47:53 -0500, Lars T. Kyllingstad >> wrote: >> >>> On Mon, 06 Dec 2010 19:10:23 +0100, Lutger Blijdestijn wrote: >>> >>>> Lars T. Kyllingstad wrote: >>>> >>>>> On Sun, 05 Dec 2010 15:51:18 +0100, Lutger Blijdestijn wrote: >>>>> >>>>>> Some time ago a new std.process branch was made, which included >>>>>> support for pipes. Is there still a plan to integrate this in >>>>>> phobos? Does it depend on a decision regarding the io design? >>>>> >>>>> That is still the plan, yes. The new std.process is pretty much >>>>> done, and has been for a while, but its incorporation in Phobos is >>>>> being blocked by bug 3979. (The bug was fixed a while ago, but the >>>>> changes were almost immediately reverted by another bug fix...) >>>>> >>>>> -Lars >>>> >>>> Thanks. I've noticed your personal copy at github, is it useable in >>>> the meantime? It doesn't suffer from the same issue? >>> >>> Yes, it works (and I just uploaded some minor changes that I had in my >>> local repo). Bug 3979 only sets in once you try to name the module >>> "std.process" and compile it together with the rest of Phobos. Note >>> that the code in my github repo is for POSIX only. Steven >>> Schveighoffer has done the Windows work, and I don't have his code. >> >> That reminds me, I should make sure that doesn't get lost, it's not >> checked in anywhere... >> >> Maybe I should send you my code. > > Sure, feel free to do so. :) I'm very curious to see how you solved the > pipe stuff! > > Even though we can't include it in Phobos before 3979 is fixed, we can at > least combine our code, publish it somewhere, and start the review > process. > > Also, we should probably get the whole File buffering thing sorted out. > That discussion kinda ebbed out without any good solution presenting > itself... > > -Lars Will you announce it if published? I'm interested in using it even though api is unstable, at least I have something until std.process is finished. I'll report back feedback / issues if you want.
Re: Deprecation schedule
Jonathan M Davis wrote: > On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote: >> I wonder what would be a good deprecation schedule. Consider >> http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example. >> >> We should now slowly deprecate std.utf.count. How should we go about it? >> >> T0: documentation marked as "scheduled for deprecation". >> T1: Function is deprecated and documentation updated to mention "has >> been deprecated" >> T2: Function is eliminated >> >> Question is, what are some good values for T1 - T0 and T2 - T1? > > I think that not doing T0 and T1 at the same time only makes sense if we > know that we're going to deprecate it but aren't ready to do so yet (like > if we were to do another release with std.date without putting in the new > std.datetime - we _know_ that we're going to deprecate std.date, but we > wouldn't be ready to actually do it yet, because it's replacement wasn't > yet in Phobos). So, in this case, I think that T0 and T1 should be done at > the same time. It's helpful to know if some module is going to be deprecated in the near future, even if an alternative is not ready. That is true for many modules in phobos. So a for T0 should be the moment the decision is made and T1 as soon as an alternative is ready - or the functionality is dropped entirely. > As for for how long a function should be deprecated and not yet removed, > that's a bit harder. How often do people update dmd? Part of me wants to > say 1 release, but I know that there are people out there who don't bother > updating for a release or two. How long before having a function > deprecated but still there becomes an issue (particularly if you end up > with very many of them)? And given the relatively fast pace of > development, if we were actually to deprecate everything that we wanted to > deprecate right now, I'm not sure that it would be all that short a list > (though, since it's mostly either whole modules or an entire language > feature like scoped local variables rather than individual functions, the > actual number of things that you'd have to list as deprecated would > probably be rather short). > > I'd say that T2 - T1 should be about 6 months at most at this point. If > Phobos dmd and Phobos were completely stable and had been for a while, > then something more like 2 years might be appropriate, but the pace of > development is still too fast for that to make sense. 6 months is still a > bit of an eternity for D at the moment, so that's probably enough right > now. I do think, however, that it's something that should change once > Phobos has become more stable. > > - Jonathan M Davis Although it's good to remove things, why should it be rushed? What is the inconvenience of having deprecated stuff lingering? Phobos users will still be reminded by the compiler that they should update the code, which is useful.
Re: Deprecation schedule
bearophile wrote: > Andrei: > >> T0: documentation marked as "scheduled for deprecation". >> T1: Function is deprecated and documentation updated to mention "has >> been deprecated" >> T2: Function is eliminated >> >> Question is, what are some good values for T1 - T0 and T2 - T1? > > T0 = T1 = 0 seconds > T2 = 2 months (2 releases) > > One year from now, in a similar situation: > T0 = 0 seconds, documentation marked as "scheduled for deprecation in next > release". T1 = 1 release (1 month) > T2 = 3-6 releases (3 - 6 months) > > Bye, > bearophile That is very harsh for T2, it means that at this point anything you write might not compile anymore with the newest phobos in just 5 weeks time. Even 3 months is short, especially for a more stable point in time. I'd rather have T1 earlier and last longer, that way you can still compile the code.
Re: Please vote on std.datetime
Andrei Alexandrescu wrote: > Jonathan M. Davis has diligently worked on his std.datetime proposal, > and it has been through a few review cycles in this newsgroup. > > It's time to vote. Please vote for or against inclusion of datetime into > Phobos, along with your reasons. > > > Thank you, > > Andrei Vote yes. - code seems well written and tested, although I admit having looked only briefly at it - api is clear and comprehensive - good documentation - the functionality it covers is required by many applications
Re: http://d-programming-language.org/ 404 & small proposal
Andrei Alexandrescu wrote: > On 12/9/10 8:04 PM, Andrej Mitrovic wrote: >> The D website is 404'ing for the library page: >> >> http://d-programming-language.org/phobos/phobos.html >> >> And I've had an idea to make the documentation website a little easier to >> navigate. Here's what the docs look like with their old design: >> >> http://imgur.com/8Vdrj.jpg >> >> Now, that's quite a mess to look at. The text isn't aligned or anything >> so it doesn't look that good, and you can't really tell which of those >> names are functions, class definitions or enums, etc. >> >> So I just quickly sketched out what I'd like to see instead: >> >> http://imgur.com/0lufR.jpg >> >> Disregard the off coloring, font sizes, and my general lack of design >> skills please :). The main point is to put the links in a table so >> they're aligned and easier to browse, and maybe even categorize all the >> names by their type (functions/enums/etc). >> >> I'm pretty sure adding a table is trivial, but I don't know if we can >> automatically categorize all the names and put them in separate tables. >> >> Thoughts? >> > > Very nice initiative. I'm not sure how we can implement that easy > without considerable effort; currently, the list is generated with > Javascript using a flat list. To generate a more structured list, the > programmer would need to insert appropriate cues in the documentation. > > Andrei With the json files dmd produces it can be automated, and you can do it the ddoc way (so latex and other formats would also be supported.) A disadvantage is that ddoc processor has to be ran twice plus an additional pass over the json is needed. ddoc support for this would obviously be better. I got this far (but it uses non-standard css3): https://dl.dropbox.com/u/6777848/ddoc_index.jpeg I'll share the tool when it's more complete, if this is something that is wanted for phobos I am willing to put it together.
Re: Verbose checking of range category
It would be a welcome improvement. One downside is that the relation between the mismatched template and the range check is not there. I worry that it will be hard to understand when facing a lot of errors, but will have to try to find out. The error message dmd produces in the face of ambiguous overloading is the most model (foo matches both bar and baz). Template constraints are great, but have taken away the possibility of very good custom error messages that static if / else / assert have. unaryFun and binaryFun of std.functional for example give really helpful messages. I'm hesitant to suggest another feature, but maybe an 'else' counterpart to template constraint checks could go a long way.
Re: http://d-programming-language.org/ 404 & small proposal
Andrei Alexandrescu wrote: >> >> I'll share the tool when it's more complete, if this is something >> that is >> wanted for phobos I am willing to put it together. > > Yes please. Other Phobosites? > > Andrei I'm sorry, I did not understand what you meant.
Re: Why Ruby?
Simen kjaeraas wrote: > Ary Borenszweig wrote: >> Code is read many more times than it is written and so it is of huge >> important that code is as readable as possible. Of course this is a >> subjective matter, but I don't understand why some people think __traits >> or __gshared are ok. > > __gshared is ok. It is supposed to indicate low-level hackery and > unpleasant, rough edges. __traits, however, is an abomination and should > be shot repeatedly with something high-caliber. > Is std.traits not sufficient for that?
Re: Why Ruby?
Jacob Carlborg wrote:
...
>
> If we have a look at the next code example from the talk there is no
> clear and natural way to translate it into D, first the Ruby code:
>
> class PeopleController < ActionController::Base
> before_filter :authenticate
>
> def index
> @people = Person.where("age > 30").order("name DESC")
>
> respond_to do |format|
> format.html
> format.xml { render :xml => @people.to_xml }
> end
> end
> end
>
> And then the translated D code:
>
> class PeopleController : ActionController.Base
> {
> Person[] people;
>
> mixin before_filter!(authenticate);
>
> void index ()
> {
> people = Person.where("age > 30").order("name DESC");
>
> respond_to((Format format) {
> format.html;
> format.xml({
> render(["xml" : people.to_xml]);
> });
> });
> }
> }
I agree with lambda syntax, iirc the trailing delegate was introduced around
the time lazy made it into the language. However, D has some features of its
own that could make for a better translation.
In rails associative array literals are used as a workaround for the lack of
named parameters in ruby. You can take advantage of overloading and template
specialization in D to reduce the need for such a feature, which looks very
strange anyway in D code. Furthermore, the code block syntax is used in ruby
everywhere, but in D we also have nested functions, alias template
parameters and lazy parameters.
I'm sure a skilled designer could make a much better api than literally
translating RoR. Perhaps something like this is already better:
class PeopleController
: ActionController!( before_filter!authenticate )
{
People[] people;
void index ()
{
people = Person.where("age > 30").order("name DESC");
void respond(Format format)
{
format.html;
format.xml( render(people.toXml) );
}
doResponse( &respond );
}
}
One thing to consider is that a certain class of errors in D is caught by
the type system. Even when you don't see static typing as an advantage
perse, you can't ignore the fact that you have to write unittests for all
these cases in a dynamic language whereas with static typing you save this
need.
Re: Why Ruby?
Adam D. Ruppe wrote: > so wrote: >> Am i alone thinking D one better here? > > No, I find foreach to be significantly better than the ruby > blocks too. I recently argued on the gentoo forums that > they are virtually equivalent too: > http://forums.gentoo.org/viewtopic-p-6500059.html#6500059 > > opApply is implemented with a delegate! You can't compare foreach to code blocks. foreach is just one function that enjoys syntactic sugar, whereas code block syntax is available for every function in ruby.
Re: Why Ruby?
Andrei Alexandrescu wrote:
> On 12/12/10 6:44 AM, Jacob Carlborg wrote:
> [snip]
>> Conclusion:
>>
>> D needs a better and nicer looking syntax for passing delegates to
>> functions.
>>
>> Suggestion:
>>
>> If a function takes a delegate as its last parameter allow the delegate
>> literal to be passed outside the parameter list, after the function
>> call, and allow to drop the semicolon. Also allow type inference of the
>> delegate parameters. Looking like this:
>>
>> foo(bar) {
>> // do something with bar
>> }
>>
>> If the function takes other arguments before the delegate I have two
>> suggestions, either just have two parameter lists, each in its own pair
>> of parentheses:
>>
>> foo(3, 'a')(bar) {
>> // do something with bar
>> }
>>
>> Or have two parameter lists in one pair of parentheses seperated by a
>> semicolon:
>>
>> foo(3, 'a' ; bar) {
>> // do something with bar
>> }
>>
>> I think that the syntax I've used in these examples has previously been
>> proposed.
>
> Yah, it's been discussed a couple of times in the past. Both Walter and
> myself are favorable to finding a good, simple lowering that improves
> syntax without adding burden to the person who learns the language.
>
> By the way, lowerings are great. Defining features as lowerings is a
> huge win in language definition, ease of understanding, and correctness
> of implementation. Features that have been implemented through lowering
> have had very few bugs - e.g. scope() and the new operator overloading,
> which was only a week's work.
>
> Getting back to finding a good lowering, consider:
>
> foreach (a, b ; c) stmt
>
> A Ruby syntactic equivalent that clarifies what belongs to the block and
> what belongs to the invoker of the block is:
>
> c.each do |a, b|
>stmt
> end
>
> So a and b are passed to the block and each is a method of c (or more
> general, each is a function called taking c as an argument). Going now
> back to D, we can imagine the following lowering:
>
> fun (a, b ; c) stmt
>
> =>
>
> fun(c, (a, b) { stmt })
>
> This could and should be generalized for more parameters, which I'm sure
> is very useful:
>
> fun (a, b ; c, d) stmt
>
> =>
>
> fun(c, d, (a, b) { stmt })
>
> Of course "fun" could be actually "obj.method".
>
> With this we have a compelling syntax that has semantics obtained via
> lowering.
>
>
> Andrei
This would be so nice. You could even implement foreach as a library
function this way.
Re: New syntax for string mixins
Nick Sabalausky wrote: > "Jacob Carlborg" wrote in message > news:iednio$2vj...@digitalmars.com... >> >> I can't quite visualize how the final code will look like and as you say >> it's hard without a formal definition of AST macros. But I think somehow >> it would be possible, I mean instead of combining strings one combine >> expressions/syntax. But I don't know if it would be possible to combine >> incomplete expressions. >> > > One parallel that may or may not be applicable, but might be worth > considering, is dynamically building XHTML: Using a string-template system > is generally found to work very well, but building it via a DOM > (essentially an AST) is often considered a bit of a pain. I guess the > simplest take-away would be that string-based approaches may be easier get > working well. FWIW. The newest vb.net has this feature, if I understand you correctly, via xml literals and linq expressions. It is quite convenient. http://msdn.microsoft.com/en-us/library/bb384460.aspx
Re: is it possible to learn D(2)?
Gour wrote: > Hello, > > Seeing all the threads here about improving D(2) syntax for different > features of the language, I just wonder if it's possible to learn D(2) > language which is so much in flux by using TDPL as reference? > > Now I may have some time to learn D(2), but wonder when will the > language become more stable or the proposals/improvements discussed > here (I skip over majority of such threads) are not major changes? > > > Sincerely, > Gour > Yes, it's not so much in flux as it seems. Like Jonathan says, it's more that some parts of phobos are unstable and certain bugs can stand in the way. Breaking changes to the language itself are very rare / unlikely now. I can't remember when such a thing broke my code whereas it used to happen every month. You can browse the changelog*, which lists new features for every release, to get a picture of the evolution. But also consider that most of the issues talked about are the more 'advanced' parts of the language. The bread and butter features haven't been changed that much for a long time now and are pretty solid. * http://www.digitalmars.com/d/2.0/changelog.html
Re: try...catch slooowness?
spir wrote: > Hello, > > > I had not initially noticed that the 'in' operator (for AAs) returns a > pointer to the looked up element. So that, to avoid double lookup in cases > where lookups may fail, I naively used try...catch. In cases of very > numerous lookups, my code suddenly became blitz fast. So that I wondered > about exception handling efficiency. Below a test case (on my computer, > both loops run in about the same average time): > Catching exceptions is known to be a bit costly. Generally, in C family languages with exceptions (such as D), it is considered bad practice to use exceptions for regular control flow. The cost is therefore acceptable because it is not suffered on the normal, happy code path. That the performance cost is so huge is likely not only the inherent overhead of exceptions, but probably also some extra cache misses or something like that.[needs analysis]
Re: emscripten
Adam D. Ruppe wrote: > bearophile: >> On a more modern browser it works "well enough" (Firefox 4). > > This is a bit of a rant, but I hate how the web community > always uses "modern browser" like this. > > I ran this site on Firefox 3.6.3. The most recent one it offers > on getfirefox.com is 3.6.13 - I'm not very far behind! My about > firefox box says Gecko from April 2010. > > That should be modern by any sane definition! > > (Now, my every day browser, Konqueror 3.5.7, is (c) 2005. So > I can understand it not being a "modern browser". But it works > for me so I won't change it. Something I find hilarious though: > it's CSS2 compliance was better than firefox up until about > last year! > > I just wrote a site going wild with css for a web demo for the > company, and it worked almost as well in my old Konq as it did > in my newer Firefox. The kde folks did a really impressive job > there.) > > > Anyway, it just irks me that so many web evangelists say "modern" > when they really mean "bleeding edge". And in Google's case, it > is even worse: when they say "all modern browsers", they actually > mean "/our/ bleeding edge beta". It really annoys me. > I'm more used to the term in "every modern browser, except IE", in which case it is usually correct and modern means something from this or last year (except IE). Good old Konq from 2005 for example has better CSS2 support than IE8.
Re: Why Ruby?
foobar wrote:
...
>
> I wasn't referring to the above which still deals with the syntactic
> issue. I'm talking about making:
>
> sort!"a >b"(whatever);
> and
> sort(whatever, (a, b) { return a>b; });
>
> have the same performance. Thus obviating the need for the first form.
> the best form IMO would be of course:
>
> whatever.sort((a, b) { return a>b; });
>
Would be nice, but:
- is it even possible (performance-wise)?
- can you enforce this performance constraint? There is a big difference
between inlining a lexical closure and creating a full one on the heap.
- with template alias parameters, its easy to compose more complex types at
compile time, you will lose this ability.
Re: gdc-4.5 testing
Anders F Björklund wrote: > Iain Buclaw wrote: Other than that, it seemed to apply cleanly to Fedora 14's version of GCC (gcc-4.5.1-20100924) > >>> Not only applied, but also seems to be working... :-) >>> Once the enormous build and test completed, that is. >>> So now you can install both "ldc" and "gcc-d" (gdc), >>> and work with both Tango and Phobos from RPM packages. > >> That's certainly nice to hear, considering the number of changes required >> were considerably less than what was needed for gcc-4.4 (then again, many >> of them were backports from gcc-4.5 anyway ;). Of those changes made, >> they all turned out to be pretty quick/lazy edits. > > I uploaded the packages to SourceForge, if anyone else > wants to try them... It's made for Fedora 14 (x86_64): Thnx, installs and works fine for a few quick tests. Would be great to see the first D2 compiler in the next fedora release, and debian / ubuntu too of course. Great work!
Re: gdc-4.5 testing
Anders F Björklund wrote: > Lutger Blijdestijn wrote: >>> I uploaded the packages to SourceForge, if anyone else >>> wants to try them... It's made for Fedora 14 (x86_64): >> >> Thnx, installs and works fine for a few quick tests. Would be great to >> see the first D2 compiler in the next fedora release, and debian / ubuntu >> too of course. Great work! >> > > So that would be two different requests, the first is making > a new package for D2 and the second is upgrading to GCC 4.6... > > https://fedoraproject.org/wiki/Features/GCC46 > > I believe that Ubuntu are sticking with GCC 4.5.x for Natty, > or at least 4.5.1 is what is in the current Alpha 1 release ? > > http://packages.ubuntu.com/natty/gcc > > The current "dmd" packages have an issue with /usr/bin/dmd > and /usr/include/d/dmd conflicts between 1.0xx and 2.0yy RPM, > even if /usr/lib/libphobos.a and /usr/lib/libphobos2.a don't. > Any packages for GDC using D2 would have the same problem... > > But it should be possible to use shims and symlinks to make > both installable, at least that's how it works on Mac OS X ? > A bigger problem is finding more developers for GCC46 and D2, > or perhaps upgrading LDC/Tango to D2 in the case of Fedora ? > > --anders Yes, it requires some thought and manpower obviously. I'm not a packager, I don't what exactly is proper way to do it, but Fedora already packages python 2.x and python 3.x side by side, so perhaps that is a start. For Fedora I think D2 could be positioned as an alternative to mono in the long run, it fits the distro very well.
Re: Why is D slower than LuaJIT?
I meant to link this, it includes all benchmarks and ranks gdc at 5th place and dmd at 8 (from 2008): http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
Re: Why is D slower than LuaJIT?
Andreas Mayer wrote: > Walter Bright Wrote: > >> I notice you are using doubles in D. dmd currently uses the x87 to >> evaluate doubles, and on some processors the x87 is slow relative to >> using the XMM instructions. Also, dmd's back end doesn't align the >> doubles on 16 byte boundaries, which can also slow down the floating >> point on some processors. > > Using long instead of double, it is still slower than LuaJIT (223 ms on my > machine). Even with int it still takes 101 ms and is at least 3x slower > than LuaJIT. > >> Both of these code gen issues with dmd are well known, and I'd like to >> solve them after we address higher priority issues. >> >> If it's not clear, I'd like to emphasize that these are compiler issues, >> not D language issues. > > I shouldn't use D now? How long until it is ready? You may want to explore the great language shootout before drawing that conclusion: http://shootout.alioth.debian.org/ LuaJit ranks high there, but still a bit below the fastest compiled languages (and the fastest java). D is not included anymore, but it once was and these benchmarks can still be found: http://shootout.alioth.debian.org/debian/performance.php LuaJit performance is impressive, far above any 'scripting' language. Just look at some numbers in the shootout comparing it to ruby or python.
Re: Clay language
bearophile wrote: > Andrei: > >> FWIW I just posted a response to a question asking for a comparison >> between Clay and D2. >> >> http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/ > > Just few comments: > >> The docs offer very little on Clay's module system (which is rock solid >> in D2). > > D2 module system may be fixed, but currently it's not even bread-solid. > > The Clay syntax for imports is more similar to what I have desired for D > (but that () syntax is not so good): > > import foo.bar; // Imports module foo.bar as a qualified path > // use "foo.bar.bas" to access foo.bar member bas > import foo.bar as bar; // Imports module foo.bar with alias bar > // use "bar.bas" to access foo.bar member bas > import foo.bar.(bas); // Imports member bas from module foo.bar > // use "bas" to access foo.bar member bas > import foo.bar.(bas as fooBarBas) // Imports member bas with alias > fooBarBas import foo.bar.*; // Imports all members from module foo.bar This looks like a subset of the D module system. The only difference is 'static' import by default and the .* feature which has to be implemented by the library author in D. Are those the things you find missing in D? > I don't know about Modula3 module system, I will search info about it. > > >>Clay mentions multiple dispatch as a major feature. Based on extensive >>experience in the topic I believe that that's a waste of time. Modern C++ >>Design has an extensive chapter on multiple dispatch, and I can vouch next >>to nobody uses it in the real world. Sure, it's nice to have, but its >>actual applicability is limited to shape collision testing and a few toy >>examples.< > > I think double dispatch is enough, it cover most cases and keeps both > compiler complexity low enough. If you put double dispatch with a nice > syntax in D then maybe people will use it. There are many things that > people in other languages use that C++ programmers don't use because using > it in C++ is ugly, a pain, unsafe, etc. The visitor pattern is used enough > in Java (Scala too was designed to solve this problem). > > Bye, > bearophile I think I agree here. I have never programmed much in a language with multiple dispatch, but everytime I see dynamic casting or the visitor pattern in an OOP program I think about how that would be so much better. Honestly its just speculation, but I guess that the lack of interest is because it is not a widely known and available solution. Library implementations have issues, both usability and performance wise.
Re: Serenity web framework - early feedback wanted
Very interesting project, will you commit to D1 or consider supporting D2 in the future?
Re: Happy New Year!!!
Happy new year, best wishes to everyone and D!
Re: Moving to D
Adrian Mercieca wrote: > Hi everyone, > > I am currently mulling if I should be adopting D as my (and subsequently > my company's) language of choice. > > We have great experience/investment in C++, so D seems - from what I've > seen so far - as the logical step; D seems to me to be as C++ done right. > I'm also looking at Go in the process, but Go seems to be more of a 'from > C' progression, whilst D seems to be the 'from C++' progression. > > I am only worried about 2 things though - which I've read on the net: > > 1. No 64 bit compiler > 2. The Phobos vs Tango issue: is this resolved now? This issue represents > a major stumbling block for me. > > Any comments would be greatly appreciated. > > Thanks. 64 bit support is the main focus of dmd development at the moment. I take it that you would first evaluate D for a while, possibly 64-bit support will arrive when you are ready and need it. gdc development is also going strong. As for tango vs phobos the situation is now that most of development in the previous version of D (released circa 2007 iirc) is done with Tango. There is also a fine 64-bit compiler for D1, LDC. The feature set of D1 is frozen and significant (some backwards incompatible) changes have been made since. There isn't any sign that Tango will be ported to D2 and phobos is shaping up to be a fine library for D2. Some parts of phobos are still in flux, though other parts are more stable. Perhaps you'll find this thread about experiences with D worth a read: http://thread.gmane.org/gmane.comp.lang.d.general/45993
Re: Who here actually uses D?
Nick Sabalausky wrote: > "Robert Clipsham" wrote in message > news:ift0mt$60...@digitalmars.com... >> On 03/01/11 16:53, Nick Sabalausky wrote: >>> There seems to be a lot of conflicting information about Qt then. I read >>> a >>> post from one of the Qt devs that said basically what I said above. So I >>> guess at this point I haven't a clue what to make of Qt. Oh well, anyone >>> know if wx is coming to D2? >> >> Having used both Qt and QtD on (Windows|Linux|OS X), I can say it looks >> native on all platforms (who cares if it actually is, it looks and feels >> it). >> > > The typical problem with things that look native but aren't technically > native is that there's almost inevitably things that don't work right. For > instance, they may ignore the system color scheme, they may fail to work > with tools that inspect/manipulate other app's controls, they may not > behave correctly outside of the most common use-cases, they may ignore > system-wide skin settings (such things do, and should, exist for Windows), > and I've even seen ones that actually go and emulate the wrong system > style (For instance, Chrome/Iron's dialog windows look like Aero...but I'm > on XP, and if I were on Win7 I'd be using the Classic theme anyway. Very > very sloppy). > > If it turns out that Qt's self-drawn controls doesn't have any of those > issues, then I agree there's no problem at all. I'd also be incredibly > impressed. Qt uses the native theme managers on mac osx and windows for styling. I haven't tried it but Qt apps should be able to cope with custom color schemes, unless of course the developer has overridden that. Perhaps some animations / effects are different, but colors should be fine.
Re: Coccinelle
bearophile wrote: > Sometimes D changes, and this requires many simple changes in Phobos. In > such and other cases to save some time I suggest D developers (Walter too) > to take a look at the free Coccinelle tool: http://coccinelle.lip6.fr/ > > I think Coccinelle works on D code too (untested). It allows to define > safe semantic patches, that despite being very short, are able to patch > lot of code in seconds. Coccinelle looks useful for DMD/druntime too. > > Bye, > bearophile OT: the picture with the ninja turtle reference and tux bashing a bug is hilarious, just need a D man to join the party!
Re: Dynamic D
Very cool! The restriction with calling zero-args functions is unfortunate, could this be solved by turning it into a class and dynamically checking whether the type is a function and then invoke it if it is? I would also change implicit declarations into an error, I see you have an throw statement for that but commented out.
Re: std.unittests for (final?) review
Michel Fortin wrote:
> I'm not sold on the concept. The whole point of this module seems to
> offer a way to replace the built-in assertion mechanism with a
> customized one, with the sole purpose of giving better error messages.
> So we're basically encouraging the use of:
>
> assertPredicate!"a > b"(a, b, "message");
>
> instead of:
>
> assert(a > b, "message");
>
> It looks like an uglification of the language to me.
As you said, it is all about the error messages, not replacing assert perse.
So this comparison would be more fair, using the syntax suggested by Andrei:
assertPred!">"(a, b);
vs
assert(a > b, format("a > b failed: [%s] is not > [%s]", a, b) );
If you really want the error message, regular asserts are a bit uglier and
duplicate code.
Cutting down on the characters further, 'expect' could be used instead of
assertPred. Some unittest libraries also use this, but I can't remember
which one. I think it then makes sense to unify everything:
expect!">"(a, b);
expect!Exception( { throw new Exception(""); } () );
Re: Moving to D
Nick Sabalausky wrote: > "Caligo" wrote in message > news:mailman.451.1294306555.4748.digitalmar...@puremagic.com... >> On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright >> wrote: >> >>> >>> That's pretty much what I'm afraid of, losing my grip on how the whole >>> thing works if there are multiple dmd committers. >>> >>> Perhaps using a modern SCM like Git might help? Everyone could have >>> (and >> should have) commit rights, and they would send pull requests. You or >> one of the managers would then review the changes and pull and merge with >> the >> main branch. It works great; just checkout out Rubinius on Github to see >> what I mean: https://github.com/evanphx/rubinius >> > > I'm not sure I see how that's any different from everyone having "create > and submit a patch" rights, and then having Walter or one of the managers > review the changes and merge/patch with the main branch. There isn't because it is basically the same workflow. The reason why people would prefer git style fork and merge over sending svn patches is because these tools do the same job much better. github increases the usability further and give you nice pr for free. otoh I understand that it's not exactly attractive to invest time to replace something that also works right now.
Re: std.unittests for (final?) review
Michel Fortin wrote:
> On 2011-01-06 06:45:41 -0500, Lutger Blijdestijn
> said:
>
>> As you said, it is all about the error messages, not replacing assert
>> perse. So this comparison would be more fair, using the syntax suggested
>> by Andrei:
>>
>> assertPred!">"(a, b);
>>
>> vs
>>
>> assert(a > b, format("a > b failed: [%s] is not > [%s]", a, b) );
>>
>> If you really want the error message, regular asserts are a bit uglier
>> and duplicate code.
>
> The whole point of my proposal is to make the regular asserts print a
> message similar to yours *by default*, when you don't specify any
> message. This is possible because assert is not a function, it's a
> language construct handled by the compiler. The compiler has access to
> the whole expression tree, and it can rewrite the code to store
> intermediate results in variables it can later give to the assertion
> handler in case of failure.
>
>
I understood, but was reacting to the proposition that assertPred is not an
improvement over the current situation, isn't that what you were saying?
Just being pragmatic, it's unlikely such big changes to assert are going to
land in dmd anytime soon. But if they are, yeah that would be cool.
Re: Moving to D
Daniel Gibson wrote: > Am 06.01.2011 23:26, schrieb Nick Sabalausky: >> "Daniel Gibson" wrote in message >> news:ig57ar$1gn...@digitalmars.com... >>> Am 06.01.2011 20:46, schrieb Walter Bright: Russel Winder wrote: > Pity, because using one of Mercurial, Bazaar or Git instead of > Subversion is likely the best and fastest way of getting more quality > contributions to review. Although only anecdotal in every case where a > team has switched to DVCS from CVCS -- except in the case of closed > projects, obviously -- it has opened things up to far more people to > provide contributions. Subversion is probably now the single biggest > barrier to getting input on system evolution. A couple months back, I did propose moving to git on the dmd internals mailing list, and nobody was interested. One thing I like a lot about svn is this: http://www.dsource.org/projects/dmd/changeset/291 where the web view will highlight the revision's changes. Does git or mercurial do that? The other thing I like a lot about gif is it sends out emails for each checkin. >>> >>> >>> It's not SVN but trac doing this. >>> And trac's mercurial plugin seems to support that as well: >>> http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets >>> >>> Bitbucket also supports that kind of view, see for example: >>> https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c >>> >>> The GitPlugin should support that as well, if I interpret the feature >>> list correctly: http://trac-hacks.org/wiki/GitPlugin >>> >>> Dsource seems to support both git and mercurial, but I don't know which >>> projects use them, else I'd them as examples to see how those trac >>> plugins work in real life. >>> >> >> DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd >> > > http://www.dsource.org/projects/ddmd/changeset?new=rt%40185%3A13cf8da225ce&old=rt%40183%3A190ba98276b3 > "Trac detected an internal error:" > looks like dsource uses an old/broken version of the mercurial plugin. > But normally it *should* work, I think. This works: http://www.dsource.org/projects/ddmd/changeset/183:190ba98276b3
Re: Moving to D
Nick Sabalausky wrote: > "Caligo" wrote in message > news:mailman.461.1294366839.4748.digitalmar...@puremagic.com... >> >> BitBucket has copied almost everything from Github, and I don't >> understand how they've never been sued. >> >> http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html >> > > That page looks like the VCS equivalent of taking pictures of sandwiches > from two different restaurants and then bitching "Oh my god! What a > blatant copy! Look, they both have meat, lettuce and condiments between > slices of bread! And they BOTH have the lettuce on top of the meat! What a > pathetic case of plagiarism!" Bah. Really? When I first visited bitbucket, I though this was from the makers of github launching a hg site from their github code, with some slightly altered css. There is quite a difference between github, gitorious and launchpad on the other hand.
Re: Moving to D
Lutger Blijdestijn wrote: > Nick Sabalausky wrote: > >> "Caligo" wrote in message >> news:mailman.461.1294366839.4748.digitalmar...@puremagic.com... >>> >>> BitBucket has copied almost everything from Github, and I don't >>> understand how they've never been sued. >>> >>> http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html >>> >> >> That page looks like the VCS equivalent of taking pictures of sandwiches >> from two different restaurants and then bitching "Oh my god! What a >> blatant copy! Look, they both have meat, lettuce and condiments between >> slices of bread! And they BOTH have the lettuce on top of the meat! What >> a pathetic case of plagiarism!" Bah. > > Really? When I first visited bitbucket, I though this was from the makers > of github launching a hg site from their github code, with some slightly > altered css. There is quite a difference between github, gitorious and > launchpad on the other hand. To be clear: not that I care much, good ideas should be copied (or, from your perspective, bad ideas could ;) )
Re: Patterns of Bugs
Walter Bright wrote: > Jonathan M Davis wrote: >> On and Off would be much better, but I suspect that it's one of those >> things where they chose symbols instead so that they didn't have to worry >> about internationalization. That way, it confuses _everyone_ instead of >> just non- English speakers. ;) > > I suspect as much, too, but at least "on" and "off" can be looked up in a > dictionary. There's no hope for O and |. I always assumed they meant 0 and 1. Then it's easy, just put it in an if() statement :)
Re: DVCS (was Re: Moving to D)
Walter Bright wrote: >> Looks like meld itself used git as it's repository. I'd be surprised if >> it doesn't work with git. :-) > > I use git for other projects, and meld doesn't work with it. What version are you on? I'm using 1.3.2 and its supports git and mercurial (also committing from inside meld & stuff, I take it this is what you mean with supporting a vcs).
Re: eliminate junk from std.string?
Andrei Alexandrescu wrote: > On 1/11/11 11:21 AM, Ary Borenszweig wrote: >> Why care where they come from? Why not make them intuitive? Say, like, >> "Always camel case"? > > If there's enough support for this, I'll do it. > > Andrei +1
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
Nick Sabalausky wrote: > "Andrei Alexandrescu" wrote in message > news:ignon1$2p4k$1...@digitalmars.com... >> >> This may sometimes not be what the user expected; most of the time they'd >> care about the code points. >> > > I dunno, spir has succesfuly convinced me that most of the time it's > graphemes the user cares about, not code points. Using code points is just > as misleading as using UTF-16 code units. I agree. This is a very informative thread, thanks spir and everybody else. Going back to the topic, it seems to me that a unicode string is a surprisingly complicated data structure that can be viewed from multiple types of ranges. In the light of this thread, a dchar doesn't seem like such a useful type anymore, it is still a low level abstraction for the purpose of correctly dealing with text. Perhaps even less useful, since it gives the illusion of correctness for those who are not in the know. The algorithms in std.string can be upgraded to work correctly with all the issues mentioned, but the generic ones in std.algorithm will just subtly do the wrong thing when presented with dchar ranges. And, as I understood it, the purpose of a VleRange was exactly to make generic algorithms just work (tm) for strings. Is it still possible to solve this problem or are we stuck with specialized string algorithms? Would it work if VleRange of string was a bidirectional range with string slices of graphemes as the ElementType and indexing with code units? Often used string algorithms could be specialized for performance, but if not, generic algorithms would still work.
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
Michel Fortin wrote: > On 2011-01-15 05:03:20 -0500, Lutger Blijdestijn > said: ... >> >> Is it still possible to solve this problem or are we stuck with >> specialized string algorithms? Would it work if VleRange of string was a >> bidirectional range with string slices of graphemes as the ElementType >> and indexing with code units? Often used string algorithms could be >> specialized for performance, but if not, generic algorithms would still >> work. > > I have my idea. > > I think it'd be a good idea is to improve upon Andrei's first idea -- > which was to treat char[], wchar[], and dchar[] all as ranges of dchar > elements -- by changing the element type to be the same as the string. > For instance, iterating on a char[] would give you slices of char[], > each having one grapheme. > ... Yes, this is exactly what I meant, but you are much clearer. I hope this can be made to work!
Re: endsWith() doesn't work with const(wchar[])s
Jonathan M Davis wrote: > On Thursday 13 January 2011 21:21:06 %u wrote: >> Hi, >> >> I've noticed that some functions, such as algorithm.endsWith, don't work >> with constant arrays. Is this a bug, or is there a reason behind it? It >> forces the user to perform dangerous casts to avoid object creation, and >> it doesn't seem like the functions actually need to perform any >> manipulations. > > Phobos doesn't really deal with const or immutable correctly at this > point. A number of things which should be able to handle const or > immutable can't. And then there are things which you'd think _should_ be > able to but can't because of the transivity of const and immutable. There > are a number of outstanding bugs related to const and immutable which > makes dealing with them at times a bit of a pain if not outright > impossible. It's on the list of things to be focused on after the 64-bit > port of dmd is done. > > As it stands, there are a number of algorithms which just won't work with > const or immutable arrays. > > Regardless, a fully const array is never going to work with a function > like endsWith() for the simple reason that such functions have to actually > be able to process the range that they're given, and if the range is > const, you can't call popFront() or popBack() on it, so it just isn't > going to work. > > Now, if you take a _slice_ of a const array, it should work, because while > the elements of the array will remain const, the slice itself won't be, so > endsWith() can process it. > > - Jonathan M Davis A slice won't work because it is still const(T[]). It can implicitly convert to const(T)[], but I believe that is a bug currently.
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
Steven Schveighoffer wrote: ... >> I think a good standard to evaluate our handling of Unicode is to see >> how easy it is to do things the right way. In the above, foreach would >> slice the string grapheme by grapheme, and the == operator would perform >> a normalized comparison. While it works correctly, it's probably not the >> most efficient way to do thing however. > > I think this is a good alternative, but I'd rather not impose this on > people like myself who deal mostly with English. I think this should be > possible to do with wrapper types or intermediate ranges which have > graphemes as elements (per my suggestion above). > > Does this sound reasonable? > > -Steve If its a matter of choosing which is the 'default' range, I'd think proper unicode handling is more reasonable than catering for english / ascii only. Especially since this is already the case in phobos string algorithms.
Re: DVCS (was Re: Moving to D)
Nick Sabalausky wrote: > "Andrei Alexandrescu" wrote in message > news:igt2pl$2u6e$1...@digitalmars.com... >> On 1/15/11 2:23 AM, Nick Sabalausky wrote: >>> I still use CRTs (one big reason being that I hate the idea of only >>> being able to use one resolution) >> >> I'd read some post of Nick and think "hmm, now that's a guy who follows >> only his own beat" but this has to take the cake. From here on, I >> wouldn't be surprised if you found good reasons to use whale fat powered >> candles instead of lightbulbs. >> > > Heh :) Well, I can spend no money and stick with my current 21" CRT that > already suits my needs (that I only paid $25 for in the first place), or I > can spend a hundred or so dollars to lose the ability to have a decent > looking picture at more than one resolution and then say "Gee golly whiz! > That sure is a really flat panel!!". Whoop-dee-doo. And popularity and > trendyness are just non-issues. Actually nearly all lcds below 600$-800$ price point (tn-panels) have quite inferior display of colors compared to el cheapo crt's, at any resolution.
Re: endsWith() doesn't work with const(wchar[])s
Jonathan M Davis wrote: > On Saturday 15 January 2011 09:02:55 Lutger Blijdestijn wrote: >> Jonathan M Davis wrote: >> > On Thursday 13 January 2011 21:21:06 %u wrote: >> >> Hi, >> >> >> >> I've noticed that some functions, such as algorithm.endsWith, don't >> >> work with constant arrays. Is this a bug, or is there a reason behind >> >> it? It forces the user to perform dangerous casts to avoid object >> >> creation, and it doesn't seem like the functions actually need to >> >> perform any manipulations. >> > >> > Phobos doesn't really deal with const or immutable correctly at this >> > point. A number of things which should be able to handle const or >> > immutable can't. And then there are things which you'd think _should_ >> > be able to but can't because of the transivity of const and immutable. >> > There are a number of outstanding bugs related to const and immutable >> > which makes dealing with them at times a bit of a pain if not outright >> > impossible. It's on the list of things to be focused on after the >> > 64-bit port of dmd is done. >> > >> > As it stands, there are a number of algorithms which just won't work >> > with const or immutable arrays. >> > >> > Regardless, a fully const array is never going to work with a function >> > like endsWith() for the simple reason that such functions have to >> > actually be able to process the range that they're given, and if the >> > range is const, you can't call popFront() or popBack() on it, so it >> > just isn't going to work. >> > >> > Now, if you take a _slice_ of a const array, it should work, because >> > while the elements of the array will remain const, the slice itself >> > won't be, so endsWith() can process it. >> > >> > - Jonathan M Davis >> >> A slice won't work because it is still const(T[]). It can implicitly >> convert to const(T)[], but I believe that is a bug currently. > > No, I'm pretty sure that that isn't a bug. A slice is a new array. A > const(T)[] that points to the same elements of an array that's const(T[]) > can't change the elements any more than the const(T[]) can. So, const is > not violated for the elements. And since the slice is a new array, the > fact that you can alter the slice itself is completely valid. You can > resize the slice or set to an entirely different block of memory or > whatever, at it won't affect the original array, so it does not violate > the const-ness of the const(T[]) array. Yes, I agree the behavior is correct, it's indeed the inconsistency I was referring to. At this moment I'm not sure how it is gonna work out. I failed searching bugzilla, but relying on this behavior would make me a bit nervous. About the slicing, this works: const(int[]) n = [1,2,3]; const(int)[] a = n[]; assert(endsWith(a, 3)); but this doesn't: auto b = n[]; assert(endsWith(b, 3)); In conclusion, you still have to 'convert' the array to a different type, even though casting is not required for arrays (and arrays only). otoh, treating a const array as a range doesn't make any sense in the first place, since ranges must be mutable by definition. Arrays *are* special in the sense that they act both as a container and 'iterator' over that container. > So, no, it's not a bug. The bug is that this sort of behavior doesn't work > for general ranges - just arrays - and that we don't currently have a > means of making it work with general ranges. It cripples const and > immutable ranges, but it doesn't cripple const and immutable arrays. > > - Jonathan M Davis
Re: What Makes A Programming Language Good
Vladimir Panteleev wrote: > On Tue, 18 Jan 2011 12:10:25 +0200, bearophile > wrote: > >> Walter: >> >>> http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a- programming-language-good/ >> >> It's a cute blog post. It suggests that it will be good to: >> >> Getting Code: >> 1) Have a central repository for D modules that is easy to use for both >> submitters and users. > > Forcing a code repository is bad. Let authors use anything that they're > comfortable with. The "repository" must be nothing more than a database of > metadata (general information about a package, and how to download it). I'm pretty happy that my Fedora repositories are just a handful, most of which are setup out of the box. It's a big time saver, one of it's best features. I would use / evaluate much less software if I had to read instructions and download each package manually. >> - D code in such repository must Just Work. > > This is not practical. The only practical way is to put that > responsibility on the authors, and to encourage forking and competition. True, though one of the cool things Gregor did back the days with dsss is automagically run unittests for each package in the repository and publish the results. It wasn't perfect but gave at least some indication.
Re: What Makes A Programming Language Good
Vladimir Panteleev wrote: > On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn > wrote: > >> I'm pretty happy that my Fedora repositories are just a handful, most of >> which are setup out of the box. It's a big time saver, one of it's best >> features. I would use / evaluate much less software if I had to read >> instructions and download each package manually. > > I don't see how this relates to code libraries. Distribution repositories > simply repackage and distribute software others have written. Having > something like that for D is unrealistic. Why? It works quite well for Ruby as well as other languages.
Re: What Makes A Programming Language Good
Vladimir Panteleev wrote: > On Tue, 18 Jan 2011 14:36:43 +0200, Lutger Blijdestijn > wrote: > >> Vladimir Panteleev wrote: >> >>> On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn >>> wrote: >>> >>>> I'm pretty happy that my Fedora repositories are just a handful, most >>>> of >>>> which are setup out of the box. It's a big time saver, one of it's best >>>> features. I would use / evaluate much less software if I had to read >>>> instructions and download each package manually. >>> >>> I don't see how this relates to code libraries. Distribution >>> repositories >>> simply repackage and distribute software others have written. Having >>> something like that for D is unrealistic. >> >> Why? It works quite well for Ruby as well as other languages. > > Um? Maybe I don't know enough about RubyGems (I don't use Ruby but used it > once or twice for a Ruby app) but AFAIK it isn't maintained by a group of > people who select and package libraries from authors' web pages, but it is > the authors who publish their libraries directly on RubyGems. > Aha, I've been misunderstanding you all this time, thinking you were arguing against the very idea of standard repository and package *format*. Then I agree, I also prefer something more decentralized.
Build tools (was: What Makes A Programming Language Good)
Russel Winder wrote: > On Thu, 2011-01-20 at 12:32 +0100, Gour wrote: >> On Thu, 20 Jan 2011 10:13:00 + >> Russel Winder wrote: >> >> > SCons, Waf, and Gradle are currently the tools of choice. >> >> Gradle is (mostly) for Java-based projects, afaict? > > It is the case that there are two more or less distinct domains of build > -- JVM-oriented, and everything else. There is though nothing stopping > a single build system from trying to be more universal. Sadly every > attempt to date has failed for one reason or another (not necessarily > technical). > > Basically there seems to be a positive feedback loop in action keeping > the two domains separate: basically the tools from one domain don't > work well on the opposite domain and so no-one uses them there, so no > evolution happens to improve things. > > In this particular case, Gradle has great support for everything > JVM-related and no real support for C, C++, Fortran, etc. All attempts > to raise the profile of the Ant C/C++ compilation tasks, which Gradle > could use trivially, have come to nothing. > Do you have an opinion for the .NET world? I'm currently just using MSBuild, but know just enough to get it working. It sucks.
Re: Why is the "in" storage class missing from the ParameterStorageClass enum?
Andrej Mitrovic wrote: > On 1/21/11, Jonathan M Davis wrote: >> Umm. in is never the default. in is essentially an alias for const scope. >> The >> default is non-shared and mutable. >> >> - Jonathan M Davis >> > > That's what I thought. But I did saw it mentioned in this NG a couple > of times, I can't remember by who though. > > In any case, "in" seems to be missing from that enum definition. So > unless there's a specific reason for its absence, I'd file an > enhancement request. It's not needed because it should resolve to SCOPE for ParameterStorageClass and const is not a storage class, but a type constructor.
Re: renamepalooza time
Andrei Alexandrescu wrote: > The following symbols in std.string don't satisfy the Phobos naming > conventions and need to be renamed: > > LS PS capwords countchars entab expandtabs hexdigits icmp iswhite > ljustify lowercase maketrans newline octdigits removechars rjustify > sformat splitlines stripl stripr tolower tolowerInPlace toupper > toupperInPlace tr whitespace zfill > > Opinions on what to rename? > > > Thanks, > > Andrei Are there any conventions beyond what case to use? I see this common pattern: verb-noun (expand-tabs) but for what I think is called adverbs in English it is a bit mixed (ljustify vs stripl). These ones should be simply lower camel case: capwords countchars entab expandtabs hexdigits octdigits removechars tolower tolowerInPlace toupper toupperInPlace lowercase maketrans splitlines newline and whitespace: not sure how it is called in English, but these look like they have become single words and are fine. LS and PS: since these are constants, upper case is ok, although LS is inconsistent with std.path.linesep. iswhite -> isWhitespace tr: would say translate, but it's already there. Doesn't it overlap too much? Then these remain, I'm less sure about them: icmp ljustify rjustify sformat stripl stripr zfill Possibly: icmp: ok, it's a single abbreviation and insensitiveCompare is too much ljustify -> leftJustify rjustify -> rightJustify sformat -> stringFormat (?) stripl -> leftStrip stripr -> rightStrip zfill -> zeroFill (or better, ditch it and overload justify to take the filling char)
Re: first git commit
Andrei Alexandrescu wrote: > We've moved the entire camp to github: dmd compiler, phobos, druntime, > website, installer. > > I'm happy to report that we have our first git commit: > > https://github.com/D-Programming- Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 > > > Andrei Congrats! Isn't it shiny?
Re: join
Andrei Alexandrescu wrote: > On 1/18/11 2:55 PM, so wrote: >>> 2. joiner uses an idiom that I've experimented with in the past: it >>> defines a local struct and returns it. As such, joiner's type is >>> impossible to express without auto. I find that idiom interesting for >>> many reasons, among which the simplest is that the code is terse, >>> compact, and doesn't pollute the namespace. I'm thinking we should do >>> the same for Appender - it doesn't make much sense to create an >>> Appender except by calling the appender() function. >> >> Didn't know there was a solution to namespace pollution. >> This one is a very nice idea, are you planning to use it in phobos in >> general? >> Retro, Stride... there should be many. > > I plan to, albeit cautiously. Sometimes people would want e.g. to store > a member of that type in a class. They still can by saying > typeof(joiner(...)) but we don't want to make it awkward for them. > > Andrei I do this sometimes with Appender for splitting complex construction of a string between functions. Is that bad practice? What is the alternative idiom? If possible, please reconsider making Appender an existential type.
Re: join
Andrei Alexandrescu wrote: ... > Good idea, done. Will be part of the next commit. I plan to make one > more pass through std.algorithm anyway. If there's stuff you wish were > there (including stuff generalized from other modules), please let me > know. > > > Andrei I had need for a group() that constructs a range of ranges instead of tuple with count.
Re: d-programming-language.org
Andrei Alexandrescu wrote: > I've had some style updates from David Gileadi rotting in a zip file in > my inbox for a good while. It took me the better part of today to > manually merge his stale files with the ones in the repository, which > have in the meantime undergone many changes. > > The result is in http://d-programming-language.org. It has (or at least > should have) no new content, only style changes. I added a simple site > index, see http://d-programming-language.org/siteindex.html. It's not > linked from anywhere but gives a good entry point for all pages on the > site. > > One other link of possible interest is > http://d-programming-language.org/phobos-prerelease/phobos.html which > will contain the latest and greatest Phobos committed to github. I've > included build targets to synchronize /phobos-prerelease/ and /phobos/. > (Right now both contain the prerelease version; don't let that confuse > you.) > > In agreement with Walter, I removed the Digitalmars reference. The > message is simple - D has long become an entity independent from the > company that created it. (However, this makes the page header look > different and probably less visually appealing.) > > Anyway, this all is not done in relation or in response to the recent > related activity on redesigning the homepage. I just wanted to make sure > that we have a clean basis to start from, and am looking with interest > at the coming developments. > > > Cheers, > > Andrei It looks great. Is it possible to create a github repository specifically for this site? That would help a lot with contributing. I'll revisit taking a stab at creating good indexes soon, sorry for the delay.
Re: Suggestion: New D front page
Adam D. Ruppe wrote: >> Sorry to harp on security issues, but what are you doing to protect >> yourself from those compile and run arbitrary code >> boxes? > > It runs a separate process which is suid'd to a single purpose > restricted user that only has access to one directory and a > number of ulimits in force. So they could in theory write evil > things, but the operating system won't let it gain much ground. > > I'm currently setting up a separate virtual machine on a different > domain to handle that, so even if they broke it, the system > is completely expendable anyway. > > Problems with this would be if someone wanted to set up a network > spammer or a CPU eater. Perhaps a cron job that loops around > killing processes would help with that. > > > I need to think about it some more. Redirecting the user to > ideone might end up being the best solution (or dropping the > feature) but I want to shoot for something higher first. ideone also has an api you can use, instead of just redirecting
Re: d-programming-language.org
Vladimir Panteleev wrote: > On Sun, 30 Jan 2011 16:25:20 +0200, Lutger Blijdestijn > wrote: > >> It looks great. Is it possible to create a github repository specifically >> for this site? That would help a lot with contributing. > > I believe one already exists: > https://github.com/D-Programming-Language/d-programming-language.org > o wow, somehow I missed that. That's great!
Re: On 80 columns should (not) be enough for everyone
Andrej Mitrovic wrote: > The unittest topic is about to get derailed so I want to continue this > silly discussion here. > 80 colums is an artifact of the old age. Just like the preprocessor is an > artifact of the C language. And many other old things are artifacts. > There's no reason to keep these artifacts around anymore. Yes, but there has to be some limit, horizontal scrolling is much worse. Someone at my workplace likes to make 400+ columns lines of code for example, he likes it but it confuses the shit out of me. > A couple of things, Andrei: > 1. 80 colums is way too restrictive. 80 columns wasn't determined by some > scientific method to be a good size for code, it's a product of > limitations of the older generation hardware. Who will run a brand new > language like D in a freakin' Terminal? Terminals can host more than 80 columns these days. > If you want to see more files on the screen, get multiple screens. Is > Facebook running out of money, can't they afford a few monitors for the > C++ guru? Yes, I know you're not allowed to comment on that one. :) iirc Andrei commented facebook installed him a 30inch screen.
Re: The CAPI Manifesto
Walter Bright wrote: > On 10/17/2011 12:42 AM, Jacob Carlborg wrote: >> Already working on a package manager for D: >> >> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D >> https://github.com/jacob-carlborg/orbit/ > > > Is it possible (and worthwhile) to layer a package manager over a github > repository? Yes, pip (for python) can do it.
Re: Website message overhaul
Andrei Alexandrescu wrote: > On 11/13/11 8:37 PM, bearophile wrote: >> Andrei Alexandrescu: >> >>> Feedback is welcome. >> >> The overall look is nice, I like the foldable examples, but I think >> there's too much text for a home page. I think it's better to move lot of >> text in a "introduction" page. >> >> I suggest to avoid titles like "Multi-paradigm power", because they sound >> a bit too much too buzzwordy. > > What characteristic of D would you substitute as a major differentiating > feature? I like the term modeling power a lot, and would use this as the main point. It's straightforward, suggests a trade-off and has a pragmatic connotation.
Re: D projects list
Denis Shelomovskij wrote: > I think it will be great to have a single place for all D related > projects so a developer can easily find what is already done > (for an example of "I didn't now about you project" see, e.g. "Modern > COM Programming in D" thread), what is *planned* and what great projects > have already failed (and, maybe, reveal it). > > A draft variant of how I see such page is this with a few projects added > (note "Planned" tag (yes, empty for now)): > http://deoma-cmd.ru/d/d-projects-list/ > > Usage examples: > * lets find a D compiler with release or beta maturity: > http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release > * lets find not abandoned GUI library for D: > http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned > > > I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into > GitHub so developers can fork and edit it. > > I'd like to hear (but yes, I can only read, this is NG) any thoughts > about this idea. > It's a great idea. I used djangopackages.com a lot when I was doing a django project, something like this would be awesome for D. You might like to check it out, it has some nice features. So, apparently djangopackages.com is built with opencomparison, which is an open source project in itself: http://opencomparison.org/
Re: std.xml should just go
Andrej Mitrovic wrote: > On 2/4/11, spir wrote: >> >> About that, I would love a tutorial about eponymous templates starting >> with their /purpose/ (why does this feature even exist? what does it >> /mean/? what does it compare/oppose to? why is one supposed to need/enjoy >> it? how is it supposed to help & make code better mirror model?) Same for >> alias template params. Same for a rather long list of features, probably. >> > > But both of these are already explained in the manual: > http://www.digitalmars.com/d/2.0/template.html (search for Implicit > Template Properties) > http://www.digitalmars.com/d/2.0/template.html (search for Template > Alias Parameters) > > Granted, eponymous templates aren't explained in much detail on that page. > As for explaining how they work together, I did write that short > template tutorial > (http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/D2Templates), but > you've already seen that. :) > > However, I do not think we should write tutorials on single features > alone. I've read a bunch of books that explain the language in > feature-by-feature basis, but neglect to tie everything together. For > example, "Learning Python" is this 1200 page book about Python 3, > explaining the language feature by feature but never really discussing > the language as a whole. It's only good as a reference, which > ironically defeats the book's title. OTOH "Dive into Python 3" > gradually introduces you to more features of the language, but always > has code examples where you can see multiple features of the language > being used. (IIRC there were string processing examples which used > regex, multiple modules, and unittests all at once). > > Having a perspective on how all features tie together is crucial to > understanding the purpose of individual features themselves. In my > opinion! I agree, most of the 'dive into' books are excellent and complementary to reference materials. TDPL also has great little examples that illustrate the why of things, without ever becoming a mindless tutorial. It's hard to write such things however (witness the abundant amount of horrible technical writing), I truly admire those who can.
Re: Stupid little iota of an idea
foobar wrote: > Andrei Alexandrescu Wrote: > >> On 2/11/11 7:07 AM, foobar wrote: >> > Andrei Alexandrescu Wrote: >> > >> >> >> >> I don't find the name "iota" stupid. >> >> >> >> Andrei >> > >> > Of course _you_ don't. However practically all the users _do_ find it >> > poorly named, including other developers in the project.. This is the >> > umpteenth time this comes up in the NG and incidentally this is the >> > only reason I know what the function does. >> > >> > If the users think the name is stupid than it really is. That's how >> > usability works and the fact the you think otherwise or that it might >> > be more accurate mathematically is really not relevant. If you want >> > D/Phobos to be used by other people besides yourself you need to >> > cater for their requirements. >> >> Not all users dislike iota, and besides arguments ad populum are >> fallacious. Iota rocks. But have at it - vote away, and I'll be glad if >> a better name for iota comes about. >> >> Andrei > > Usability seems to be Achilles' heel of D and is a recurrent theme on the > NG. Usability cannot be mathematically deduced even though you seem to try > hard to do just that. This reminds me the story of a Google designer that > quit the company, being frustrated by the engineering mind-set of the > company. He gave many amusing examples of a complete lack of understanding > of design principals such as choosing the shade of blue by doing a > "scientific" comparison of a thousand different shades. > > could we for once put aside otherwise valid implementation concerns such > as efficiency and mathematical correctness and treat usability as valid > important concern? Could we for once accept that The users' opinion is not > "fallacious" and have a user oriented design is not a bad thing or are we > implementing for the sake of boosting ones own ego and nothing else? first rule of usability: don't listen to users http://www.useit.com/alertbox/20010805.html
Re: Stupid little iota of an idea
foobar wrote: > Lutger Blijdestijn Wrote: > >> >> first rule of usability: don't listen to users >> >> http://www.useit.com/alertbox/20010805.html >> > > I fail to see how that page ( which talks about website design ) applies > to what I've said. It says that you should look at what people _do_ > instead of what they _say_. How would you apply this to Phobos' naming > conventions? Quite literally. The thing is, most average joe users like me don't know what's good for them. They don't understand usability directly but rather 'know it when they see it.' Of course it is too time-consuming / has too little pay-off to conduct experiments for everything. > How about this: > Show a code sample using "iota" to users who never programmed in D and ask > them what that code does. Exactly, that's a very good idea.
Re: tooling quality and some random rant
Paulo Pinto wrote: > Hi, > > still you don't convice me. > > So what language features has C that are missing from D and prevent a > linker to be written in > D? > > The issue is not if I can beat Walter, the issue is that we have a > language which on its official > home page states lots of reasons for using it instead of C and C++, and > its creator decides > to use C when porting the linker to an high level language. > > So doesn't Walter belive in its own language? >From Walter himself: "Why use C instead of the D programming language? Certainly, D is usable for such low level coding and, when programming at this level, there isn't a practical difference between the two. The problem is that the system to build Optlink uses some old tools that only work with an old version of the object file format. The D compiler uses newer obj format features, the C compiler still uses the old ones. It was just easier to use the C compiler rather than modify the D one. Once the source is all in C, it will be trivial to shift it over to D and the modern tools." http://www.drdobbs.com/blog/archives/2009/11/assembler_to_c.html
Re: tooling quality and some random rant
gölgeliyele wrote: ... > > I think what we need here is numbers from a project that everyone has > access to. What is the largest D project right now? Can we get numbers on > that? How much time does it take to compile that project after a change > (assuming we are feeding all .d files at once)? Well you can take phobos, I believe Andrei used it once to compare against Go. With std.datetime it is now also much bigger :) Tango is another large project, I remember someone posted a compilation speed of a couple of seconds (Tango is huge, perhaps 300KLoC). But projects and settings may vary a lot. For sure, optlink is one hell of a speed monster and you might not get similar speeds with ld on a large project.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Walter Bright wrote: > Akakima wrote: >>> Changing the object module format is not sufficient. The symbolic debug >>> info would have to be changed (and Microsoft's is undocumented) and then >>> there's the dependency on Microsoft's C runtime library if linking with >>> VC generated object files. >> >> I found some doc there: >> >> http://pierrelib.pagesperso-orange.fr/exec_formats/index.html >> >> Microsoft Symbol and Type Information >> By TIS / Microsoft. Entry added 12/28/2004. >> Keywords: ms, symbol, type, info >> File: MS_Symbol_Type_v1.0.pdf >> « This document describes Microsoft Symbol and Type Information, a >> debugging information format fromMicrosoft Corporation for the 32-bit >> Windows environment. » > > > That document describes the Codeview symbol debug format, which Microsoft > abandoned 15 years ago in favor of a proprietary format. > > Dmd generates that older format :-) Are you going to do Elf? With optlink in D? (Does that even make sense?)
Re: tooling quality and some random rant
Walter Bright wrote: > Michel Fortin wrote: >> But note I was replying to your reply to Denis who asked specifically >> for demangled names for missing symbols. This by itself would be a >> useful improvement. > > I agree with that, but there's a caveat. I did such a thing years ago for > C++ and Optlink. Nobody cared, including the people who asked for that > feature. It's a bit demotivating to bother doing that again. Let me take the opportunity to say I care about an unrelated usability feature: the spelling suggestion. However small it's pretty nice so thanks for doing that.
Re: tooling quality and some random rant
retard wrote: > Mon, 14 Feb 2011 04:44:43 +0200, so wrote: > >>> Unfortunately DMC is always out of the question because the performance >>> is 10-20 (years) behind competition, fast compilation won't help it. >> >> Can you please give a few links on this? > > What kind of proof you need then? Just take some existing piece of code > with high performance requirements and compile it with dmc. You lose. > > http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html > http://permalink.gmane.org/gmane.comp.lang.c++.perfometer/37 > http://lists.boost.org/boost-testing/2005/06/1520.php > http://www.digitalmars.com/d/archives/c++/chat/66.html > http://www.drdobbs.com/cpp/184405450 > That is ridiculous, have you even bothered to read your own links? In some of them dmc wins, others the differences are minimal and for all of them dmc is king in compilation times.
Re: tooling quality and some random rant
retard wrote: > Mon, 14 Feb 2011 20:10:47 +0100, Lutger Blijdestijn wrote: > >> retard wrote: >> >>> Mon, 14 Feb 2011 04:44:43 +0200, so wrote: >>> >>>>> Unfortunately DMC is always out of the question because the >>>>> performance is 10-20 (years) behind competition, fast compilation >>>>> won't help it. >>>> >>>> Can you please give a few links on this? >>> >>> What kind of proof you need then? Just take some existing piece of code >>> with high performance requirements and compile it with dmc. You lose. >>> >>> http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html >>> http://permalink.gmane.org/gmane.comp.lang.c++.perfometer/37 >>> http://lists.boost.org/boost-testing/2005/06/1520.php >>> http://www.digitalmars.com/d/archives/c++/chat/66.html >>> http://www.drdobbs.com/cpp/184405450 >>> >>> >> That is ridiculous, have you even bothered to read your own links? In >> some of them dmc wins, others the differences are minimal and for all of >> them dmc is king in compilation times. > > DMC doesn't clearly win in any of the tests and these are merely some > naive examples I found by doing 5 minutes of googling. Seriously, take a > closer look - the gcc version is over 5 years old. Nobody even bothers > doing dmc benchmarks anymore, dmc is so out of the league. I repeat, this > was about performance of the generated binaries, not compile times. > > Like I said: take some existing piece of code with high performance > requirements and compile it with dmc. You lose. I honestly don't get what > I need to prove here. Since you have no clue, presumably you aren't even > using dmc and won't be considering it. You go on ranting about dmc as if it is dwarfed by other compilers (which it might very well be), then provide 'proof' that doesn't prove this at all and now I must be convinced that it's because the other compilers are so old? You lose. You don't have to prove anything, but when you do, don't do it with dubious and inconclusive benchmarks. That's all.
digitalmars-d@puremagic.com
Jonathan M Davis wrote: ... > > Personally, it wouldn't hurt my feelings any to have const ref take > temporaries. I do not understand why it's a problem. But Andrei insists > that it is. Presumably Walter agrees, but I don't know. They could very > well be right and that it's overall better _not_ to have const ref take > temporaries, but it _is_ annoying. Since I don't understand what the real > problem with not knowing whether const ref is actually referring to an > lvalue or rvalue is, I can't really judge whether they're right or wrong. > However, Andrei is certain that it's on of C++'s biggest mistakes. > > Regardless, the general push has been that structs be cheap to copy, and I > would argue that if you're structs _aren't_ relatively cheap to copy, you > should at least consider rethinking your design. Sometimes COW or ref > semantics will probably be required though. > > There may be a way to solve this problem reasonably and still have const > ref require lvalues, but for the moment, we have to deal with it. > > - Jonathan M Davis For reference, here is a link to the thread discussing it: http://www.mail- archive.com/digitalmars-d@puremagic.com/msg44075.html If I understood that discussion correctly, 'auto ref' is supposed to solve the rvalue references problem but are not completely implemented yet.
Re: Integer conversions too pedantic in 64-bit
Nick Sabalausky wrote: > "Nick Sabalausky" wrote in message > news:ijesem$brd$1...@digitalmars.com... >> "Steven Schveighoffer" wrote in message >> news:op.vqx78nkceav7ka@steve-laptop... >>> >>> size_t works, it has a precedent, it's already *there*, just use it, or >>> alias it if you don't like it. >>> >> >> One could make much the same argument about the whole of C++. It works, >> it has a precedent, it's already *there*, just use it. >> > > The whole reason I came to D was because, at the time, D was more > interested in fixing C++'s idiocy than just merely aping C++ as the theme > seems to be now. I don't see any difference, D has always kept a strong link to it's C++ heritage. It's just a matter of what you define as idiocy.
digitalmars-d@puremagic.com
Peter Alexander wrote: > On 15/02/11 10:47 PM, Lutger Blijdestijn wrote: >> For reference, here is a link to the thread discussing it: >> http://www.mail- archive.com/digitalmars-d@puremagic.com/msg44075.html >> >> If I understood that discussion correctly, 'auto ref' is supposed to >> solve the rvalue references problem but are not completely implemented >> yet. > > Thanks Lutger. > > From the thread, it seems like the correct annotation would be 'auto > ref const T', would it not? Yes, I think so.
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: > Okay, removing elements from a container sucks right now. You can do stuff > like removeAny (generally pretty useless IMHO) or removeFront just fine, > but removing an arbitrary range from a container just plain sucks. > > remove takes a range type which is the range type for the container that > it's on. That makes sense. It's obviously not going to be able to a take > an arbitrary range and remove that from itself. How would it know which > elements in that range corresponded to which elements in itself - > especially when it could be a range which skips elements or something > similar? So, _that_ part makes sense. I don't understand why not. Given, as you said, that a lot of functions return a new type it would make sense. My answer as to how would be something like: while range not empty container.remove range.front range.popFront Is there a problem with that? > But have you actually tried to get a range of the appropriate type to > remove from a container? It seems like almost ever function in std.range > and std.algorithm returns a new range type, making them completely useless > for processing a range to be removed from a container. > > I was looking to remove a single element for a RedBlackTree. The best > function that I could think to get the proper range was findSplit. The > middle portion of the return value would be the portion that I was looking > for. I'd take that and pass it to RedBlackTree's remove. Wrong. It uses > takeExactly in its implementation and the first two portions of the result > of findSplit aren't the right range type. > > So, what do I do? The _only_ thing that I can think of at the moment is to > use find to locate the beginning of the range that I want, take the length > of the range with walkLength and then use popBackN to pop of the elements > I don't want. e.g. The table in the docs mention stableRemoveAny(v) which says "Same as c.removeAny(v), but is guaranteed to not invalidate any iterators." Though c.removeAny(v) itself is not listed in the table nor implemented in RedBlackTree, isn't this the right function for the job? (I take it v stands for a value of the container, rather than a range). builtin aa's also implement this function.
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: > On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote: >> Jonathan M Davis wrote: >> > Okay, removing elements from a container sucks right now. You can do >> > stuff like removeAny (generally pretty useless IMHO) or removeFront >> > just fine, but removing an arbitrary range from a container just plain >> > sucks. >> > >> > remove takes a range type which is the range type for the container >> > that it's on. That makes sense. It's obviously not going to be able to >> > a take an arbitrary range and remove that from itself. How would it >> > know which elements in that range corresponded to which elements in >> > itself - especially when it could be a range which skips elements or >> > something similar? So, _that_ part makes sense. >> >> I don't understand why not. Given, as you said, that a lot of functions >> return a new type it would make sense. My answer as to how would be >> something like: >> >> while range not empty >> container.remove range.front >> range.popFront >> >> Is there a problem with that? > > It's horribly inefficient for one. Also, I'm not sure that the range is > valid any more after the remove, since it's front was removed. popFront > may not work correctly. It's a matter of range (in)validation right? I admit at this point I'm not sure how it is supposed to work. remove + popFront is a bad idea if the range is a view into the contained from where stuff is removed, but in c++ this works for map: some_map.erase(i++) where i is an iterator. So it depends on the type of container what is supported I think. But perhaps this falls under Walter's category of useless wankery, since it is easy to write yourself. >> > But have you actually tried to get a range of the appropriate type to >> > remove from a container? It seems like almost ever function in >> > std.range and std.algorithm returns a new range type, making them >> > completely useless for processing a range to be removed from a >> > container. >> > >> > I was looking to remove a single element for a RedBlackTree. The best >> > function that I could think to get the proper range was findSplit. The >> > middle portion of the return value would be the portion that I was >> > looking for. I'd take that and pass it to RedBlackTree's remove. Wrong. >> > It uses takeExactly in its implementation and the first two portions of >> > the result of findSplit aren't the right range type. >> > >> > So, what do I do? The _only_ thing that I can think of at the moment is >> > to use find to locate the beginning of the range that I want, take the >> > length of the range with walkLength and then use popBackN to pop of the >> > elements I don't want. e.g. >> >> The table in the docs mention stableRemoveAny(v) which says "Same as >> c.removeAny(v), but is guaranteed to not invalidate any iterators." >> >> Though c.removeAny(v) itself is not listed in the table nor implemented >> in RedBlackTree, isn't this the right function for the job? (I take it v >> stands for a value of the container, rather than a range). builtin aa's >> also implement this function. > > removeAny doesn't solve the problem. For starters, the table appears to be > wrong in that stableRemoveAny takes a value and removeAny doesn't. So, > either stableRemoveAny is supposed to not take a value or there's supposed > to be another version of removeAny which takes a value, and it's missing. > So, I don't know what exactly is intended with stableRemoveAny. > > Regardless of that, however, remove still needs to work. It's perfectly > valid to want to remove a range of elements rather than just one. > > - Jonathan M Davis (stable)removeAny does not solve the problem of removing ranges, but there must be *something* that solves the problem of removing one element. You found one way to do it for RedBlackTree (i gave up), but if I am not mistaken it doesn't have the right complexity and efficient removal is a key property of this container.
Re: Ranges and Algorithms -- Templates, Delegates, or Ranges?
Mafi wrote:
> Am 22.02.2011 11:29, schrieb %u:
>> Having learned functional programming in Scheme a couple months ago, I
>> tried my hand at using map(), reduce(), and filter() in D:
>>
>> int addend = 5;
>> map(delegate int(int x) { return x + addend; }, iota(1, 5));
>>
>> but it didn't work. It turned out that map() actually took the mapper as
>> its _template_ argument, not as a function argument. Not too much of a
>> problem, it probably seemed to be... except that it's a critical problem.
>> It makes map(), reduce(), filter(), etc. to become 10x less useful,
>> because there's no way to change their behavior at runtime, depending on
>> program's state.
>>
>
> I did never try and so I'm unsure but shouldn't you be able to give a
> delegate variable as template parameter.
> std.algorithms.map's parameter is an alias parameter so it should be
> able alias your variable and use it's runtime value.
> If it does not work this way it's a bug IMO.
>
> Mafi
yes it works: map!((int x) { return x + addend; })(iota(1, 5));
It's called local template instantiation iirc, and is restricted to global
templates (which map is).
Re: We need to rethink remove in std.container
Jonathan M Davis wrote: > On Tuesday 22 February 2011 03:52:34 Lutger Blijdestijn wrote: >> Jonathan M Davis wrote: >> > On Tuesday 22 February 2011 01:04:48 Lutger Blijdestijn wrote: >> >> Jonathan M Davis wrote: >> >> > Okay, removing elements from a container sucks right now. You can do >> >> > stuff like removeAny (generally pretty useless IMHO) or removeFront >> >> > just fine, but removing an arbitrary range from a container just >> >> > plain sucks. >> >> > >> >> > remove takes a range type which is the range type for the container >> >> > that it's on. That makes sense. It's obviously not going to be able >> >> > to a take an arbitrary range and remove that from itself. How would >> >> > it know which elements in that range corresponded to which elements >> >> > in itself - especially when it could be a range which skips elements >> >> > or something similar? So, _that_ part makes sense. >> >> >> >> I don't understand why not. Given, as you said, that a lot of >> >> functions return a new type it would make sense. My answer as to how >> >> would be something like: >> >> >> >> while range not empty >> >> >> >> container.remove range.front >> >> range.popFront >> >> >> >> Is there a problem with that? >> > >> > It's horribly inefficient for one. Also, I'm not sure that the range is >> > valid any more after the remove, since it's front was removed. popFront >> > may not work correctly. >> >> It's a matter of range (in)validation right? I admit at this point I'm >> not sure how it is supposed to work. remove + popFront is a bad idea if >> the range is a view into the contained from where stuff is removed, but >> in c++ this works for map: some_map.erase(i++) where i is an iterator. So >> it depends on the type of container what is supported I think. But >> perhaps this falls under Walter's category of useless wankery, since it >> is easy to write yourself. > > It depends on the implementation. It's possible that iterating an iterator > or popping the front of a range where that iterator no longer points to a > valid element actually works. It's also possible that, because it no > longer points to a valid element, it _doesn't_ work. It wouldn't surprise > me at all that some_map.erase(i++) isn't guaranteed to work in C++ at all > but that you've just gotten lucky with the STL implementation that you've > been using. I'd have to research it to be sure. But my guess would be that > you've been lucky. I'm fairly certain this is guaranteed, but specifically tied to std::map. The iterator returns the old value and is incremented before erasure, which doesn't invalidate iterators except the one that got removed. >> >> > But have you actually tried to get a range of the appropriate type >> >> > to remove from a container? It seems like almost ever function in >> >> > std.range and std.algorithm returns a new range type, making them >> >> > completely useless for processing a range to be removed from a >> >> > container. >> >> > >> >> > I was looking to remove a single element for a RedBlackTree. The >> >> > best function that I could think to get the proper range was >> >> > findSplit. The middle portion of the return value would be the >> >> > portion that I was looking for. I'd take that and pass it to >> >> > RedBlackTree's remove. Wrong. It uses takeExactly in its >> >> > implementation and the first two portions of the result of findSplit >> >> > aren't the right range type. >> >> > >> >> > So, what do I do? The _only_ thing that I can think of at the moment >> >> > is to use find to locate the beginning of the range that I want, >> >> > take the length of the range with walkLength and then use popBackN >> >> > to pop of the elements I don't want. e.g. >> >> >> >> The table in the docs mention stableRemoveAny(v) which says "Same as >> >> c.removeAny(v), but is guaranteed to not invalidate any iterators." >> >> >> >> Though c.removeAny(v) itself is not listed in the table nor >> >> implemented in RedBlackTree, isn't this the right function for the >> >> job? (I ta
Re: We need to rethink remove in std.container
Andrei Alexandrescu wrote: > On 2/22/11 3:04 AM, Lutger Blijdestijn wrote: >> The table in the docs mention stableRemoveAny(v) which says "Same as >> c.removeAny(v), but is guaranteed to not invalidate any iterators." >> >> Though c.removeAny(v) itself is not listed in the table nor implemented >> in RedBlackTree, isn't this the right function for the job? (I take it v >> stands for a value of the container, rather than a range). builtin aa's >> also implement this function. > > I don't think removeAny() works for his case because he wants to remove > a specific element from a container. removeAny() is useful when you want > to express "pick one element from that container in the easiest way > possible". > > Andrei I was looking for remove(ElementType value) but this function is not listed anywhere in std.container. The entry for stableRemoveAny(v) references removeAny(v) - note the parameter - so I thought that indicated the intent of a function removeAny(ElementType) but it doesn't exist in the table either. I assumed (mistakenly) that removeAny(v) would remove any value x where x == v from the container, where the choice of which would be left up to the container.
Re: We need to rethink remove in std.container
Steven Schveighoffer wrote: > On Mon, 21 Feb 2011 21:55:20 -0500, Jonathan M Davis > wrote: > >> Okay, removing elements from a container sucks right now. You can do >> stuff like >> removeAny (generally pretty useless IMHO) or removeFront just fine, but >> removing >> an arbitrary range from a container just plain sucks. >> >> remove takes a range type which is the range type for the container that >> it's >> on. That makes sense. It's obviously not going to be able to a take an >> arbitrary >> range and remove that from itself. How would it know which elements in >> that >> range corresponded to which elements in itself - especially when it >> could be a >> range which skips elements or something similar? So, _that_ part makes >> sense. >> >> But have you actually tried to get a range of the appropriate type to >> remove >> from a container? It seems like almost ever function in std.range and >> std.algorithm returns a new range type, making them completely useless >> for >> processing a range to be removed from a container. >> >> I was looking to remove a single element for a RedBlackTree. The best >> function >> that I could think to get the proper range was findSplit. The middle >> portion of >> the return value would be the portion that I was looking for. I'd take >> that and >> pass it to RedBlackTree's remove. Wrong. It uses takeExactly in its >> implementation and the first two portions of the result of findSplit >> aren't the >> right range type. > > RedBlackTree supports the equalRange function, which gives you a range of > elements equal to the value you give. > oo how I missed that. When you are working on RedBlackTree, would you please consider putting an example in the doc that uses it to this effect?
Re: Proposal for std.path replacement
Jonathan M Davis wrote: > On Sunday 06 March 2011 22:51:55 Christopher Nicholson-Sauls wrote: >> On 03/07/11 00:24, Jonathan M Davis wrote: >> > On Sunday 06 March 2011 22:09:22 Nick Sabalausky wrote: >> >> "Jonathan M Davis" wrote in message >> >> news:mailman.2280.1299459971.4748.digitalmar...@puremagic.com... >> >> >> >>> This reminds me. I should look into mime types one of these days to >> >>> see what the >> >>> appropriate way (if any) would be to put support for them in Phobos. >> >>> It would be >> >>> nice to not have to go by extension for the few programs that I have >> >>> which have >> >>> to worry about file type. >> >> >> >> I'm no unix expert, but my understanding is that mime types in the >> >> filesystem don't even exist at all, and that what it *really* does is >> >> use some complex black-box-ish algorithm that takes into account the >> >> first few bytes of the file, the extention, the exec flag, and >> >> god-knows-what-else to determine what type of file it is. Contrary to >> >> how people keep making it sound, mime type is *not* the determining >> >> factor (and cannot possibly be), but rather nothing more than the way >> >> the *result* of all that analysis is represented. >> > >> > I thought that the first few bytes of the file _were_ the mime type. >> > Certainly, from what I've seen, extension has _no_ effect on most >> > programs. Konqueror certainly acts like it does everything by mime type >> > - file associations are set that way. >> > >> > - Jonathan M Davis >> >> As someone who uses hex editors quite a bit (resorting these days to >> using Okteta mainly), I can tell you I have yet to see any file's mime >> embedded at the beginning, nor have I seen it in any headers/nodes when >> scanning raw. Doesn't mean it's impossible of course, and certain file >> systems certainly might do this[1] but I haven't seen it yet[2]. >> >> You are quite right, though, that extension doesn't matter at all, >> except in certain corner cases. Even then, they are reasonable and >> predictable things -- like SO's having the right extension. Considering >> the posix convention of "hiding" files/directories by starting the name >> with a dot, it'd be hard to rely on extensions in any naive way anyhow. >> ;) >> >> -- Chris N-S >> >> [1] I'd just about expect the filesystem of BeOS/Haiku to do so, or >> something similar to it at least. >> >> [2] Also not saying I wouldn't want to see it, necessarily. Done right, >> it'd be a damn nifty thing. > > I've never studied mime types, so I don't know much about them. It's just > that it was my understanding the the first few bytes in a file indicated > its mime type. If that isn't the case, I have no idea how you determine > the mime type of a file or what's involved in doing so. I _would_, > however, like to have a way to get a file's mime type in D, so one of > these days, I'll likely be looking into the matter. > > - Jonathan M Davis A good place to start is likely freedesktop.org, which maintains specifications, libraries and utilities aimed at enhancing interoperability between desktop systems. This is the page about mime types: http://freedesktop.org/wiki/Specifications/shared-mime-info-spec
Re: Curl support RFC
dsimcha wrote: > I don't know much about this kind of stuff except that I use it for very > simple > use cases occasionally. One thing I'll definitely give your design credit > for, > based on your examples, is making simple things simple. I don't know how > it scales to more complex use cases (not saying it doesn't, just that I'm > not > qualified to evaluate that), but I definitely would use this. Nice work. > > BTW, what is the license status of libcurl? According to Wikipedia it's > MIT > licensed. Where does that leave us with regard to the binary attribution > issue? > Walter contacted the author, it's not a problem: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=112832
Re: Curl support RFC
Jonas Drewsen wrote:
> On 11/03/11 22.21, Jesse Phillips wrote:
>> I'll make some comments on the API. Do we have to choose Http/Ftp...? The
>> URI already contains this, I could see being able to specifically request
>> one or the other for performance or so www.google.com works.
>
> That is a good question.
>
> The problem with creating a grand unified Curl class that does it all is
> that each protocol supports different things ie. http supports cookie
> handling and http redirection, ftp supports passive/active mode and dir
> listings and so on.
>
> I think it would confuse the user of the API if e.g. he were allowed to
> set cookies on his ftp request.
>
> The protocols supported (Http, Ftp,... classes) do have a base class
> Protocol that implements common things like timouts etc.
>
>
>> And what about properties? They tend to be very nice instead of set
>> methods. examples below.
>
> Actually I thought off this and went the usual C++ way of _not_ using
> public properties but use accessor methods. Is public properties
> accepted as "the D way" and if so what about the usual reasons about why
> you should use accessor methods (like encapsulation and tolerance to
> future changes to the API)?
>
> I do like the shorter onHeader/onContent much better though :)
>
> /Jonas
Properties *are* accessor methods, with some sugar. In fact you already have
used them, try it:
http.setReceiveHeaderCallback = (string key, string value) {
writeln(key ~ ":" ~ value);
};
Marking a function with @property just signals it's intended use, in which
case it's nicer to grop the get/set prefixes. Supposedly using parenthesis
with such declarations will be outlawed in the future, but I don't think
that's the case currently.
>> Jonas Drewsen Wrote:
>>
>>> //
>>> // Simple HTTP GET with sane defaults
>>> // provides the .content, .headers and .status
>>> //
>>> writeln( Http.get("http://www.google.com";).content );
>>>
>>> //
>>> // GET with custom data receiver delegates
>>> //
>>> Http http = new Http("http://www.google.dk";);
>>> http.setReceiveHeaderCallback( (string key, string value) {
>>> writeln(key ~ ":" ~ value);
>>> } );
>>> http.setReceiveCallback( (string data) { /* drop */ } );
>>> http.perform;
>>
>> http.onHeader = (string key, string value) {...};
>> http.onContent = (string data) { ... };
>> http.perform();
Re: a cabal for D ?
Jason E. Aten wrote:
> Please correct me if I'm wrong, but I observe that there doesn't appear
> to be a package management system / standard repository for D libraries.
> Or is there?
>
> I'm talking about something as easy to use as R's CRAN,
>> install.packages("rforest")
>
> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
> Hackage, etc.
>
> If there's not a commonly utilized one currently, perhaps we could
> "borrow" cabal, with a trivial port. cabal is Haskell's package manager.
>
> Not only does having a standard package install system facilitate
> adoption, it greatly facilitates code sharing and library maturation.
There used to be one called dsss (d shared software system). It was widely
used, I think some D1 libraries still use it but it hasn't been maintained
for years.
Re: a cabal for D ?
Russel Winder wrote:
> On Thu, 2011-03-17 at 20:44 +, Jason E. Aten wrote:
>> Please correct me if I'm wrong, but I observe that there doesn't appear
>> to be a package management system / standard repository for D libraries.
>> Or is there?
>>
>> I'm talking about something as easy to use as R's CRAN,
>> > install.packages("rforest")
>>
>> or cpan for perl, ctan for latex, dpgk/apt for debian, cabal for Haskell/
>> Hackage, etc.
>
> Note that every language-specific package manager conflicts directly
> with every operating system package manager. Thus RubyGems, CPAN,
> Cabal, Maven, Go, etc. conflicts with the package management of Debian,
> Fedora, SUSE, FreeBSD, MacPorts, etc. leading to pain. Pain leads to
> anger. Anger leads to hate. Hate leads to suffering.
>
>> If there's not a commonly utilized one currently, perhaps we could
>> "borrow" cabal, with a trivial port. cabal is Haskell's package manager.
>>
>> Not only does having a standard package install system facilitate
>> adoption, it greatly facilitates code sharing and library maturation.
>
> At the expense of easy system administration.
Not necessarily, fedora has rpm packages of gems for example.
> I guess the only up side of language specific package management is that
> it enables people whose operating systems are not package structured to
> do things sensibly. Alternatively Windows users could switch to a
> sensible operating system ;-)
>
It's also often easier to package libraries with system specifically
designed to do so for a particular language. That, combined with a common
repository, usually results in a much wider selection of apis than a native
distribution offers.
Re: GSoC-2011 project:: Containers
Ishan Thilina wrote: > @ steve & Johannes: Yeah, it works for me now :). I informed the site > owners about this and he has rectified it :) > > @Denis: > >>You are right, indeed. To say it shortly, ranges are D's version of >>iterators or > generators, especially powerful and general. With its own set of issues > (somewhat >>complicated, rather opaque types, various bugs remaining), but globally >>extremely > useful and usable. Most of Phobos2 (the std lib) builds on ranges; this > applies even >more to collections: if you wish to implement new > collections for D, it is certainly required that they hold range factories > for iteration. Sometimes, more than one (eg >tree traversal breadth-first > vs depth-first, leaves only...). >> >>About D collections: aside std.container in Phobos, Steven Schweighoffer >>has a > fairly advanced project called dcollections: > http://www.dsource.org/projects>/dcollections. As I understand it, it is a > bit of a concurrent for std.container, but there seems to be a possibility > for them to converge in the future. In >any case, >you should definitely > study it, if only to take inspiration and avoid double work. >> >>Use the D learn mailing list to ask people for help in understanding D's >>more > advanced features and issues. >> >>Denis >>-- > > Thank you very much for that helpful answer. > The biggest challenge now i have is to find good resources to learn about > ranges. Any suggestions ? Boostcon 2009 talk 'iterators must go' also recommended: http://blip.tv/file/2432106 The docs and sourcecode of std.range and std.algorithm is most relevant though, and this newsgroup or .learn for discussion and questions. > I'll look at the dcollections. I didn't know such a thing existed. It will > be a great help for me :).
Re: constexpr and CTFE
bearophile wrote: > This first question is mostly for D.learn, but below I show a partially > related link too, so I put both of them here. > > If you have library code, and the users of your library run one of your > functions at compile time, later if you change your function it may not > run at compile time any more. So isn't the quality of being able to run at > compile time part of the signature of the function? An attribute similar to pure that can be checked by the compiler might be useful. However, the signature affects the type right? I'm not sure that is the intent of ctfe. A simple ddoc annotation and a unittest is probably enough to both ensure and convey the ctfe-ability. > --- > > GCC 4.6 implements the C++0x constexpr. I've found a note about constexpr, > that touches the topic of logic const too, purity, memoization: > > http://stackoverflow.com/questions/4748083/when-should-you-use-constexpr- capability-in-c0x/4750253#4750253 > > Bye, > bearophile
Re: GSoC-2011 project:: Containers
Ishan Thilina wrote: > As to my understanding algorithms are seperated from the containers so > that the code is maintainable. But in std.container I can see that all the > algorithms are in the container method definitions. Why is this? Have I > got the things incorrectly? Slightly, D ranges use the same basic principles as the STL so any documentation on that can be used to understand the big picture. You'll see that no container implements all of std.algorithm, in fact containers have a very small interface. Normally algorithms work with different kinds of ranges and containers can provide one or more ranges, thus achieving very loose coupling and reuse. If a container provides a certain range then *all* algorithms which operate on that kind of range will work with the container. For example, any container that can be accessed with a random access range can be used by std.sort. However, containers usually have more to offer than what can be expressed by ranges. std.container documents a large set of methods that particular containers can implement as they see fit, as a convention. These methods are usually specific to a particular container implementation and necessary to use a container or take advantage of it's specific properties.
Re: Complete D grammar
Nick Sabalausky wrote: ... > > Yea, I remember that too. Someone took all the BNF sections from D's docs > on digitalmars.com, put them together, and filled in some > missing/erroneous parts. Maybe it's on wiki4d? Not sure if this is what you meant, but Jascha Wetzel had made a D grammar used by seatd / APaGeD: http://seatd.mainia.de/grammar.html
Re: Is the world coming to an end?
spir wrote: > On 04/03/2011 02:52 AM, bearophile wrote: >> Michel Fortin: >> >>> The new syntax is certainly usable, it's just inelegant and hackish. >>> Its your language, it's your choice, and I'll admit it won't affect me >>> much. >> >> My suggestions for Walter are: >> - To turn 01 .. 07 too into errors; >> - to deprecate the octal! Phobos template. >> - To introduce the 0o leading that works from 0o0 to the uint.max; >> - To change the new error message, so it suggests to use 0o. >> - To ask opinions to the community here next time before changing things >> in D2/D3 :-) > > I'm very surprised of this move -- aside the concrete details. What I > point out here is how far sentiments about what is "obvious" or "correct" > can be, for a given issue, that most of us considered wrong for the same > reason. > > When I introduced the topic of octal notation 0nnn beeing bad, I was 100% > sure that (if a move was ever made) either octals would be thrown out of D > all together for beeing nearly useless, or the syntax would be fixed -- > the "obvious" "correct" solution if octals remain. While I new about > octal!, this was so hackish and obviously wrong *for me*, that I did not > even imagine one second it could become the "official" solution. > I'm certainly not the only one. > Questions of detail, sure, but we all know what the details hide ;-) > > Denis I don't understand why it is hackish if it's a pure library approach. (it is right?) I find it actually rather nice that D can do this. This is not a syntax change, octals are out of the language and the library now has an octal template. Where's the problem?
Re: GUI library for D
Nick Sabalausky wrote: > "Andrej Mitrovic" wrote in message > news:mailman.3178.1301970383.4748.digitalmar...@puremagic.com... >> On 4/5/11, Nick Sabalausky wrote: >>> After all, I >>> *really* want to get around to making my own web browser (based off >>> either >>> Mozilla or Chromium) - I'm getting really fed up with the current state >>> of >>> available web browsers. Well, and the web as a whole (god I fucking hate >>> the >>> web), but one step at a time, I guess). >> >> I'll be the first to install it. >> >> Btw, there's a full web browser example in the QtD sources. But it has >> to be ported to D2. And then you have to deal with any eventual bugs >> along the way. :] > > Ha! I may not need to do much after all: I was just looking through > Wikipedia's giant list of browsers, found a few that looked potentially > promising, tried them all and...well, was mostly disappointed. But the > *last* one I had left to try I've been really impressed with so far: > > Arora (Qt/WebKit) > http://code.google.com/p/arora/ > > I've only tried it breifly, but the UI is *actually nice*! Only modern > browser out there with a UI that isn't absolutely horrid. I didn't even > see *one* instance of invisible-text on my light-on-dark system, which is > unbeleivavly rare among all software these days. > > And it has a lot of essential stuff built in, like ad blocking, > disableable JS, and a "ClickToFlash" which I haven't tried out yet. > There's still a few things it seems like it might be missing, like > equivalents to NoScript, BetterPrivacy and maybe DownloadHelper and > DownThemAll, but most of those are less important to me, and even as it is > right now it's a damn good start. Maybe I could add some of that remaining > stuff, or heck, maybe even port the whole thing to D ;) Even it it would involve looking at C++ code? Did you know Arora *is* the Qt webbrowser example that got out of control and became a real browser? (it uses webkit) iirc QtD has a sizeable chunk of that example already ported to D.
Re: Ceylon language
Nick Sabalausky wrote:
> "spir" wrote in message
> news:mailman.3497.1302788057.4748.digitalmar...@puremagic.com...
>> On 04/13/2011 02:34 PM, bearophile wrote:
>>
>>>
>>> If a value of type T can be null, it must be declared as type
>>> Optional, which may be abbreviated to T?
>>>
>>> String? name = process.args.first;
>>> if (exists name) {
>>> writeLine("Hello " name "!");
>>> }
>>> else {
>>> writeLine("Hello World!");
>>> }
>>>
>>> Use of an optional value must be guarded by the if (exists ... )
>>> construct. Therefore, NullPointerExceptions are impossible.
>>>
>>> This is exactly what I suggested for D in a enhancement request.
>>> It seems this kind of stuff is becoming a standard in new languages.
>>
>> +++
>>
>> But I guess optionality could, and should, extend to non-ref types; thus,
>> null is just a particular case of non-existence. And this would apply
>> especially on function parameters:
>>void f (int i?) {...}
>>
>
> Oh absolutely. Haxe has nullable-primatives which really comes in handly
> at times (it often prevents the need for a separate bool to keep track
> of). Only problem is that in Haxe, not only is nullable the default, but
> it doesn't even *have* any non-nullables at all, for any type.
>
>
>>
>> I don't get the diff between currying & partial app. And find this
>> feature much complication for close to uselessness.
>>
>
> I'm not certain either, but I *think* partial application is just like
> currying except there's some sort of arbitrary limitaion on what
> combination(s) of paramaters you can choose to specify or not specify. And
> that limitation is based purely on what order the function defines its
> parameters. So basically, my understanding is that partial application is
> an arbitrarily-gimped currying.
>
partial application is getting a new function out of an existing one where
one of the arguments is fixed / bound. More or less what std.functional
curry does, confusingly.
currying however doesn't involve specifying parameters at all, it means to
get a function with one parameter out of a function with more than one
parameter. This new function returns a function with one parameter, and so
on and so forth until there is nothing left to curry. An example is clearer:
int foo(int a, int b, int c) {
return a + b + c;
}
auto curriedFoo(int a) {
return (int b) {
return (int c) {
return foo(a, b, c);
};
};
}
assert( curriedFoo(1)(2)(3) == 6 );
Whereas partial application could be something like:
auto partialApply(F)(int x, F fun) {
return (ParameterTypeTuple!(F)[1..$] args) {
return fun(x, args);
};
}
assert( partialApply(1, &foo)(2,3) == 6);
Re: Context sensitivity
bearophile wrote:
> I was away.
>
> This is D code adapted from a blog post about C language:
> http://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-
c%E2%80%99s-grammar-revisited/
>
>
http://www.reddit.com/r/programming/comments/h23h3/the_context_sensitivity_of_cs_grammar_revisited/
>
>
> Three little D2 programs that compile with no errors. Similar code is
> allowed in C too:
>
> //
>
> alias int Foo;
> void foo() {
> Foo bar;
> float Foo;
> }
> void main() {}
>
> //
>
> alias int Foo;
> void foo() {
> Foo Foo;
> int bar = Foo + 2;
> assert (bar == 2);
> }
> void main() {}
>
> //
>
> alias char Foo;
> void foo() {
> int bar = Foo.sizeof, Foo, spam = Foo.sizeof;
> assert(bar == 1);
> assert(spam == 4);
> }
> void main() {}
>
> //
>
> Note: currently I have put nothing about this in Bugzilla.
>
> My question is: is it OK to keep allowing such kind of code in D2 too? Or
> is it better to statically forbid it?
>
> A disadvantage of statically disallowing it is the breakage of some valid
> C code. On the other hand I don't think I want to find code like that in D
> programs.
>
> Bye,
> bearophile
That's surprising, I didn't know it. I agree it should be statically
forbidden, which does not violate the principles wrt C compatibility because
it doesn't silently change semantics.
Tt also interacts with templates because they can pick up the redefined
name. Not sure if it's really a problem, it would be interesting to think of
a situation where this can occur in practice. Maybe with lots of templates,
ctfe and mixins it can became non-obvious? It sure as hell would be
confusing to run into such a bug.
Re: [OT] Re: There's new GIT instructions on Github now
Daniel Gibson wrote: > Am 21.05.2011 01:34, schrieb Andrej Mitrovic: >> What's there to configuring visual studio? You just open a solution >> file and hit compile. If there are any dependencies you usually >> download the libs and put them in some subfolder. >> > > I don't have much experience with visual studio, but I've read that > using a project from one version in another (newer) version may not > always be painless, e.g. > http://twitter.com/#!/ID_AA_Carmack/status/45616436995039232 Going from one version of a *solution* to the next usually just works. I expect tech5 to be somewhat more complex though. What usually doesn't work is going from one compiler version to the next, at least for C++. 'Managed' .Net is a different story. > And how well do projects from a professional version work in the free > (Visual Studio Express) version? That should work, the professional version is mostly about extra ide features, the basics and the toolchain is exactly the same. >> At least that's my experience. >> >> Now compare that to having to follow that gigantic tutorial for >> compiling GDC using msys. That's not really a fair comparison, GDC is very complex. There are also a lot of OSS projects which are much less arcane than what GNU usually does. Windows has it's share of complex build setups too, I believe the visual studio shell is such an example. I generally also find the boatloads of msbuild / nant xml scripts to be pretty incomprehensible when you need to work with them if something doesn't work.
Re: There's new GIT instructions on Github now
Andrej Mitrovic wrote: > Also I'd add the first time I tried using GIT GUI a few months ago it > froze and crashed when I tried to do a simple clone. I like git cola for gui. I has some nice features such as picking the lines from a file you want to stage for a commit. http://cola.tuxfamily.org/
Re: There's new GIT instructions on Github now
Andrej Mitrovic wrote: > What the duck has happened to this topic? > > Ok anyway, I found out a few things: > > I can change $HOME by adding this line into C:\Program > Files\Git\etc\profile file: > HOME="/d/dev/git/" > > right *above* this line: > HOME="$(cd "$HOME" ; pwd)" > > This was from someone's blogs post. And then if I want to start git > bash from a different initial directory I just change the git bash > shortcut "Start In" field to whatever directory. > > Anyways I've made a bunch of commits to my forked repo of dpl.org, and > now have to figure out how to make a pull request. I haven't made any > branches or anything because I'm way too new to this. > > I would also like to know how to uncommit a change which hasn't been > pushed yet. So if I locally do: > git add someFile.d > git commit -m "woops wrong comment" I recently starting using interactive rebasing which is a tremendous help for these kind of situations. This is usually what I do: start a branch for work on feature foo: git checkout -b foo * do a bunch of commits on foo * update master with newest changes: git checkout master git pull when foo is done, rebase it on top of master: git checkout foo git rebase -i master This will popup your editor and let you squash some commits together and edit the message. The text in your editor is fairly self-explanatory. It also 'replays' the commits on top of those from master you have pulled in *after* creating the foo branch. This helps with two things: you can resolve any conflicts inside the foo branch and prevents annoying merge commits. It will look in history like you have starting the foo branch from the latest commit from master. Sometimes this is not what you want, but most of the time it makes sense. >From here you can either merge it with master (it will fast-forward) and push to github, or push the foo branch to a foo branch on github. Doing interactive rebasing like this allows you to organize the series of commits and messages *after* you are done developing something, resulting in very nice pull requests. There is one thing you should never do: rebase a branch which you have already pushed to some place other people can see / use / depend on. Then you are taking away the history on which people have build. It is to be used strictly with private branches. I use this workflow to work concurrently on lot's of different topics, each in a seperate branch. Without rebasing the history will be cluttered with merge commits. I also don't have to worry anymore about other people when I commit, since making nice messages and such is postponed to the point of a rebase. This makes life much more pleasant.
