Re: D 2.062 release
18-Feb-2013 13:18, Dmitry Olshansky пишет: 18-Feb-2013 11:31, Walter Bright пишет: On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? The output of said D script for 2.062 is: $(DMDBUGSFIXED $(LI $(BUGZILLA 1369): Unable to find 'this' in __traits(getMember)) $(LI $(BUGZILLA 1730): Bogus error message calling a non-const struct method on a const struct reference) $(LI $(BUGZILLA 1841): Closure detection doesn't work when variable is used in a nested function) $(LI $(BUGZILLA 2452): Unimplemented method errors should show function overload) $(LI $(BUGZILLA 2630): ddoc should be able to document unittests) $(LI $(BUGZILLA 3321): debug flags) $(LI $(BUGZILLA 3404): JSON output should retain original alias names) $(LI $(BUGZILLA 3466): Wrong JSON output for templated classes, structs, and interfaces) $(LI $(BUGZILLA 4178): destructor missing in JSON output) $(LI $(BUGZILLA 4194): Attributes included in JSON output) $(LI $(BUGZILLA 4269): Regression(2.031): invalid type accepted if evaluated while errors are gagged) $(LI $(BUGZILLA 4477): JSON output for function definitions includes insufficient type information) $(LI $(BUGZILLA 4478): JSON output omits import statements) $(LI $(BUGZILLA 4540): Better error message for wrong switch type) $(LI $(BUGZILLA 5168): String enums don't work with -g compiler switch) $(LI $(BUGZILLA 5461): Invalid declaration for auto functions in .di files generated by DMD -H) $(LI $(BUGZILLA 5529): std.system.endian for pure functions?) $(LI $(BUGZILLA 5893): Allow simple aliases for operator overloading) $(LI $(BUGZILLA 5933): Cannot retrieve the return type of an auto-return member function) $(LI $(BUGZILLA 5978): ICE(mtype.c) when calling __traits(parent) on the child of an anonymous function.) $(LI $(BUGZILLA 6057): Problem with defining enum in function) $(LI $(BUGZILLA 6171): rdmd: cache dependency file to improve startup time [patch]) $(LI $(BUGZILLA 6319): debug's relaxed purity does not apply to nested scopes) $(LI $(BUGZILLA 6332): Auto-return function cannot be inferred as @safe) $(LI $(BUGZILLA 6408): string[].init gives a wrong type) $(LI $(BUGZILLA 6538): ICE(mangle.c) Invalid template constraints) $(LI $(BUGZILLA 6552): Wrong fallthrough warning for CaseRange) $(LI $(BUGZILLA 6652): foreach parameter with number range is always ref) $(LI $(BUGZILLA 6708): immutable ref implicit cast to const ref) $(LI $(BUGZILLA 6743): ICE(mars.c) attempting to compile an exe file) $(LI $(BUGZILLA 6833): Floating point literals lose fractional part in headers) $(LI $(BUGZILLA 6873): Multiple storage class is not allowed on template argument) $(LI $(BUGZILLA 6902): Different pure nothrow int() types) $(LI $(BUGZILLA 6905): ref acts as auto ref when return type is missing) $(LI $(BUGZILLA 6962): Wrong Code With Scope Exit and Array Parameter, only with -O) $(LI $(BUGZILLA 6963): pure/nothrow inference doesn't work for function pointers) $(LI $(BUGZILLA 7152): Can't assign null to default argument) $(LI $(BUGZILLA 7159): Forward reference when casting auto return method) $(LI $(BUGZILLA 7408): traits compiles fails for built-in properties of template instances) $(LI $(BUGZILLA 7420): Duplicate cannot be read at compile time error messages) $(LI $(BUGZILLA 7585): functions in templates inferred as delegate) $(LI $(BUGZILLA 7740): unicodeProperties cannot be read at compile time for ctRegex) $(LI $(BUGZILLA 7950): Type tuples are incorrectly flattened in base type list of interface) $(LI $(BUGZILLA 8053): Recursive alias this causes infinite loop) $(LI $(BUGZILLA 8105): Implement in ref) $(LI $(BUGZILLA 8128): unittest blocks should be allowed in interfaces) $(LI $(BUGZILLA 8152): Linking C library causes Seg-fault) $(LI $(BUGZILLA 8153): Warning about toHash signature is incorrect on x86_64) $(LI $(BUGZILLA 8504): Template attribute inferrence doesn't work) $(LI $(BUGZILLA 8583): [64 bit] AA ushort[dchar] byValue range is corrupted on x86_64) $(LI $(BUGZILLA 8631): illegal overrides accepted) $(LI $(BUGZILLA 8717): `private` and `protected` restrict member usage in same module) $(LI $(BUGZILLA 8742): Anonymous nested class derived from another nested class makes DMD crash) $(LI $(BUGZILLA 8763): struct
Re: Higgs, a JavaScript JIT done in D
05-Feb-2013 23:01, Andrej Mitrovic пишет:
On 2/5/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Care for a shotgun search/replace pull request?
Looking at the implementation:
string text(T...)(T args)
{
return textImpl!string(args);
}
private S textImpl(S, U...)(U args)
{
S result;
foreach (i, arg; args)
{
result ~= to!S(args[i]);
}
return result;
}
I can see 2 optimizations here:
1. Use a static if to replace the append operator with a simple return
when there's only one argument
2. Use Appender instead of a regular string for multiple arguments.
Unfortunately #2 won't fly because std.regex uses text and it expects
it to be safe, but Appender isn't safe.
Time to make Appender @trusted and linch the author if it's not that
safe inside? ;)
But seriously it would silently allow @system OutputRanges... @trusted
needs re-design.
--
Dmitry Olshansky
Re: DIP22 : Private symbol visibility
01-Feb-2013 13:34, Dicebot пишет: On Wednesday, 30 January 2013 at 11:39:26 UTC, Timon Gehr wrote: On 01/30/2013 10:42 AM, Dicebot wrote: ... That was the most uneasy part of proposal. I have been thinking for few hours about it, considering different options. In the end, I have decided that it is only confusing to one coming from C++ lax approach and for clean mind it should make perfect sense that private symbol is indistinguishable from non-existing one in regular user code - that is the point of encapsulation how I get it. ... As long as compile-time reflection cannot get hold of the error message, the more helpful diagnostic does not do any harm. (After all, the programmer might still be aware of the existence of the member, but missing that it is not accessible (yet) from the module he/she is currently working on.) I am arguing exactly that it is more helpful as it somewhat breaks encapsulation. I really believe it is good to not give out information that was no supposed to be shown. What do you think about changing both undefined and denied access messages to one symbol is undefined or inaccessible then? just tell what it is: not visible, period! And BTW good dip, the first part. The second about internal (C's static) is up for more work. -- Dmitry Olshansky
Re: Runtime code reloading in D, part 1
06-Jan-2013 14:37, Benjamin Thaut пишет: Am 05.01.2013 05:24, schrieb ixid: On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote: Am 31.12.2012 15:02, schrieb DypthroposTheImposter: Do you find that D without GC is more effective than C++? Seems like you would be stuck using structs which seems somewhat limiting, even compared to C++... UE4 has similar reloading capabilities(using DLLs), though they use C++ and rely more on the ability to serialize everything Why should I be stuck with structs? Its the exact same as in C++. I did build my own new and delete operators (as templates). It's not that hard and works pretty well, only the syntax is not ideal in some cases. I can use everything you can use with D+GC. Sometimes you have to be carefull with implict allocations (e.g. closures, array literals) but I have a leak detector that points me to these directly and usually its easy to free these manually. And I'm quite a bit more productive then in C++. Module constructors with a defined order instead of random static initalizers, code generation isnstead of huge amounts of boilerplate code and many other features are the cause of this. Kind Regards Benjamin Thaut Is D moving away from your sort of use? Games and bioinformatics would seem to be the areas the language should be trying to get people to start using it in. The features you're using seem very much like they should be a part and mode of using the language. I wouldn't say its moving away from it. Some recent changes to druntime have made it significantly less leaking. But on the other hand a API design like toString() which pretty much does leak in almost all cases don't exactly help a GC free D. In Summary it feels to me that GC free D is not important to the community or the active contributors. Regarding toString there is a better signature that avoids useless allocations: void toString(scope void delegate(const (char)[]) sink); It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap. I'd even say that string toString(); is an artifact of the past, instead to!string should be used (if allocating a string is fine). I also see D's biggest chances in becoming popular in the performance critical fields of programming. Which would be systems programming, Gaming and others. For programming fields in which a GC is applicable people tend to use languages like C# or Java, because they are truly safe (see the recent ref is unsafe discussion in the newsgroup), they have nice productivity features like runtime code changing through the VM and have a way better GC because the language was designed from the beginning to support a advanced GC. Kind Regards Benjamin Thaut -- Dmitry Olshansky
Re: Runtime code reloading in D, part 1
06-Jan-2013 23:55, Philippe Sigaud пишет: On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky dmitry.o...@gmail.com mailto:dmitry.o...@gmail.com wrote: Regarding toString there is a better signature that avoids useless allocations: void toString(scope void delegate(const (char)[]) sink); It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap. I'd even say that string toString(); is an artifact of the past, instead to!string should be used (if allocating a string is fine). I know you explained that already, but see, that again slipped my mind. This toString(sink) thingy seems cool, but is there a documentation on it somewhere? Without a related doc, I fear no one will know this exists. Guess I need to find the original on toString and bit-blit it over with this new sink thingy ;) -- Dmitry Olshansky
Re: Runtime code reloading in D, part 1
07-Jan-2013 00:02, Dmitry Olshansky пишет: 06-Jan-2013 23:55, Philippe Sigaud пишет: On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky dmitry.o...@gmail.com mailto:dmitry.o...@gmail.com wrote: Regarding toString there is a better signature that avoids useless allocations: void toString(scope void delegate(const (char)[]) sink); It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap. I'd even say that string toString(); is an artifact of the past, instead to!string should be used (if allocating a string is fine). I know you explained that already, but see, that again slipped my mind. This toString(sink) thingy seems cool, but is there a documentation on it somewhere? Without a related doc, I fear no one will know this exists. Guess I need to find the original on toString and bit-blit it over with this new sink thingy ;) There is a short note in object.d: ... string toString(); Convert Object to a human readable string. ... That is any class may override it. However the real relevant golden bit of information is buried after a row of formatValue templates (that hardly makes any sense to newcomers) at the bottom of std.format page: (http://dlang.org/phobos/std_format.html) Aggregates (struct, union, class, and interface) are basically formatted by calling toString. toString should have one of the following signatures: const void toString(scope void delegate(const(char)[]) sink, FormatSpec fmt); const void toString(scope void delegate(const(char)[]) sink, string fmt); const void toString(scope void delegate(const(char)[]) sink); const string toString(); So it's quite flexible. Even better then I've been advertising it. Note that classes are covered. I bet it can call virtual functions through base reference if base defines the new variation of toString. The problem is if it's going to be extended to wchar/dchar... At least wchar is useful on Windows. But the real fun is that I fail to find any real description of toString in the docs for d-p-l website! The only files in d-p-l site where it is found in are: - errors.dd: ... class Error has a pure virtual a function called toString() which produces a char[] with a human readable description of the error.) Nothing useful and it's out of date! It returns a string (immutable) these days. - lazy-evaluation.dd uses as an example of expensive computation and has the form of toString(i) where i is an int (wtf?!). Probably horribly out of date as it should use either format or to!string. - tempalte.dd uses std.string.toString as an example (same as in lazy?) and it's again an out of date piece of crap. And a couple more files call it here and there (e.g. windows.dd to display exception message box). -- Dmitry Olshansky
Re: D 1.076 and 2.061 release
04-Jan-2013 07:10, Walter Bright пишет: On 1/3/2013 11:36 AM, Jonathan M Davis wrote: Oh. Those are links. I was wondering when the data was actually going to be posted. When compared to the previous ones, it looks like there's only headers with no information. The idea is to add explanatory information to the bugzilla issue being pointed to. Making some effort to clarify the title of the bugzilla issue is also justified. This change to the changelog presentation does require that we up our game with bugzilla - accurate tags (you can see at the top what is being keyed on), accurate titles, and accurate information. With all due respect I just plain refused crawling through the list of links of bugzilla to understand the whole amount of changes and/or enhancements. New features need to be featured (!) at the top of changelog and represented in the on-line spec obviously. -- Dmitry Olshansky
Re: D 1.076 and 2.061 release
04-Jan-2013 10:44, Jonathan M Davis пишет: On Thursday, January 03, 2013 22:24:34 Walter Bright wrote: Please note that the documentation that was there before in the changelog, but with no corresponding bugzilla entry, has been cut pasted into the enhancement request bugzilla entry that I created for it. Nothing has been lost or removed. And where are items like $(LI std.range.hasSlicing has been made stricter in an effort to make it more reliable. opSlice for infinite ranges must now return the result of std.range.take, and any range with slicing which supports $(D $) must now support it with the same semantics as arrays (including supporting subtraction for finite ranges).) That's something that should be listed prominently, not buried in a long list of bugzilla entries. If you want to put that sort of thing in a separate release notes section, fine. But notes like this do _not_ belong in a list of bugzilla entries. They should be prominently displayed to users. In fact, this has pointed out quite a few New/Changed Features that had been omitted from the human curated list. I think that a complete list is better than the buggy, half-assed one we had before. I will certainly concur that a lot (most?) of the titles on the bugzilla enhancement requests kinda suck, but you or I or anyone else can fix them as necessary, and I did fix a few of them. I'm all for automating the bug fixes, and it makes perfect sense to handle many of the enhancement requests in the same way, but we should have a way to highlight major changes separately from the list of bugzilla entries (which have no indication of prominence or relative importance) as well as an area for giving specific notes to developers when needed (like major changes they should watch out for or impending changes that they should be aware of). If that's a separate release notes section rather than in the changelog itself, so be it, but we've now completely lost the section that we were using for that sort of thing. Instead, it's now simply a link to a bunch of bugzilla entries. - Jonathan M Davis P.S. Also, as a future improvement, we _really_ shouldn't be linking to bugzilla for our list. I've never seen a release notes document or changelog do that in my entire life. It would be _far_ more user friendly to list the changes like we did before with the bug number for each entry linking to the bug report (and it's what most projects to do from what I've seen). Automatically generating the list of bug fixes is great (and a definite step forward), but the current presentation leaves a lot to be desired. +1 Can't agree more. -- Dmitry Olshansky
Re: C++11 - using const and mutable for thread safety [Video]
03-Jan-2013 12:39, Michal Minich пишет: Newly discovered changes in C++11 on using const and mutable for thread safety http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank So now const is retrofitted as thread-safe. Again by convention. And that is true only because of a statement in std library expectations. This shift is great but just ... by convention. Looks like this channel got some updates on C++ and beyond 2012. I've found this one to be far more revealing: http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C -- Dmitry Olshansky
Re: D 1.076 and 2.061 release
1/3/2013 12:22 PM, Russel Winder пишет: On Wed, 2013-01-02 at 13:59 -0800, Walter Bright wrote: […] rhythmbox is a miserable program (at least on Ubuntu). It has a marvy feature where it randomly stops playing, and only a cold boot will bring it back. It also has random problems syncing with my music file database which is on a Windows shared folder. Getting it to recognize a just-added CD was an exercise in madness. I usually wound up deleting rhythmbox's settings file and starting over. There was a period prior to Canonical dropping Rhythmbox and then later reinstating it as the default player, that there were some problems with Rhythmbox failing to work. It was painful. for the last couple of years though, Rhythmbox has worked entirely fine for me on Debian Unstable with none of the problems seen during that period. So Rhythmbox on Debian works fine for me, far better than any other Linux offering. OS X offerings I have tried all, universally, fail to be at all appealing or even useful. I finally threw in the towel and don't use Ubuntu to play music anymore. I threw in the towel on Ubuntu when Unity came out as the default UI. Going OT but can't agree more :) -- Dmitry Olshansky
Re: Managing email [ was Re: D 1.076 and 2.061 release ]
04-Jan-2013 00:12, Russel Winder пишет: On Thu, 2013-01-03 at 21:08 +0100, Jacob Carlborg wrote: […] Next step: becoming your own ISP ? Define ISP ;-) Then go for autonomous system aka AS g -- Dmitry Olshansky
Re: D 1.076 and 2.061 release
1/2/2013 11:24 PM, Walter Bright пишет: On 1/2/2013 11:09 AM, Russel Winder wrote: On Wed, 2013-01-02 at 10:51 -0800, Walter Bright wrote: […] I've been avoiding upgrading Ubuntu, because the last time I did that the installer trashed everything. Lost a day on that one. Just because it happened once doesn't mean it will always happen. Until I abandoned all use of Ubuntu, I had never had an upgrade crash that didn't correct itself on appropriate rerun. You are the only person I know that had a total trashing due to installer fail. Reinstalling from scratch does not take a whole day. 2 hours maybe. It does when you don't remember what goes in the host file, what you had installed, redoing all the ssh keys, etc. It also deleted all my virtual boxes, I never did figure out how to get them working again. I simply gave up on virtual boxes as more trouble than they're worth. While I've found them to be quite easy to migrate and use. If virtual hard disk can be found/recovered you don't need the settings and other crap as these are re-created in matter of minutes. There are even pre-constructed images of various OS+software stack to be found on the web. P.S. I like calendar programs, but on Windows and Ubuntu, upgrading the OS inevitably deletes the calendar database. None of those frackin' calendar programs ever deign to tell me where they store their frackin' database, so I can back it up. I really, really don't understand mail and calendar programs that make it difficult to back up the data. I quit using Outlook Express because it stored the mail database in a hidden directory. WTF? Thunderbird is better, but not much. On latest Windows OS-es almost everything is in AppData\Roaming + AppData\Roaming in \Users directory. Just copying them over and reinstalling the apps seems to work (I only tried Thunderbird and couple of others though). -- Dmitry Olshansky
Re: Remus
10/30/2012 8:09 AM, Philippe Sigaud пишет: It would be really awesome if you could play around with making the AST available during compilation so we can alter it using ctfe. I have a compile-time parser and code generator project here: https://github.com/PhilippeSigaud/Pegged We are adding a D grammar in there and there is a compile-time D parser (some current transatlantic cable problem make github act erratically from Europe, but it's transitory). Pegged gives you a compile-time parse tree, which can then be manipulated with CTFE and transformed back into other code (the last part is not implemented for D specifically, but I have other tree-transformation function and they work alright at compile-time. Cool. Reminds myself that I need to find some more time to play with it (and the source). -- Dmitry Olshansky
Re: std.string.toUpper() for greek characters
On 03-Oct-12 18:11, Minas wrote:
On Wednesday, 3 October 2012 at 13:27:25 UTC, Paulo Pinto wrote:
On Wednesday, 3 October 2012 at 10:56:11 UTC, Minas wrote:
Currently, toUpper() (and probably toLower()) does not handle greek
characters correctly. I fixed toUpper() by making a another function
for greek characters
And a lot of others. And it is handwritten and thus unmaintainable.
// called if (c = 0x387 c = 0x3CE)
dchar toUpperGreek(dchar c)
{
if( c = 'α' c = 'ω' )
{
if( c == 'ς' )
c = 'Σ';
else
c -= 32;
}
else
{
dchar[dchar] map;
map['ά'] = 'Ά';
map['έ'] = 'Έ';
map['ή'] = 'Ή';
map['ί'] = 'Ί';
map['ϊ'] = 'Ϊ';
map['ΐ'] = 'Ϊ';
map['ό'] = 'Ό';
map['ύ'] = 'Ύ';
map['ϋ'] = 'Ϋ';
map['ΰ'] = 'Ϋ';
map['ώ'] = 'Ώ';
c = map[c];
}
return c;
}
Then, in toUpper()
{
if (c = 0x387 c = 0x3CE)
c = toUpperGreek()...
///
}
Do you think it should stay like that or I should copy-paste it in
the body of toUpper()?
I'm going to fix toLower() as well and make a pull request.
I'm *strongly* against bringing these temporary hacks into standard
library. The fact that toUpper/toLower are outdated is bad but fixing it
by piling hack after hack on this mess of if/else branches is not the
way out.
Also I hope you haven't lost a few hundreds over here:
http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3Agreek%3A%5D+%26+%5B%3ACasedLetter%3A%5Dg=
The way out is a proper implementation that is is a direct derivative of
the Unicode character database. And I've spent this summer on doing this
proper 'cure' for these kind of problems with Unicode support in D.
Admittedly, my reworked Unicode support probably won't hit the next
release(2.061). Needs to go through review etc. But I'm determined to
get it to 2.062.
I'd suggest to keep around you personal version for the moment and then
just switch to the new std one. However given our release schedule this
could be anywhere from 4 months to 1 year away :)
Regarding toLower() a problem I see is how to handle sigma (Σ),
because it has two possible lower case representations depending where
it occurs in a word. But of course toLower() is working on character
basis, so it cannot know what the receiver plans to do with the
character.
--
Paulo
Yeah, that's a problem indeed. I will make it become 'σ', and the
programmer can change the final'σ' to 'ς' himself.
I think this is one of a small number of special cases, see the full
list here:
ftp://ftp.unicode.org/Public/UNIDATA/SpecialCasing.txt
(handling these subtleties is commonly called 'tailoring' and currently
I believe is out reach for std library)
Currently mytoLower will do 'σ' as prescribed by simple case folding
rules. (i.e. the ones that can only map 1:1).
I have case-insensitive string comparison that does 1:n mappings as well
(and is going to replace current icmp) but it doesn't do tailoring.
One day we may add some language specific tailoring (via locales etc.)
but we'd better do it carefully.
--
Dmitry Olshansky
Re: std.string.toUpper() for greek characters
On 03-Oct-12 21:10, Ali Çehreli wrote:
On 10/03/2012 03:56 AM, Minas wrote:
Currently, toUpper() (and probably toLower()) does not handle greek
characters correctly. I fixed toUpper() by making a another function for
greek characters
// called if (c = 0x387 c = 0x3CE)
dchar toUpperGreek(dchar c)
{
if( c = 'α' c = 'ω' )
{
if( c == 'ς' )
c = 'Σ';
else
c -= 32;
}
else
{
dchar[dchar] map;
map['ά'] = 'Ά';
map['έ'] = 'Έ';
map['ή'] = 'Ή';
map['ί'] = 'Ί';
map['ϊ'] = 'Ϊ';
map['ΐ'] = 'Ϊ';
map['ό'] = 'Ό';
map['ύ'] = 'Ύ';
map['ϋ'] = 'Ϋ';
map['ΰ'] = 'Ϋ';
map['ώ'] = 'Ώ';
c = map[c];
}
return c;
}
Then, in toUpper()
{
if (c = 0x387 c = 0x3CE)
c = toUpperGreek()...
///
}
Do you think it should stay like that or I should copy-paste it in the
body of toUpper()?
I'm going to fix toLower() as well and make a pull request.
I don't want to detract from the usefulness of these functions but
toupper and tolower has been two of the strangests functions of the
computer history. It is amazing that they are still accepted, because
they are useful in very limited situations and those situations are
becoming rarer as more and more systems support Unicode.
Glad you showed up!
One and by far the most useful case is case-insensitive matching.
That being said this doesn't and shouldn't involve toLower/toUpper (and
on the whole string) anywhere. Not only it's multipass vs single pass
but it's also wrong. As a lot of other ASCII-minded carry-overs.
Other then this and being used as some intermediate sanitized form I
don't think it has much use.
Two quick examples:
1) How should this string be capitalized in a scientific article?
Anti-obesity effects of α-lipoic acid
There is a lot of lousy conversions. The basic toLower is defined in the
standard, try it here:
http://unicode.org/cldr/utility/transform.jsp?a=Upperb=Anti-obesity+effects+of+%CE%B1-lipoic+acid
I don't think the α in there should be upper-cased.
Depends on why you are doing it in the first place :) Capitalizing
scientific article strikes me as kind of strange as well.
2) How should this name be capitalized in a list of names?
Ali
Again what's the goal of capitalization here?
Simplifying matching afterwards? - Then it doesn't matter as long as
it's lousiness is acceptable (rarely so) and it stays within the system,
i.e. doesn't leak away.
It completely depends on the writing system of that string itself, not
even the current locale. (There are two uppercases that I know of, which
can be considered as correct: ALI and ALİ.)
One word: tailoring. Basically any software made in Turkey has to do ALİ :)
Only half-joking.
I agree that your toUpper() and toLower() will be useful in many
contexts but will necessarily do the wrong thing in others.
Ali
--
Dmitry Olshansky
Re: std.string.toUpper() for greek characters
On 03-Oct-12 20:13, David Nadlinger wrote: On Wednesday, 3 October 2012 at 10:56:11 UTC, Minas wrote: Do you think it should stay like that or I should copy-paste it in the body of toUpper()? I'm going to fix toLower() as well and make a pull request. In any case, you should coordinate with Dmitry Olshansky, since he is working on Unicode support in Phobos. Fixed ;) -- Dmitry Olshansky
Re: dlib - d utility library
On 28-Sep-12 21:47, Peter Alexander wrote:
On Friday, 28 September 2012 at 09:43:34 UTC, Timur Gafarov wrote:
dlib is a growing collection of native D language libraries serving as
a framework for various higher-level projects - such as game engines,
rendering pipelines and multimedia applications. It is written in D2
and has no external external dependencies aside D's standart library,
Phobos.
A note on your Vector implementation. Currently you use the vector
operators, e.g.
Vector!(T,size) opAddAssign (Vector!(T,size) v)
body
{
arrayof[] += v.arrayof[];
return this;
}
This is fine for large vectors, but (correct me if I'm wrong), your
vector class appears to be designed for small vectors. Those vector ops
currently call a asm optimised function that uses SIMD instructions in a
loop - it works well for larger vectors with hundreds of elements, but
for small vectors it's significantly faster to just use:
foreach (i; 0..size)
arrayof[i] += v.arrayof[i];
In this case simply unrolling it would be much better
(if size is fixed and is small e.g. 10).
foreach (i; TypeTuple!(1, 2, 3, 4 ... ))
//too bad we still don't have static Iota in Phobos
{
arrayof[i] += v.arrayof[i];
}
--
Dmitry Olshansky
Re: dlib - d utility library
On 29-Sep-12 20:39, Dmitry Olshansky wrote:
On 28-Sep-12 21:47, Peter Alexander wrote:
On Friday, 28 September 2012 at 09:43:34 UTC, Timur Gafarov wrote:
dlib is a growing collection of native D language libraries serving as
a framework for various higher-level projects - such as game engines,
rendering pipelines and multimedia applications. It is written in D2
and has no external external dependencies aside D's standart library,
Phobos.
A note on your Vector implementation. Currently you use the vector
operators, e.g.
Vector!(T,size) opAddAssign (Vector!(T,size) v)
body
{
arrayof[] += v.arrayof[];
return this;
}
This is fine for large vectors, but (correct me if I'm wrong), your
vector class appears to be designed for small vectors. Those vector ops
currently call a asm optimised function that uses SIMD instructions in a
loop - it works well for larger vectors with hundreds of elements, but
for small vectors it's significantly faster to just use:
foreach (i; 0..size)
arrayof[i] += v.arrayof[i];
In this case simply unrolling it would be much better
(if size is fixed and is small e.g. 10).
foreach (i; TypeTuple!(1, 2, 3, 4 ... ))
Sorry I've meant 0, 1, 2, 3 ...
//too bad we still don't have static Iota in Phobos
{
arrayof[i] += v.arrayof[i];
}
--
Dmitry Olshansky
Re: Slides from LASER 2012
On 21-Sep-12 03:27, Timon Gehr wrote:
On 09/21/2012 12:51 AM, bearophile wrote:
Timon Gehr:
chain has type Result. dynRange takes an arbitrary range and transforms
it into a range with the same value/vs reference behaviour whose static
type depends only on the element type.
I see. So that chain() is the normal chain of Phobos :-)
Exactly.
(But is DynRange a lazy stream/sequence? This is the most important
thing, because creating an eager linked list is kind of easy already,
and misses the main point of my request.)
Bye,
bearophile
Proof of concept:
import std.range, std.algorithm;
struct DynRange(T){
@property T front(){ return frontImpl(); }
@property bool empty(){ return emptyImpl(); }
void popFront(){
auto u = popFrontImpl();
frontImpl = u.frontImpl;
emptyImpl = u.emptyImpl;
popFrontImpl = u.popFrontImpl;
}
private:
T delegate() frontImpl;
bool delegate() emptyImpl;
DynRange!T delegate() popFrontImpl;
}
DynRange!(ElementType!R) dynRange(R)(R range)if(isInputRange!R){
DynRange!(ElementType!R) result;
result.frontImpl = ()=range.front;
result.emptyImpl = ()=range.empty;
result.popFrontImpl = (){
auto newRange = range;
newRange.popFront();
return dynRange(newRange);
};
return result;
}
void main(){
auto r = iota(0,10).dynRange;
auto t = [1,2,3,4,5].dynRange;
import std.stdio;
writeln(r,r,t,t);
}
To allow the definition of recursive lazy ranges, we'd also need
a facility to 'delay' computation. I'll post a proof of concept
tomorrow, by implementing eg. a lazy prime sieve.
I swear I've seen it somewhere in Phobos:
http://dlang.org/phobos/std_range.html#InputRangeObject
and friends. Maybe we ought to lay a better infrastructure for it.
--
Dmitry Olshansky
Re: Wrote a blog post about CTFE and D
On 30-Aug-12 13:41, Danny Arends wrote:
I wrote a blog post about the stuff I've been doing last weekend using
CTFE.
All comments are welcome, you can find the blog post at:
http://www.dannyarends.nl/index.cgi?viewDetailed=00029
Danny Arends
http://www.dannyarends.nl
Nice read.
A couple of nits:
Use T[2] for fixed arrays like Cord one. It also helps tremendously for
lookup speed of the final lookup table. Thus instead of array of arrays
you'd have an array of pairs i.e. 2 indirections --- 1 indirection and
cache friendly layout.
And an awful typo in degreeloop function I think:
pure int degreeloop(int deg){
while(deg 0 || deg = 360){
if(deg 0) deg += 360;
if(deg = 0) deg -= 360; //shouldn't it be = 360 ??
}
return deg;
}
--
Olshansky Dmitry
Re: Dmitry Olshansky Passes GSoC Final Evaluation
On 24-Aug-12 19:50, Andrei Alexandrescu wrote: Hi everybody, I'm happy to announce that Dmitry has passed GSoC's final evaluation. Going forward he and I will focus on integrating his work within Phobos. This should have technically occurred during the allocated time itself, but it's not like Dmitry will run away with the money :o). Thanks for your faith in me :o) Please join me in congratulating Dmitry. And Dmitry, let's get going with the integration. It would be great if we can get help from compiler hackers, as I've collected some gems on my first attempt to merge it that may very well stall the process: http://d.puremagic.com/issues/show_bug.cgi?id=8412 http://d.puremagic.com/issues/show_bug.cgi?id=8348 And this one makes all isXXX impure atm: http://d.puremagic.com/issues/show_bug.cgi?id=8446 -- Olshansky Dmitry
Re: dmd 1.075 and 2.060 release
On 03-Aug-12 20:57, Philippe Sigaud wrote: On Fri, Aug 3, 2012 at 10:25 AM, Mike James f...@bar.com wrote: Well, I installed by hand on windows, as I did for the previous releases and nothing links anymore. Then, at home, the same for linux. I did the exact moves/copies I did for 2.057, 2.058 and 2.059 and I never had this problem before. So now, all my DMD installs are broken :) What was changed in this release exactly? What Jonathan, what do you mean by old .di files? I never create any .di If you (like I did) just extract zip over your dmd installation this could lead to unpleasant surprise as some files should be now deleted yet new compiler will happily pick up old ones and get to a link error. Just obliterate your previous installation before setting up new one :) -- Dmitry Olshansky
Re: Pull freeze
On 29-Jul-12 15:11, Jacob Carlborg wrote: On 2012-07-29 08:08, Andrei Alexandrescu wrote: Due to the upcoming release, there will be no regular pull walk-through tomorrow. Thanks for the growing rate of contribution, and let's resume the ritual next Sunday. Andrei Again, we _need_ to start using branches. +1 -- Dmitry Olshansky
Re: DStep - Bindings Generator 0.0.1
On 09-Jul-12 02:13, Roman D. Boiko wrote: On Sunday, 8 July 2012 at 20:01:07 UTC, Jacob Carlborg wrote: On 2012-07-08 20:42, Walter Bright wrote: Since OC is a proper superset of C, this shouldn't be a problem. Just run the OC converter as your C compiler. That is not completely true if one is picky. The following code is legal C, but not legal Objective-C : int id; int nil; In Objective-C id is a type. I suppose this symptom will repeat in the future. I mean, for a particular file extension there may be several code importers. An (exotic?) example might be when some existing code uses one converter, but for some reason new code should use a different one. What about using the something like this: mixin convertImport!header.h; Ineffective even in distant future. Fixed functionality (=compiled, native, etc.) is faster and more practical. E.g. the above was possible already for something like a year (no less) the exact magic is: mixin(translate(import(file.ext)); But it never scaled to reasonably sized inputs/amounts of files like translating headers. with ability to specify a particular converter as second template parameter? However something like : import file.ext, FancyImporter; could work and call some 'FancyImporter' for compiler's tools directory to produce file.di I think extra syntax could be added easily WHEN the need arrives, so far 1:1 converters to extension feels fine. -- Dmitry Olshansky
Re: Visual D 0.3.33 uses a server for parsing and semantic analysis
On 20-Jun-12 02:41, Alex Rønne Petersen wrote: On 20-06-2012 00:20, Rainer Schuetze wrote: Hi, Visual D 0.3.33 has just been released. The biggest improvement is the move of the parser and the semantic analysis into a local COM server process, so that the IDE is no longer suffering from stalls caused by garbage collections on more than small amounts of memory. Very nice! Indeed, I've moved back to Visual once again :) Some other, not so spectacular changes include * debugger project settings now stored in solution options file, not in project file I love you!!! You have no idea how annoying that could get sometimes... * cv2pdb: new version 0.25 that supports VS2012 * cv2pdb: exposed command line options in the project options * intellisense tool tip now shows enumerator value * version highlighting now supports the version(V): syntax * tweaked vsi2d to also convert the Windows 8 SDK and VS2012 SDK * various improvements to parser and semantic analysis The full list of changes is at http://www.dsource.org/projects/visuald/wiki/VersionHistory Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-11 as well as the free Visual Studio Shells. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald The source code is now also available on github: https://github.com/rainers/visuald Rainer Does this work with the VS 2012 RC? Works here on VS 2012 RC win8. -- Dmitry Olshansky
Review of std.uuid is going on!
Cross-posting to cover a wider audience. The review for inclusion of a new module std.uuid into Phobos is in the process in the general .D newsgroup. Links: Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html Let's keep the discussion in the .D newsgroup: http://forum.dlang.org/thread/jr018l$afj$1...@digitalmars.com -- Dmitry Olshansky
Re: bootDoc - advanced DDoc framework using Twitter's Bootstrap
On 02.05.2012 22:26, Jakob Ovrum wrote: Note about noscript: JavaScript is used to get around the static nature of DDoc. The sidebar does not work without JavaScript, and neither do fully qualified anchor names. However, anchors with ambiguous names (such as those usable for symbols on dlang.org) work both with and without JavaScript, with the same limitations. Wooha! remove in std.algorithm finally points to _function_. Impressed :) (BTW It's still points to enum in dlang.org) Comments, issues, enhancement requests, questions or rants about JavaScript - all feedback is much appreciated! -- Dmitry Olshansky
Re: XSort - Sorting algorithms (including Timsort!)
On 12.04.2012 18:50, Xinok wrote:
On Thursday, 12 April 2012 at 05:25:52 UTC, Nathan M. Swan wrote:
On Thursday, 12 April 2012 at 03:04:49 UTC, Xinok wrote:
I just wanted to share this. I started a project a few weeks ago on
Github to implement several sorting algorithms in D. In total, there
are 8 modules at the moment, each implementing a sorting algorithm or
combination thereof.
https://github.com/Xinok/XSort
I just finished Timsort today. It's working, it's stable, but I need
to spend a little more time better optimizing it.
Cool! To make it a bit more generic, may I suggest making all the
inputs only have to be isInputRange, and have it converted to an array.
NMS
This incurs different behavior as random-access ranges would be sorted
in place and input ranges wouldn't be. I could add separate functions to
make this behavior explicit, but I see little point in doing so. It's
quite easy to convert an input range to an array yourself:
import std.array, std.range;
auto inputRangeToArray(R)(R range)
if(isInputRange!R !isInfinite!R)
{
auto app = Appender!(ElementType!(R)[])();
static if(hasLength!R) app.reserve(range.length);
app.put(range);
return app.data;
}
Indeed and there is a standard function array(...) that does this very
thing.
--
Dmitry Olshansky
Re: Russian TDPL is available for orders
On 03.04.2012 4:09, Denis Shelomovskij wrote: 02.04.2012 21:21, Oleg Kuporosov пишет: There is good news for Russian D Developers, translated Andrey's TDPL is available for pre-orders at some online stores http://www.books.ru/books/yazyk-programmirovaniya-d-827252/ Hope it will definetelly increase Russian speaking community, so far we don't have good localized resources on D. Andrey, is it first translation? Thanks, Oleg. I was afraid of it and it has finally happened. Sorry, but there is only *bad* news for us. I started reading translation of the foreword by Scott Meyers... The translation is not verbatim (strange, because it's not a poems translation), but readable... For some reason, a sentence Update: I'm not about to crack open a bottle of champagne but I want to point out that the translation (in the provided preview) was fixed in the mean time. You might want to review your comment on the book :) -- Dmitry Olshansky
Re: Russian TDPL is available for orders
On 05.04.2012 2:46, Igor Stepanov wrote: финиш Функциональные программисты убеждены, что такая модель вычислений поощряет неупорядоченное, параллельное выполнение, однако до недавнего времени эти возможности существовали скорее в виде потенциальной энергии, чем достигнутой цели. Так лучше? Да, неплохо. Меня все еще как-то тревожит в виде потенциальной энергии, чем достигнутой цели и мн. число в возможностях (все таки она одна - параллельное выполнение, остальное - эпитеты). Может быть лучше эта возможность являлась скорее потенциальной энергией, нежели достигнутой целью. -- Dmitry Olshansky
Re: Russian TDPL is available for orders
On 04.04.2012 19:35, Vladimir Panteleev wrote: On Tuesday, 3 April 2012 at 00:09:02 UTC, Denis Shelomovskij wrote: I was afraid of it and it has finally happened. Sorry, but there is only *bad* news for us. Hi, The text was revised by Igor Stepanov and myself. We are both D users, but inevitably a few errors will slip through the cracks. The translation should get better further on - the forewords haven't gotten as much attention as the main text. The book hasn't been printed yet. The errors brought up here shouldn't be in the print version. If you see any more goofs, please post here, it may not be too late to fix them. And sorry about the long delay - it's partially my fault :) The ones I recall in chapter 13 (and the only available for preview): с. 471 ...вплоть до массовой памяти лучше уж дисковой, звучит проще и сомнений меньше. на с.474 есть просто отличное предложение: По мнению программистов на функциональных языках, для такой модели вычислений органично неупорядоченное, параллельное исполнение, но до недавнего времени эти возможности существовали скорее в виде потенциальной энергии, чем как достигнутая цель. (прочел попытки с 3ей) ...для такой модели вычислений органично неупорядоченное, параллельное исполнение --- ...для такой модели вычислений естественно ... или в такую модель вычислений органично вписывается и откуда множественное число - эти ? Оригинал вроде: ...that potential was more of latent energy... С оригинала начало скорее - В среде функциональных программистов является признанным фактом, что такая модель вычислений -- Dmitry Olshansky
Re: Russian TDPL is available for orders
On 04.04.2012 22:56, Igor Stepanov wrote: The ones I recall in chapter 13 (and the only available for preview): с. 471 ...вплоть до массовой памяти лучше уж дисковой, звучит проще и сомнений меньше. Все таки имелась в виду не дисковая память, а ОЗУ. Можно ли назвать ее регулярной? Глядя на оригинал - mass storage это точно не RAM :) Думаю подразумевается в виду механизм виртуальной памяти, при котором страницы весьма легко могут оказаться на диске. BTW, we can ask the author of the book! Andrei, may I ask you what kind of memory you had in mind when refereed to mass storage in this statement of TDPL? The existence of a spectrum of memory architectures that navigate different trade-offs among density, price, and speed, has caused an increased sophistication of memory hierarchies; accessing one memory word has become a detective investigation that involves questioning several cache levels, starting with precious on-chip static RAM and going possibly all the way to mass storage. I believe it's harddisk(s) and it's ilk via virtual memory, while Igor (a corrector for Russian edition) thinks it's regular RAM. на с.474 есть просто отличное предложение: По мнению программистов на функциональных языках, для такой модели вычислений органично неупорядоченное, параллельное исполнение, но до недавнего времени эти возможности существовали скорее в виде потенциальной энергии, чем как достигнутая цель. (прочел попытки с 3ей) ...для такой модели вычислений органично неупорядоченное, параллельное исполнение --- ...для такой модели вычислений естественно ... или в такую модель вычислений органично вписывается и откуда множественное число - эти ? Оригинал вроде: ...that potential was more of latent energy... С оригинала начало скорее - В среде функциональных программистов является признанным фактом, что такая модель вычислений Да, фраза немного странная. Кст до лит. редактирования она звучала так: Как было замечено в кругах программистов на функциональных языках, пока неплохо такая модель вычислений от природы протежирует неупорядоченное, ай-ай-ай ) параллельное выполнение, однако до недавнего времени эти возможности существовали скорее в форме латентной энергии, чем достигнутой цели. финиш P.S. Ничего, что я по-русски? I've seen Spanish used, so it's should be more or less OK :) The topic provides nice excuse anyway. (Я тут и испанский видел, думаю более ли менее нормально. Тема в любом случае дает отличный повод для применения великого и могучего) -- Dmitry Olshansky
Re: Stewart's Utility Library 0.10 release - now exclusively for D2
On 01.04.2012 20:00, Stewart Gordon wrote: As some of you have heard already, I've taken the plunge and switched to D2. And, having seemingly discovered that most people have already left D1 behind, and that it's now harder than it was to make code compatible with both languages, I have decided to make my libraries D2-only. Other updates include the addition of DimensionedValue, my own stab at the old problem of primitive units checking, changing DateInterval and TimeInterval from kludgy typedefs to structs, and enforcing that set elements are immutable. http://pr.stewartsplace.org.uk/d/sutil/ Stewart. I gave this a brief look, the console stuff for windows caught my eye. No offense, but I totally expected console module to do coloring or some other cool terminal stuff. As is it looks like a workaround for stdio. BTW I think dgwrap can be safely yanked out, see http://dlang.org/phobos/std_functional.html#toDelegate -- Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 17.03.2012 10:59, Philippe Sigaud wrote: On Wed, Mar 14, 2012 at 10:48, Dmitry Olshanskydmitry.o...@gmail.com wrote: That's one of the caveats on PEG. That and greedy operators. 'a*a' never succeeds because 'a*' consumes all the available a's. Hey, wait, I thought there has to be backtrack here, i.e. when second 'a' finally fails? PEG only do local backtracking in 'or' choices, not in sequences. I think that's because the original author was dealing with packrat parsing and its O(input-size) guarantee. Ok, let's agree on fact that semantically a* is : As - a As / a and a*? is this: As - a / a As Now that's local ;) I remember trying compile-time backtracking in another similar library in D 1-2 years ago and getting lots of pb. I might add that in Pegged, but I don't know the consequences. How do you do that in std.regex? There are two fundamental ways to get around the problem, the easiest to implement is to use a stack to record a position in input + number of alternative/production (I call it a PC - program counter) every time there is a fork like that. Then when the current path ultimately fails pop stack, reset input and go over again until you either match or empty the stack. That's how to avoid dp recursion that happens here. The problematic thing now is combinatorial explosion of a* a* a* //simplified, but you get the idea The trick to avoid this sort of crap is to 1) agree that whatever matches first has higher priority (left-most match) that's a simple disambiguation rule. 2) record what positions + pc you place on stack e.g. use a set, or in fact, a bitmap to push every unique combination (pc,index) only once. Voila! Now you have a linear worst-case algorithm with (M*N) complexity where M is number of all possible PCs, and N is number of all possible indexes in input. Now if we put aside all crap talk about mathematical purity and monads, and you name it, a packrat is essentially this, a dynamic programming trick applied to recursive top-down parsing. The trick could be extended even more to avoid extra checks on input characters, but the essence is this memoization. (nice article btw, I learnt some about regexes) Thanks, I hope it makes them more popular. Might as well keep me busy fixing bugs :) -- Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 17.03.2012 18:11, Philippe Sigaud wrote: On Sat, Mar 17, 2012 at 10:09, Dmitry Olshanskydmitry.o...@gmail.com wrote: Ok, let's agree on fact that semantically a* is : As- a As / a and a*? is this: As- a / a As Now that's local ;) It's local, yes. But the pb is with Expr- A* B C D, when D fails. PEG sequences don't backtrack. I'd argue they do. As I see it as: Expr - As B C D / B C D As - A / A As (or use an epsilon production for As, is it allowed in pegged ?) I remember trying compile-time backtracking in another similar library in D 1-2 years ago and getting lots of pb. I might add that in Pegged, but I don't know the consequences. How do you do that in std.regex? There are two fundamental ways to get around the problem (snip) Thanks for the explanations. Does std.regex implement this? It does the second way that I haven't told about, and had hard time to implement in C-T :) And the simple version of what I presented (i.e. stack stuff) is used in CT-regex and as fallback in R-T. The problem with doing a bitmap memoization is that regex often used to _search_ things in large inputs. Some compromise and/or thresholds have to be estimated and found. Parsing on the contrary guaranties that the whole input is used or in error, hence bitmap is not wasted. Now if we put aside all crap talk about mathematical purity and monads, and you name it, a packrat is essentially this, a dynamic programming trick applied to recursive top-down parsing. The trick could be extended even more to avoid extra checks on input characters, but the essence is this memoization. I plan to store indices anyway. I might add this in the future. A read something on using PEGs to parse Java and C and there was no need to do a complete memoization: storing the last parse result as a temporary seemed to be enough. Well even straight no-memorization is somehow enough, it's just a way to ensure no extra work is done. C Java are not much of backtracky grammars. (nice article btw, I learnt some about regexes) Thanks, I hope it makes them more popular. Might as well keep me busy fixing bugs :) As people said on Reddit, you should make more whooping sounds about CT-regex. That was what wowed me and pushed me to tackle CT-parsing again. It's just I'm also well aware of how much luck it (still) takes to fly ;) The asserts that compare C-T vs R-T go off too often for my taste, other then this the memory usage during compile is too high. I recall once dmd had GC re-enabled for brief period, dmd used no more then ~64Mb doing real crazy ct-regex stuff. OK, back to C-T parsing, I have one crazy idea that I can't get away from - add operator precedence grammar into the mix. From what I observe it should integrate into PEG smoothly. Then it would make military-grade hybrid that uses operator precedence parsing of expressions and the like. Few more tricks and it may beat some existing parser generators. See this post, where I tried to describe that idea early on: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=159562 I might catch spare time to go about adding it myself, the only tricky thing is to embed plain semantic actions, as AST generation would be more or less the same. -- Dmitry Olshansky
Re: Visual D 0.3.31 features GDC support
On 14.03.2012 11:46, Rainer Schuetze wrote: Hi, the new version of Visual D includes support for building and debugging D projects with GDC, both Win32 and x64. Wow! Now that's a killer feature! Here is a list of major changes: 2012-03-14 Version 0.3.31 * added support for building with GDC * added platform support for x64 (use with GDC only) * includes new version 0.23 of cv2pdb that now also converts DWARF to pdb * added option to Intellisense page to configure trigger of code completion * new version of mago with bug fixes and support for associative arrays in expressions with basic key types * property: fixed editing multiple configurations at once * added Compile command to syntax check the current source file * parser now supports new lambda syntax (x) = x * fix resource include with spaces Very short instructions on how to get started with GDC can be found here: http://www.dsource.org/projects/visuald/wiki/Installation#UsingGDC Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-11 as well as the free Visual Studio Shells. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Rainer -- Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 14.03.2012 2:49, Philippe Sigaud wrote:
On Tue, Mar 13, 2012 at 17:17, Dmitry Olshanskydmitry.o...@gmail.com wrote:
PEG defines order of alternatives, that is pretty much like a top-down
recursive descent parser would parse it. Alternatives are tried from left to
right, if first one fails, it tries next and so on.
Yes.
In an example I give B is always picked first and so C is never ever looked
at.
That's one of the caveats on PEG. That and greedy operators.
'a*a' never succeeds because 'a*' consumes all the available a's.
Hey, wait, I thought there has to be backtrack here, i.e. when second
'a' finally fails?
Literal- (' .+ ') / ('' .+ '')
This needs escaping. Plain '.+' in pattern asks for trouble 99% of time.
This is an example were PEG would munch anything till the end, and
fail (since is not found in an empty string).
The standard PEG way to do that is
(!EndMarker .)+ EndMarker
It's a common enough pattern I tend to define a parameterized rule for that:
Until(Expr)- (!Expr .)* Expr
Gotta love parametrized rules! 15' to code, a neverending stream of joy.
Nice!
In fact grammars are usually devised the other way around, e.g.
Start:
Program - ...
Ehm... what the whole program is exactly ? Ok, let it be Declaration* for
now. What kind of declarations do we have? ... and so on. Latter grammars
get tweaked and extended numerous times.
At any rate production order has no effect on the grammar, it's still the
same. The only thing of importance is what non-terminal considered final (or
start if you are LL-centric).
Yes. The PEG standard seem to be that the first rule is the start
(root) rule. Pegged let you decide which rule you use for a start. The
rest is automatic.
I might change that.
--
Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 12.03.2012 16:43, bls wrote: On 03/10/2012 03:28 PM, Philippe Sigaud wrote: Hello, I created a new Github project, Pegged, a Parsing Expression Grammar (PEG) generator in D. https://github.com/PhilippeSigaud/Pegged docs: https://github.com/PhilippeSigaud/Pegged/wiki Just WOW! Nice to have on your WIKI would be a EBNF to PEG sheet. Wirth EBNF Pegged A = BC. A - B C A = B|C. A - C / C Maybe A - B / C. And even then it's not exactly equivalent if the grammar was ambiguous. Imagine: B - a, C - aa -- Dmitry Olshansky
Re: Pegged, From EBNF to PEG
On 12.03.2012 17:45, bls wrote:
On 03/13/2012 04:28 AM, Dmitry Olshansky wrote:
On 12.03.2012 16:43, bls wrote:
On 03/10/2012 03:28 PM, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
Just WOW!
Nice to have on your WIKI would be a EBNF to PEG sheet.
Wirth EBNF Pegged
A = BC. A - B C
A = B|C. A - C / C
Maybe A - B / C. And even then it's not exactly equivalent if the
grammar was ambiguous.
Imagine: B - a, C - aa
PEG is pretty new to me. Can you elaborate a bit ?
PEG defines order of alternatives, that is pretty much like a top-down
recursive descent parser would parse it. Alternatives are tried from
left to right, if first one fails, it tries next and so on.
In an example I give B is always picked first and so C is never ever
looked at.
Somewhat less artificial example:
Literal - IntL| FloatL
FloatL - [0-9]+(.[0-9]+)?
IntL - [0-9]+
If you change it to: Literal - FloatL| IntL then integer literals would
get parsed as floating point.
My mistake.. cleaned up stuff..
Pegged Wirth EBNF
Sequence
A - B C A = BC.
B or C
A - B / C A = B|C.
Zero or one B
A - B? A = [B].
Zero or more Bs
A - B* A = {B}.
One or more Bs
A - B+ Not available
PEG description of EBNF
EBNF - Procuction+
Production - Identifier '=' Expression '.'
Expression - Term ( '|' Term)*
Term - Factor Factor*
Factor - Identifier / Literal / '[' Expression ']' / '{' Expression '}'
/ '(' Expression ')'
lowerCase - [a-z]
upperCase - [A-Z]
Identifier - (lowerCase / upperCase) (lowerCase / upperCase)*
Why not:
Identifier - [a-zA-Z]+
Literal - (' .+ ') / ('' .+ '')
This needs escaping. Plain '.+' in pattern asks for trouble 99% of time.
Still not sure if this is correct. Especially :
Term - Factor Factor*
Another thing I never really understand is the production order, In
other words : Why not top down ..
Start :
lowerCase - [a-z]
upperCase - [A-Z]
Identifier - (lowerCase / upperCase) (lowerCase / upperCase)*
End :
EBNF - Procuction+
where End is Root..
In fact grammars are usually devised the other way around, e.g.
Start:
Program - ...
Ehm... what the whole program is exactly ? Ok, let it be Declaration*
for now. What kind of declarations do we have? ... and so on. Latter
grammars get tweaked and extended numerous times.
At any rate production order has no effect on the grammar, it's still
the same. The only thing of importance is what non-terminal considered
final (or start if you are LL-centric).
TIA, Bjoern
--
Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 09.03.2012 11:58, Jonathan M Davis wrote: On Friday, March 09, 2012 11:53:51 Dmitry Olshansky wrote: The goal is to make std.algorithm general when it comes to UTF-x ranges, VLE range seems a best suited abstraction level so far. Other things like base64 encoded stuff could be there, though it needs some thought. My point is that it doesn't make sense to try and design the lexer around an as yet undesigned and unused VLE range. Interface-wise, yes. Either the lexer should just move forward with how things are currently done and then be adjusted later to use VLE ranges once they've been sorted out, or it should be postponed until VLE ranges are sorted out. Or it could use whatever abstraction it needs internally, providing (for starters) (w|d)string interface. -- Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
sure that you understand the basics of Unicode fairly well - especially with how they pertain to char, wchar, and dchar - since that will affect your ability to correctly translate code to use ranges as well as properly optimize them. It would probably help if other D developers who are more familiar with ranges took a look at what you have and maybe even helped you start adjusting your code, but I don't know how many will both have the time and be interested. If I have time, I'll probably start poking at it, but I don't know that I'll have time any time soon, much as I'd like to. Regardless, you need to familiarize yourself with ranges if you want to get the lexer and parser ready for inclusion in Phobos. And you really should familiarize yourself with them anyway, since they're heavily used in D code in general. Not being able to use ranges in D would be like not being able to use iterators in C++. You can program in it, but you'd be fairly crippled - particularly when dealing with the standard library. - Jonathan M Davis -- Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 08.03.2012 22:46, Jonathan M Davis wrote:
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
Does isElementEncodingType aware of anything other then string/wstring?
else
{ ... }
I'm not sure that wrapping char and wchar arrays in structs that treat them as
ranges of char or wchar is a good idea. At minimum, I'm not aware of anything
in Phobos currently working that way (unless you did something like that in
std.regex?).
Well it's not that I'm insisting of _wrapping_ the arrays or some such
in general sense. And yes, I had some hard experience in std.regex with
UTF decoding and range design that doesn't exactly fits.
What I'm truly against is going overly generic and automatically
stomping on your performance. That being said the general design of
string ranges has unnessary pessimization already as it's popFront does
a UTF length lookup, identical operation is performed when decoding the
first codepoint (.front).
At any rate building lexer on top of ranges in current setting means
using abstraction that _hides_ decoding inside. That's a bad idea, it's
loosing a fight from the start. Why? Because in this case range can't
know if decoding is needed at this particular state of lexer or not, it
is generality that kills this by definition.
Yeah, in general auto-magically decoding ranges are OK, as long as the
stuff you do has cost much higher then decoding (~10 times would be
fine) or things that you strictly can't do otherwise. Lexer doesn't fall
into this criteria.
Everything either treats them as generic ranges of dchar or
special cases them. And when you want to be most efficient with string
processing, I would think that you'd want to treat them exactly as the arrays
of code units that they are rather than ranges - in which case treating them
as generic ranges of dchar in most places and then special casing certain
sections of code which can take advantage of the fact that they're arrays of
code units seems like the way to go.
Yeah, no arguing that. The thing is that lexer as a whole is precisely
one of these special cases. It's good as long as it's fast and that
requires more control then a generic input range of dchar.
Now, speaking outside of this specific problem.
Basically I would propose formalizing a kind of range that current
string/wstring is. And that is a VariableLengthEncoding range (VLE
range), a two in one - random access codeunit range and bidirectional
'codepoint' range. I've heard of attempts on this concept before, but
now with a use case at hand it could be become more important.
The problem is, I think, that current InputRange range is insufficent as
it requres to calculate length of first element twice: one time in front
and extra one in popFront.
--
Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 09.03.2012 1:12, Jonathan M Davis wrote:
On Friday, March 09, 2012 00:54:48 Dmitry Olshansky wrote:
On 08.03.2012 22:46, Jonathan M Davis wrote:
On Thursday, March 08, 2012 22:03:12 Dmitry Olshansky wrote:
On 08.03.2012 11:48, Jonathan M Davis wrote:
A range is not necessarily a dynamic array, though a dynamic array is a
range. The lexer is going to need to take a range of dchar (which may or
may not be an array), and it's probably going to need to return a range
of tokens. The parser would then take a range of tokens and then output
the AST in some form or other - it probably couldn't be range, but I'm
not sure. And while the lexer would need to operate on generic ranges of
dchar, it would probably have to be special-cased for strings in a
number
of places in order to make it faster (e.g. checking the first char in a
string rather than using front when it's known that the value being
checked against is an ASCII character and will therefore fit in a single
char - front has to decode the next character, which is less efficient).
Simply put, the decisison on decoding should belong to lexer. Thus
strings should be wrapped as input range of char, wchar dchar
respectively.
??? The normal way to handle this is to simply special-case certain
operations. e.g.
static if(Unqual!(isElementEncodingType!R) == char)
{ ... }
Does isElementEncodingType aware of anything other then string/wstring?
No. It uses isNarrowString. So, what you'd end up doing is having the lexer
accept a generic range of dchar and then have specializations where
appropriate for narrow strings. Nothing in Phobos' string handling really
supports the idea of dealing with generic char or wchar ranges. It all
processes ranges of dchar and specializes on narrow strings where appropriate.
The concept that *only* strings need special casing is broken. I recall
somebody already stomped on this: i.e. any range that returns char (a
wrapper range, over say memory-mapped file) passes by all the intricate
special casing that does decoding of std.algorithm and friends. So to
put it simply there is no way to tap into this *decoding by default*
infrastructure.
But is there really a use case for a generic range of char or wchar? I don't
know. In general, I really don't think that there is.
Memory mapped file wrapper is one, it's just from the top of my head.
There could be plenty of them, one needs just to look. 'I don't
know' is not a solid argument, sorry.
When dealing with ranges
of characters, they're essentially always either strings or strings which have
been wrapped in other ranges (generally by calling some other range-based
function such as take or filter). And those range-based functions pretty much
inevitably need to treat the strings as ranges of dchar to do what they do
(potentially with specific optimizations for strings). They aren't designed to
operate on ranges of char or wchar, and the only reason to make them do so
would be if there were a use case where you needed a range of char or wchar
which was not an array. But they're all either arrays or wrapped arrays. So,
no such use case currently exists with Phobos, and I really question the
usefulness of trying to optimize on a generic range of char or wchar -
especially when many of the optimizations for arrays involve random access
ranges, and if you have a random access range of char or wchar, I _really_
question that it would ever be anything other than an array.
And that is problem, if you fail to see why we need to stop pretending
that all char/wchar ranges are arrays, then I failed somewhere. In the
same vane one would argue that there is no other random access range but
array, yet there is. For instance if we explore containers there could
be Tries, Dequeues and whatnot of char/wchar with their respective ranges.
So, I'd advise against trying to operate on ranges of char or wchar and just
stick to operating on ranges of dchar with optimizations for narrow strings
where appropriate.
Probably the fact that in lexer it's not 'some place for optimizations,
it's the whole thing' was missed. That's why I'm looking for more or
less generic yet efficient way.
Now, speaking outside of this specific problem.
Basically I would propose formalizing a kind of range that current
string/wstring is. And that is a VariableLengthEncoding range (VLE
range), a two in one - random access codeunit range and bidirectional
'codepoint' range. I've heard of attempts on this concept before, but
now with a use case at hand it could be become more important.
There has been some talk of VLE ranges but really only with regards to the
fact that strings are a case of that. Nothing has been done to generalize it.
It may be something that should be looked into, but until we've formalized
that, I don't think that something like the lexer should be built around the
idea. It would be safer to stick with what we've been doing - operating on
ranges of dchar and special
Re: D to Javascript converter (a hacked up dmd)
On 29.02.2012 21:58, Adam D. Ruppe wrote: [...] 4) This is an insane idea, but one that came to mind. I'm testing this by piping the generated JS into dmdscript. dmd runs insanely fast when compiling this code. Phobos is kinda slow to compile, but you don't have to use it here. Write D1 style code and dmd is blink of an eye. dmdscript is reasonably fast too. As someone that spent quite some time porting and fixing dmdscript I humbly suggest using Google's standalone version of v8. I mean I've done benchmarking, and it was like 20-200x times slower depending on the things you do. For one hashtables are the bottleneck, I though of reworking them but lost interest along the way. The other problem is FP speed since JS uses double for eveerything. dmd used FP stack for double back then, probably now it uses SSE(?). Suppose you're writing an app and you want a scripting extension. Embed dmdscript, boom you can use javascript. (I really want to revive a dmdscript D2 port to make this even easier, but it isn't hard right now either.) You can try where I stopped it's still on D source, though I should probably upload that on github. If you are serious about dmd I would recommend it, as I've spent weeks to figure out proper try/catch/finally implementation and fix closures that were broken. Last thing I vaguely recall is building it with 2.055 or 2.056, and moving deprecated parts of phobos into it. What if you want to script in D? If you're GPL... embed dmd front end too. Make D output JS, which is interpreted by D, calling D apis Pretty insane, but you could script your app in D without doing shared libraries or anything like that! Indeed, but who knows ;) Compared to cases 1-3 though, this is silly. Just a thought that came to mind. The web app use case is strong though. I think I'll actually use this thing. -- Dmitry Olshansky
Re: D to Javascript converter (a hacked up dmd)
On 29.02.2012 23:40, Adam D. Ruppe wrote: On Wednesday, 29 February 2012 at 19:10:27 UTC, Dmitry Olshansky wrote: If you are serious about dmd I would recommend it, as I've spent weeks to figure out proper try/catch/finally implementation and fix closures that were broken. Indeed, I still have a copy of your zip from before. I tried to do it too, but I never got a lot of things working quite right; it'd sometimes crash, I replaced the AAs with a linear lookup since I didn't get that working right either. I ended up using hacked RandAA by David Simcha, it works quite well. It's a somewhat slow on reads comapred to d's native one, but sure it's more stable ;) Your version worked well, as I recall. But on dmdscript vs v8, v8 is faster, but I'm not too concerned about speed. A couple big advantages dmdscript has are: a) I expect it will be easier to integrate in D apps b) I already know its source code, so if I want to hack new things on to the language, it won't be a big todo. c) license is a little more permissive. The big one though is familiarity with the source. Agreed, it's very clean and lean for full interpreter (not to mention built-ins). -- Dmitry Olshansky
Re: dmd 2.057 release
On 14.12.2011 11:05, Walter Bright wrote:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
Indeed.
Yet I have to issue yet another warning about new std.regex compared
with old one:
import std.stdio;
import std.regex;
void main() {
string src = 4.5.1;
foreach (c; match(src, regex(r(\d+
writeln(c.hit);
}
previously this will find all matches, now it finds only first one. To
get all of matches use g option.
Seems like 100% compatibility was next to impossible.
--
Dmitry Olshansky
Re: std.regex wins with 11 votes
On 31.10.2011 7:21, Jesse Phillips wrote: I wish to congratulate Dmitry Olshansky for not only having his project selected for GSoC, but inclusion into Phobos. Absolutely no one had objection to this proposal and it received 11 yes votes, myself included. Dmitry, please merge in the latest master branch and submit a pull request so that we can have this great addition in the next release! Great, I'm on it. -- Dmitry Olshansky
Re: D programming language specification ebook
On 09.07.2011 8:59, Jordi Sayol wrote: Al 09/07/11 06:20, En/na Walter Bright ha escrit: Amazon has a kindle app for Windows which will display it, there's probably one for Linux too. 'fbreader' properly handle 'dlangspec.mobi' on Ubuntu 11.04 Best regards, You can also try this file conversion web service: http://www.convertfiles.com/ saved me a whole lot of trouble in the past. -- Dmitry Olshansky
Re: Programming Windows D Examples are now Online!
On 22.06.2011 23:01, Andrej Mitrovic wrote: I just ran into some odd stdout corruption issue while doing parallel builds, take a look: http://i.imgur.com/pgC4o.png I've tried building again and it was gone, it looks like an appearance of a heisenbug. There might be some bug lurking somewhere in std.parallelism, but it's hard to say when I can't recreate it. I'd say that is to be expected, e.g. when multiple processes (in this case two resource compilers) output to the same stream (console) and has nothing to do with std.parallelism. One cure for that is to have them output to a unique temporary files or pipes. The only thing that's strange is that I'd expect it to happen in blocks as there should be buffering, but maybe they doesn't use it at all. -- Dmitry Olshansky
Re: (Interesting) Microsoft Demos C++ AMP Heterogeneous Computing at AMD's Fusion Developer Summit
On 16.06.2011 21:42, Zz wrote: Interesting article and video. Microsoft Demos C++ AMP Heterogeneous Computing at AMD's Fusion Developer Summit. http://hothardware.com/News/Microsoft-Demos-C-AMP-Heterogeneous-Computing-at-AFDS/ link to the full video: http://channel9.msdn.com/Events/AMD-Fusion-Developer-Summit/AMD-Fusion-Developer-Summit-11/KEYNOTE BTW amazing stuff, and it's definitely good that we now have std.parallelism. Admittedly it doesn't deal with specialized things like computing on GPUs. -- Dmitry Olshansky
Re: Visual D 0.3.24 released
On 08.05.2011 13:31, Rainer Schuetze wrote: Hi, as the newest version of Visual D includes some major improvements, I'd like to announce its release here. Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005, 2008 and 2010 as well as the free Visual Studio Shells. Added features worth noting include * support for Object Browser and Class View * runs a parser in the background to underline syntax errors (no semantic analysis) * new version of the mago debugger that fixes some issues with exceptions and improves the call stack display Highlights in previous versions not announced here: * support for Code Definition Window * search and replace based on the D tokenizer, ignoring white spaces and comments and supporting brace matching * new compilation modes: compile and link seperately, compile only Visual D comes with an easy installer and can be downloaded here: http://www.dsource.org/projects/visuald Best, Rainer Awesome tool! Previously I used Code::Blocks on Windows, now I think I'm addicted to VisualD ;) -- Dmitry Olshansky
Re: Alternative linker win32/64
On 24.02.2011 21:41, Walter Bright wrote: Sebastian Schuberth wrote: On 18.02.2011 11:00, Dmitry Olshansky wrote: The nice thing is reduction in half of the resulting binary size. That's indeed nice! The unnecessarily huge size of binaries created with D / Optlink was in fact something hindering me to use D at all! I'm sure that linker is doing it by writing compressed exe's. This means that it has the same memory footprint, and it loads slower because it must be decompressed. Also, if you store it in a zip file, the zip file won't be any smaller because recompressing compressed data doesn't make it smaller. Tried that, it's still compresses to roughly 50% of it's size. Well, I no expert but a glance at disassembly shows that at least strings / imports are intact. For what it's worth the IDA control flow analysis shows a bulk of unreferenced procedures in optlink's one. So maybe the case is that they also included a decent stripper. -- Dmitry Olshansky
Re: dmd 1.067 and 2.052 release
On 21.02.2011 11:53, Stephan wrote: On 18.02.2011 11:18, Walter Bright wrote: Now with 64 bit Linux support! (Though expect problems with it, it's brand new.) http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.067.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.052.zip Nice release in theorie but since i did not get the time to test the beta it seems some regressions made it into the release that rendered my codebase unbuildable... The problem is that i cannot reduce it properly. (win32, dmd 2.052) 1) Without changing anything suddenly i get linker errors. I am building an executable linking in a static lib that contains some methods using std.random.uniform. When i now try to build the executable the linker complains about std.random.uniform not being found. What the heck ? The whole rest of phobos is there and this is missing ?? Having hit similar things earlier, I'll tell you my recipe. I usually rebuild *everything* step by step starting with and including all 3rd party D libraries with new dmd. And making sure nothing from old version sliped on the path. Yes, that's tiresome, especially when you haven't touch those libraries for quite a long time (assuming they are sort of stable). 2) This one is really weird. After removing all the std.random.uniform crap from above it compiles and links but crashes right in the beginning befor even entering my main method. This just happens in debug builds. Funny thing is that this is not due to some unittest of mine. And correct me if i am wrong but phobos is shipped without unittests either, right ? Any help is welcome. Stephan -- Dmitry Olshansky
Alternative linker win32/64
The fresh beta of universal linker UniLink has arrived, with exciting new features. Quoting the changelog: + Preliminary support of Digital Mars D language compiler. + The debug info processing in old CV format added (dmc, dmd, watcom, old ml). And it works! At least for the first part. I actually linked my port of DMDscript and run it through some stress tests, no problems so far. The nice thing is reduction in half of the resulting binary size. As to debug info I think it may need another round of polishing... but the devs are willing to support it ;) C:\ulinkulink -v test.obj UniLink v1.07 [beta] (build 3.01) Error: Invalid debug information in 'test.obj' Nevertheless the grim rule of Optlink in windows lands is at end :) Some tips on how to get started. Grab the latest beta here (for now it's ulnb0301.zip): ftp://ftp.styx.cabel.net/pub/UniLink/ Installation is extract + add to PATH Also to save you a bit of investigation, the relevant ulink.cfg config for dmd is along the lines: -zkernel32;advapi32;user32;wsock32;shell32;snn -LC:\dmd2\windows\lib -Go -- Dmitry Olshansky
Re: DMDScript now on D2
On 17.12.2010 4:01, Brian Hay wrote: On 17/12/2010 2:14 AM, Dmitry Olshansky wrote: I decided I'll take a risk to announce my work on porting DMDScript, that is ECMA-262 script engine. Nice! As few seem to read the DMDScript newsgroup, here's my last post as it seems relevant to this topic. === There's a JavaScript arms race going on (as I'm sure many of you are aware). The competing JS engines of the major browsers are leap-frogging each other in performance every few months it seems. http://www.conceivablytech.com/4472/products/chrome-10-posts-huge-performance-jump/ It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns. Possible? Indeed, that would be desirable. I dreamed to get back performance tuning from the day it started working, but It's better to fix some bugs and clean up the source first. -- Dmitry Olshansky
Re: DMDScript now on D2
On 17.12.2010 5:34, Adam D. Ruppe wrote: Brian Hay wrote: It would be so cool (and a huge showcase for the D Programming Language) if DMDScript was in that performance race and beating the big guns. It kicked the living crap out of the competition up to not too long ago! It beat out Firefox 2 by well about 50x when I checked it, and IE7 by IIRC 20x. What's really impressive is dmdscript was several years old at that point - as in it only got a few minor bugfixes in those years, and the main design was even older. It took the big guys some five years or more to catch up to lone Walter. It was about 1/2 the speed of Firefox 3 when I checked it last. That gap has probably widened quite a bit in the last year. A quick check using the sieve.ds shows Firefox 3 is currently about 16x faster than dmdscript. Yes, it's about 20x times slower on my machine.. It must be the properties of RandAA, namely relatively slow lookup time. Profiler shows 90% time is spent in hashmap lookup function. I had to replace built-in AA at certain point because of spurious segfaults that fixed, but must have degraded speed. The gap is definitely opening up in the other direction now, but still, it took them long enough! Could dmdscript take the lead back? Probably, though I suspect it'd be quite a lot of work. But I don't really know. dmdscript is a kind of compiler, so maybe not. I'm just not qualified. -- Dmitry Olshansky
DMDScript now on D2
Following that quite emotional discussion of JavaScript on digitalmars.D I decided I'll take a risk to announce my work on porting DMDScript, that is ECMA-262 script engine. In the end it turned out to more like a quite successful fork given the amount of changes. The goal was not only to just make it compile with D2 and work (that would be of limited value) but also slowly convert it to newer D2 idioms/libraries/etc, I essence simplifying user side code for writing extensions. For instance, I even managed to use immutable strings throughout, at the expense of a couple of casts at critical spots. I'm considering current state of release as stable beta, since I had to disable some of original performance tricks in order to debug some issues properly. They eventually would be re-enabled of course. Latest tar with source code + samples can be found here: http://dsource.org/projects/dmdscript-2/browser/downloads Things of possible interest: -- Builds fully works with latest dmd , tested on Windows and Linux -- Greatly increased standard conformance -- Still runs quite fast -- Some huge bugs fixed, that were present in DMDScript 1.16 . (for instance 'in' _expression_ not implemented) -- Includes (highly experimental) module for extending script engine with native D functions/types in a couple of LOCs -- Contains few basic examples to get started P.S. I'm still reluctant to give it a version number, should it be DMDScript2 0.1 ? -- Dmitry Olshansky
Re: DMDScript now on D2
On 16.12.2010 19:43, Adam Ruppe wrote: Dmitry Olshansky wrote: The goal was not only to just make it compile with D2 and work (that would be of limited value) I tried this too about a year ago...: http://arsdnet.net/dcode/dmdscript_d2.zip Yes, that's the only previous effort I've found, and it was after my port almost started working. ...but overall, from a brief glance, your port is *much* better than mine. I used a lot more casts and idups, and thus introduced new bugs and hurt the performance. I got it working, but not working well. Nice work! Thanks, yet I plan a lot of refactoring, one I dream of is eventually replacing struct Value with Algebraic from Phobos. And yes, that exception propagation mechanism, I almost switched to throwing instead of returning exceptions from functions. But there still might be a few ideas or bits of code we can share from the easy expansion stuff. I called mine pretty.d and test.d in that zip. One of the things I tried to do was make a ScriptObject class in D, which you could expand and call with opIndex and opDispatch. I was only partially successful, but maybe we can better with a newer compiler. Here's a copy/paste of part of my test.d showing the idea I was chasing: === auto g = se.globalObject; // se is a ScriptEngine /* You can work with the script environment as an associative array... */ g[hello] = Hello, world!; g[lol] = new ScriptObject; // ScriptObject is just a generic object. You can specialize it in the constructor. //g[lol][fun] =fun; // Can even assign native top-level functions this way! FIXME: broken due to ICE /* Or, you can do it with opDispatch, though this is limited to just assigning existing ScriptObjects... */ auto so2 = new ScriptObject; se.globalObject.lol.hate = so2; /* You can also add functions to specific ScriptObjects with the addFunction template */ se.addFunction!(raise, fun)(so2); === Yes, that's awesome. I guess I should get a closer look at that pretty.d! And all that stuff would of course be available to the script via the global object. In pretty.d, you can see some attempt to unify D and dmdscript exceptions too, but I don't recall how well that went, but I'm pretty sure it worked at least one way. One little thing we both did is one line expansion. One thing I'd add to your code is making the name of the script function default to being the same name as the D function. It's a minor addition, but I think it looks nice. Yes, it's planned, and indeed improves user experience. I just was stuck with the issue of extending of variadic functions/templated functions consider, for example, std.stdio.writeln. That must have distracted me from this issue. Generally though, your port is excellent, thanks for doing it! -- Dmitry Olshansky
Re: Phobos unit testing uncovers a CPU bug
On 26.11.2010 23:02, Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD
}
The results for yl2x(0x1.0076fc5cc7933866p+40L, LN2) are:
Intel: 0x1.bba4a9f774f49d0ap+4L
AMD:0x1.bba4a9f774f49d0cp+4L
The least significant bit is different. This corresponds only to a
fraction of a bit (that is, it's hardly important for accuracy. For
comparison, sin and cos on x86 lose nearly sixty bits of accuracy in
some cases!). Its importance is only that it is an undocumented
difference between manufacturers.
The difference was discovered through the unit tests for the
mathematical Special Functions which will be included in the next
compiler release. Discovery of the discrepancy happened only because
of several features of D:
- built-in unit tests (encourages tests to be run on many machines)
- built-in code coverage (the tests include extreme cases, simply
because I was trying to increase the code coverage to high values)
- D supports the hex format for floats. Without this feature, the
discrepancy would have been blamed on differences in the
floating-point conversion functions in the C standard library.
This experience reinforces my belief that D is an excellent language
for scientific computing.
Thanks to David Simcha and Dmitry Olshansky for help in tracking this
down.
Glad to help!
I was genuinely intrigued because not more then a few weeks ago I
discussed with a friend of mine a possibility of differences in FP
calculations of AMD vs Intel.
You see, his scientific app yielded different results when working at
home/at work, which is a frustrating experience. Since that's exactly
same binary, written in Delphi (no C run-time involved and so on) and
environment is pretty much the same... I suggested to check CPU vendors
just in case... of course, different.
In the meantime, I sort of ported the test case to M$ c++ inline asm
and posted it on AMD forums, let's see what they have to say.
http://forums.amd.com/forum/messageview.cfm?catid=319threadid=142893enterthread=y
http://forums.amd.com/forum/messageview.cfm?catid=319threadid=142893enterthread=y
--
Dmitry Olshansky
Re: TDPL in Russian
On 10.11.2010 1:22, Andrei Alexandrescu wrote: Just got word from my editor that TDPL has been approved for translation in Russian. Andrei Awesome! P.S. God, if you hear me, please, send us some _adequate_ Russian translators/reviewers. -- Dmitry Olshansky
