Re: datetime review part 2 [Update 6]
Newest: http://is.gd/hsNcq Since, I just overhauled some of my unit test functions, it seems appropriate to repost the changes. So, here they are. I also changed the days of the week to their abbreviated names, which I had meant to do earlier but forgot. No changes to the API other than the days of the week. - Jonathan M Davis P.S. Remember to link with advapi32.lib on Windows.
Re: Shared pain
On Fri, 19 Nov 2010 16:21:41 -0500, Jason House wrote: > Steve Teale Wrote: > >> On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote: >> >> > A cast to immutable is required when constructing immutable objects. >> > The type system can't prove that's safe. It's a design limitation to >> > keep complexity low. >> > >> Jason, >> >> But design limitations like that will force programmers who are on a >> tight schedule to just say __gshared, and to hell with it. >> >> Languages can't be designed just on theory - some recognition of >> practicality is also required. > > I didn't say I liked the need for the cast or even that I think D has > the proper design! IIRC, the cast with object creation was in lieu of > adding "unique" tepe qualifier and the extra complexity to get that > right. In your example, I believe the object was created once, so a cast > really isn't that bad. The bad part to me was the need to cast away > immutability with every use. That's why I encouraged a bugzilla entry. I > did't check this case, but Phobos had a bad track record with adopting > type qualifiers after they were added to D2. I'm a bit calmer now I have got most of my utility modules working again. There were two circumstances where I found the casts particularly irksome. I had at one point an immutable char* that I would be passing to Win32 functions. I was assigning to it the address of a plain static character array, and I had to use a cast to do it. I could not see what harm such an assignment could do. Then I had a slew of cases where I had created immutable RegExp objects, and I had to do (cast(RegExp) rexobj).find(...). I could not see what the cast was protecting here either. I think these are bugs, if you agree I will put them in bugzilla.
Error 42: Symbol Undefined __d_throwc
The following: import std.regex; void main() { string s = "$,"; replace(s, regex("$",","), ""); // Is this possible? If so, what is the propper way to do it? assert(s == "", s); } Compiled with dmd.2.039, 042, 048, and 049 but yields a runtime error: D:\code>bug object.Exception: unrecognized attribute Compiled with dmd.2.050, it yields the linker error: D:\code>dmd bug OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html bug.obj(bug) Error 42: Symbol Undefined __d_throwc --- errorlevel 1 I grepped my hard drive for _d_throwc and found the following: D:\code>grep -r -i _d_throwc d:\*.* \dmd2\linux\lib\libphobos2.a:_d_throwc \dmd2\linux\lib\libphobos2.a:.text._d_throwc \dmd2\linux\lib\libphobos2.a:.rel.text._d_throwc \dmd2\osx\lib\libphobos2.a:__d_throwc \dmd2\src\dmd\dmd.exe:_d_throwc \dmd2\src\dmd\rtlsym.obj:_d_throwc \dmd2\src\dmd\backend\rtlsym.h:SYMBOL_MARS(THROWC, FLfunc,(mES | mBP),"_d_throwc", SFLexit, t) \ \dmd2\src\druntime\deh.obj:__d_throwc.. \dmd2\src\druntime\lib\druntime.lib:__d_throwc.. \dmd2\src\druntime\lib\druntime.lib:__d_throwc. \dmd2\src\druntime\src\rt\deh.c:void _d_throwc(Object *h) \dmd2\src\druntime\src\rt\deh2.d:extern (C) void _d_throwc(Object *h) \dmd2\src\phobos\phobos.lib:__d_throwc.. \dmd2\windows\bin\dmd.exe:_d_throwc Redundant entries were removed for brevity. Function _d_throwc is defined on line 152 of dmd2\src\druntime\src\rt\deh2.d and line 232 of dmd2\src\druntime\src\rt\deh.d. I do not know how to correct the problem however it does seem odd that Linux's libphobos2.a uses the same name as was originally defined "_d_throwc" while OSX's libphobos2.a, druntime.lib and phobos.lib are different. Note that this function did not exist prior to dmd.2.050. Don't know if it matters but I'm using Win7. Any assistance is appreciated. Andrew
Re: standardization ISO
On Friday 19 November 2010 15:29:15 bioinfornatics wrote: > hi, why D language doesn't have a standardization (like iso)? > http://en.wikipedia.org/wiki/International_Organization_for_Standardization It takes years to reach that point. While the specification for D2 is now fairly stable, changes are still being made. You would have to have a very stable spec before trying to make it an international standard. And honestly, while it's nice to have an international standard, I'm not sure that it does all that much for you. Most languages - including many major ones - have no international standard. For instance, Java, python, and ruby don't have an ISO standard, and yet they're heavily used. Take a look here, and you'll see that very few languages have ISO standards: http://en.wikipedia.org/wiki/Comparison_of_programming_languages Really. I'm not sure that it's all that useful to have them in many cases - especially when you have a central place where the language is defined. Many languages are designed by one person or group and have specific language versions, so you have a specification that tools can use or which other groups can implement. It's generally a sign of maturity for a language when it gets an ISO standard, but the lack of one doesn't necessarily say anything bad about a language. D may very well get an ISO standard some day, but it doesn't need one, and I don't think that it would really be benefited by one at this point. It's going to have to be a lot more mature before that's likely a good idea. - Jonathan M Davis
Re: Kill implicit joining of adjacent strings
Stewart Gordon wrote: On 12/11/2010 09:53, Andrei Alexandrescu wrote: Well put me on board then. Walter, please don't forget to tweak the associativity rules: var ~ " literal " ~ " literal " concatenates literals first. You mean make ~ right-associative? I think this'll break more code than it fixes. But implementing a compiler optimisation so that var ~ ctc ~ ctc is processed as var ~ (ctc ~ ctc), _in those cases where they're equivalent_, would be sensible. Andrei's right. This is not about making it right-associative. It is about defining in the language that: ((a ~ b) ~ c) is guaranteed to produce the same result as: (a ~ (b ~ c)) Unfortunately, the language cannot make such a guarantee in the face of operator overloading. But it can do it for cases where operator overloading is not in play.
Re: std.algorithm.remove and principle of least astonishment
On 11/19/2010 16:40, Andrei Alexandrescu wrote: > On 11/19/10 12:59 PM, Bruno Medeiros wrote: >> Sorry, what I mean is: so we agree that char[] and wchar[] are special. >> Unlike *all other arrays*, there are restrictions to what you can assign >> to each element of the array. So conceptually they are not arrays, but >> in the type system they are very much arrays. (or described >> alternatively: implemented with arrays). >> >> Isn't this a clear sign that what currently is char[] and wchar[] (= >> UTF-8 and UTF-16 encoded strings) should not be arrays, but instead a >> struct which would correctly represents the semantics and contracts of >> char[] and wchar[]? Let me clarify what I'm suggesting: >> * char[] and wchar[] would be just arrays of char's and wchar's, >> completely orthogonal with other arrays types, no restrictions on >> assignment, no further contracts. >> * UTF-8 and UTF-16 encoded strings would have their own struct-based >> type, lets called them string and wstring, which would likely use char[] >> and wchar[] as the contents (but these fields would be internal), and >> have whatever methods be appropriate, including opIndex. >> * string literals would be of type string and wstring, not char[] and >> wchar[]. >> * for consistency, probably this would be true for UTF-32 as well: we >> would have a dstring, with dchar[] as the contents. >> >> Problem solved. You're welcome. (as John Hodgeman would say) >> >> No? > > I don't think that would mark an improvement. You don't see the advantage of generic types behaving in a generic manner? Do you know how much pain std::vector caused in C++? I asked this before, but I received no answer. Let me ask it again. Imagine a container Vector!T that uses T[] internally. Then consider Vector!char. What would be its correct element type? What would be its correct behavior during iteration? What would be its correct response when asked to return its length? Assuming you come up with a coherent set of semantics for Vector!char, how would you implement it? Do you see how easy it would be to implement it incorrectly? -- Rainer Deyke - rain...@eldwood.com
Re: D1 -> D2
Andrew Wiley wrote: On Fri, Nov 19, 2010 at 7:14 PM, Walter Bright mailto:newshou...@digitalmars.com>> wrote: Andrew Wiley wrote: I'm a fan of parsing false version blocks, but it seems like there should be some sort of exception for version blocks for a different version of the language. Could they just be skipped with a warning that an unknown version of the language is in use? It's somewhat hackish, but to me, that seems better than parsing it and giving an error because of syntax changes. How can it skip it without knowing the grammar? It's probably too much work for too little gain, but would it be possible to basically just scan for matching braces until the version block ends? If they always come in matching pairs (or at least they *should*), you could scan for them and ignore everything else until you find the end of the block. It would still have to know about all the new tokens.
Re: D1 -> D2
On Fri, Nov 19, 2010 at 7:14 PM, Walter Bright wrote: > Andrew Wiley wrote: > >> I'm a fan of parsing false version blocks, but it seems like there should >> be some sort of exception for version blocks for a different version of the >> language. Could they just be skipped with a warning that an unknown version >> of the language is in use? It's somewhat hackish, but to me, that seems >> better than parsing it and giving an error because of syntax changes. >> > > > How can it skip it without knowing the grammar? > It's probably too much work for too little gain, but would it be possible to basically just scan for matching braces until the version block ends? If they always come in matching pairs (or at least they *should*), you could scan for them and ignore everything else until you find the end of the block.
Re: standardization ISO
== Quote from bioinfornatics (bioinfornat...@fedoraproject.org)'s article > hi, why D language doesn't have a standardization (like iso)? > Because it is beneath it.
Re: D1 -> D2
torhu wrote: But current D 1 compilers are useless for most people anyway, until Tango catches up. And in any case, if you upgrade, you often get some nice new bugs in addition to the fixes, so upgrading is often not worth the hassle. But making it easier to go from D 1 to D 2 would still be a big gain, so why not do that? No one cares about "stability" of D 1 compilers. If you want "stability", it's very simple. You just don't upgrade. Tango is dying, and D 1 with it. We don't want "stability", we want a viable way to move to D 2. I understand. You can use a text preprocessor right now to do it, m4. It's quick, easy, and works.
Re: D1 -> D2
On 20.11.2010 01:18, Walter Bright wrote: Bernard Helyer wrote: No. The contents of a version block is still parsed. If the D2 code doesn't _parse_ as valid D1, then the D1 compiler will reject it, even if the version block will not be processed further than that. Yes. Now, if the D1 compiler is supposed to successfully lex& parse (and then ignore) false version blocks, it becomes impossible for a D1 compiler to be stable. It will have to track every future D language variant, missteps and all. But current D 1 compilers are useless for most people anyway, until Tango catches up. And in any case, if you upgrade, you often get some nice new bugs in addition to the fixes, so upgrading is often not worth the hassle. But making it easier to go from D 1 to D 2 would still be a big gain, so why not do that? No one cares about "stability" of D 1 compilers. If you want "stability", it's very simple. You just don't upgrade. Tango is dying, and D 1 with it. We don't want "stability", we want a viable way to move to D 2.
Re: D1 -> D2
On Sat, 20 Nov 2010 04:33:36 +0300, Walter Bright wrote: Denis Koroskin wrote: On Sat, 20 Nov 2010 04:14:05 +0300, Walter Bright How can it skip it without knowing the grammar? #ifdef D_Version2 ... #else ... #endif D has a precedence of having preprocessor macros (e.g #line) even if it's not a full-fledged preprocessor, and I don't see why it couldn't adapt the same solution. FWIW, C# has #if blocks, too. Yes, I know it can be done with a text preprocessor. [[ Queue run away screaming ]] Once again, it's NOT a text preprocessor. It's NOT a separate parsing phase (unlike C/C++). It's done at parsing level, similarly to comments.
Re: Looking for champion - std.lang.d.lex
On 11/19/2010 05:45 PM, Todd VanderVeen wrote: I agree. I do like the suggestion for developing the D grammar in Antlr though and it is something I would be interested in working on. With this in hand, the prospect of adding D support as was done for C++ to Eclipse or Netbeans becomes much more feasible. Has a complete grammar been defined/compiled or is anyone currently working in this direction? Having a robust IDE seems far more important than whether it is written in D itself. D is not a parser generator friendly language. I have pretty complete ANTLR2 grammars for D1 and D2, but they are slow.
Re: D1 -> D2
Denis Koroskin wrote: On Sat, 20 Nov 2010 04:14:05 +0300, Walter Bright How can it skip it without knowing the grammar? #ifdef D_Version2 ... #else ... #endif D has a precedence of having preprocessor macros (e.g #line) even if it's not a full-fledged preprocessor, and I don't see why it couldn't adapt the same solution. FWIW, C# has #if blocks, too. Yes, I know it can be done with a text preprocessor. [[ Queue run away screaming ]]
Re: Looking for champion - std.lang.d.lex
On Friday, November 19, 2010 15:17:35 Bruno Medeiros wrote: > On 19/11/2010 22:02, Jonathan M Davis wrote: > > On Friday, November 19, 2010 13:53:12 Bruno Medeiros wrote: > >> On 19/11/2010 21:27, Jonathan M Davis wrote: > >> > >> And by providing a lexer and a parser outside the standard library, > >> wouldn't it make it just as easy for those tools to be written? What's > >> the advantage of being in the standard library? I see only > >> disadvantages: to begin with it potentially increases the time that > >> Walter or other Phobos contributors may have to spend on it, even if > >> it's just reviewing patches or making sure the code works. > > > > If nothing, else, it makes it easier to keep in line with dmd itself. > > Since the dmd front end is LGPL, it's not possible to have a Boost port > > of it (like the Phobos version will be) without Walter's consent. And > > I'd be surprised if he did that for a third party library (though he > > seems to be pretty open on a lot of that kind of stuff). Not to mention, > > Walter and the core developers are _exactly_ the kind of people that you > > want working on a lexer or parser of the language itself, because > > they're the ones who work on it. > > > > - Jonathan M Davis > > Eh? That license argument doesn't make sense: if the lexer and parser > were to be based on DMD itself, then putting it in the standard library > is equivalent (in licensing terms) to licensing the lexer and parser > parts of DMD in Boost. More correctly, what I mean by equivalent, is > that there no reason why Walter would allow one thing and not the > other... (because on both cases he would have to issue that license) It's very different to have D implementation of something - which is based on a C++ version but definitely different in some respects - be under Boost and generally available, and having the C++ implementation be under Boost - particularly when the C++ version covers far more than just a lexer and parser. Someone _could_ port the D code back to C++ and have that portion useable under Boost, but that's a lot more work than just taking the C++ code and using it, and it's only the portions of the compiler which were ported to D to which could be re-used that way. And since the Boost code could be used in a commercial product while the LGPL is more restricted, it could make a definite difference. I'm not a licensing expert, and I'm not an expert on what Walter does and doesn't want done with his code, but he put the compiler front end under the LGPL, not Boost, and he's given his permission to have the lexer alone ported to D and put under the Boost license in the standard library, which is very different from putting the entire front end under Boost. I expect that the parser will follow eventually, but even if it does, that's still not the entire front end. So, there is a difference in licenses does have a real impact. And no one can take the LGPL C++ code and port it to D - for the standard library or otherwise - without Walter's permission, because its his copyright on the code. As for the usefulness of a D lexer and parser, I've already had several programs or functions which I've wanted to write which would require it, and the lack has made them infeasible. For instance, I was considering posting a version of my datetime code without the unit tests in it, so that it would be easier to read the actual code (given the large number of unit tests), but I found that to accurately do that, you need a lexer for D, so I gave up on it for the time being. Having a function which stripped out unnecessary whitespace (and especially newlines) for string mixins would be great (particularly since line numbers get messed up with multi-line string mixins), but that would require CTFE-able D lexer to work correctly (though you might be able to hack together something which would mostly work), which we don't have. The D lexer won't be CTFE-able initially (though hopefully it will be once the CTFE capabilites of dmd improve), so you still won't be able to do that once the lexer is done, but it is a case where a lexer would be useful. Ideally, Phobos would be huge in a manner similar to how C# or Java's libraries are huge. It will take time to get there, and we'll need more developers, but I don't think that it really makes sense to not put things in the standard library because it might take more dev time - particularly when a D lexer is the sort of thing that likely won't need much changing once it's done, since it would only need to be changed when the language changed or when a bug with it was found (which would likely equate to a bug in the compiler anyway), so ultimately, the developer cost is likely fairly low. Additionally, Walter thinks that the development costs will be lower to have it in the standard library with an implementation similar to dmd's rather than having it separate. And it's his call. So, it's going to get done.
Re: D1 -> D2
On Sat, 20 Nov 2010 04:14:05 +0300, Walter Bright wrote: Andrew Wiley wrote: I'm a fan of parsing false version blocks, but it seems like there should be some sort of exception for version blocks for a different version of the language. Could they just be skipped with a warning that an unknown version of the language is in use? It's somewhat hackish, but to me, that seems better than parsing it and giving an error because of syntax changes. How can it skip it without knowing the grammar? #ifdef D_Version2 ... #else ... #endif D has a precedence of having preprocessor macros (e.g #line) even if it's not a full-fledged preprocessor, and I don't see why it couldn't adapt the same solution. FWIW, C# has #if blocks, too.
Re: Register Preservation in Inline ASM Blocks
dsimcha wrote: What is the rule on who is responsible for saving registers when inserting an inline ASM block into the middle of a function? For example: void fun() { auto ptr = somePointer(); asm { mov EAX, ptr; lock; inc [EAX]; } } Is this acceptable (will the compiler do what it needs to do to deal with my usage of EAX), or do I need to do something more like: asm { push EAX; lock; inc [EAX]; pop EAX; } , leaving EAX exactly as I found it? Unless you use 'naked' asm, the compiler will figure it out for you.
Register Preservation in Inline ASM Blocks
What is the rule on who is responsible for saving registers when inserting an inline ASM block into the middle of a function? For example: void fun() { auto ptr = somePointer(); asm { mov EAX, ptr; lock; inc [EAX]; } } Is this acceptable (will the compiler do what it needs to do to deal with my usage of EAX), or do I need to do something more like: asm { push EAX; lock; inc [EAX]; pop EAX; } , leaving EAX exactly as I found it?
Re: D1 -> D2
Andrew Wiley wrote: I'm a fan of parsing false version blocks, but it seems like there should be some sort of exception for version blocks for a different version of the language. Could they just be skipped with a warning that an unknown version of the language is in use? It's somewhat hackish, but to me, that seems better than parsing it and giving an error because of syntax changes. How can it skip it without knowing the grammar?
Re: The D Scripting Language
By the way, I found a bug that I think is quite serious if DMD wants to hit the scripting languages world: http://d.puremagic.com/issues/show_bug.cgi?id=5243 Copied for convenience: dmd -run potentially removes user files See this example: $ mkdir x $ echo 'void main() {}' > x/test.d $ echo "my very important data that shouldn't be ereased" > test $ ls test test $ cat test my very important data that shouldn't be ereased $ dmd -run x/test.d $ ls test ls: cannot access test: No such file or directory $ cat test cat: test: No such file or directory I think this is a very serious bug. It's really unexpected that DMD removes the test file (I can understand why it happens, but it shouldn't). test.d being in another directory is just to point how much surprising could be that running a "script" in an unrelated directory removes files in the current directory. If DMD wants to put D in the scripting world, this should be fixed ASAP, as no scripting language EVER will remove your files unexpectedly. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- SATANAS EN COMISARIA -- Crónica TV
Re: Review: A new stab at a potential std.unittests
Jonathan M Davis, el 19 de noviembre a las 13:24 me escribiste: > On Friday 19 November 2010 12:39:20 Leandro Lucarella wrote: > > Sean Kelly, el 19 de noviembre a las 14:59 me escribiste: > > > Jonathan M Davis Wrote: > > > > On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > > > > > Jonathan M Davis Wrote: > > > > > > In particular, needing to pass LineInfo() to assertExcThrown!() to > > > > > > know the file and line number was disliked (though it was by far > > > > > > the best solution that I'd been able to come up with). > > > > > > > > > > Not sure if this helps, but if you default-initialize template > > > > > function parameters with __LINE__ and __FILE__ they get the line and > > > > > file of where the template was instantiated. > > > > > > > > Yes. The problem was that the function was a _variadic_ template. So, > > > > you couldn't have default arguments. > > > > > > This should work: > > > > > > void func(string x = __FILE__, T...)(T args); > > > > > > D allows defaulted template arguments to occur before non-defaulted ones. > > > > And what is func!("blah")(); is supposed to do, make x = "blah"? args[0] > > = "blah"? both? > > > > (I don't have a compiler at hand to try it =P) > > T... is filled in be args, so if there are no args, T is empty. It can't > confuse > x for T... Good point, thanks for the clarification. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Sometimes you got to suffer a little in your youth to motivate you to succeed later in life. Do you think if Bill Gates got laid in high school, do you think there'd be a Microsoft? Of course not. You gotta spend a lot of time stuffin your own locker with your underwear wedged up your arse before you think "I'm gona take over the world with computers! You'll see I'll show them."
Re: D1 -> D2
== Quote from Bernard Helyer (b.hel...@gmail.com)'s article > On Thu, 18 Nov 2010 19:58:42 +, %u wrote: > > == Quote from Denis Koroskin (2kor...@gmail.com)'s article > >> On Thu, 18 Nov 2010 22:19:12 +0300, Walter Bright > >> wrote: > >> > Steven Schveighoffer wrote: > >> >> My recommendation -- when you are ready, switch wholly to D2. Don't > >> >> bother with compatibility, it's just not possible. > >> > > >> > From what you wrote, it appears that most of the difficulties were > >> > in > >> > dealing with strings. > >> No, it's not. From my experience, a bigger issue is that version (D2) { > >> /* some D2 only code involving const etc */ > >> } > >> simply won't compile in D1, because even if it's D2-only the code needs > >> to be correct D1 code as well. > > > > Wow, that sucks!! > > Can't this simply be mended with special D_DMD1 and D_DMD2 (D_DMD3 :) > > version identifiers? > > If the compiler version isn't the same then it won't look at the code. > No. The contents of a version block is still parsed. If the D2 code > doesn't _parse_ as valid D1, then the D1 compiler will reject it, even if > the version block will not be processed further than that. Well, actually I said the compiler wouldn't look at it, so it wouldn't get parsed as well. What you should have said is that is very difficult to not parse a piece of code and still know its boundaries ;) So how can the compiler be sure a version block ends without actually parsing the text as code. A single line version would do :)
Re: D1 -> D2
On Fri, Nov 19, 2010 at 6:18 PM, Walter Bright wrote: > Bernard Helyer wrote: > >> No. The contents of a version block is still parsed. If the D2 code >> doesn't _parse_ as valid D1, then the D1 compiler will reject it, even if >> the version block will not be processed further than that. >> > > Yes. Now, if the D1 compiler is supposed to successfully lex & parse (and > then ignore) false version blocks, it becomes impossible for a D1 compiler > to be stable. It will have to track every future D language variant, > missteps and all. > I'm a fan of parsing false version blocks, but it seems like there should be some sort of exception for version blocks for a different version of the language. Could they just be skipped with a warning that an unknown version of the language is in use? It's somewhat hackish, but to me, that seems better than parsing it and giving an error because of syntax changes.
Re: D1 -> D2
Bernard Helyer wrote: No. The contents of a version block is still parsed. If the D2 code doesn't _parse_ as valid D1, then the D1 compiler will reject it, even if the version block will not be processed further than that. Yes. Now, if the D1 compiler is supposed to successfully lex & parse (and then ignore) false version blocks, it becomes impossible for a D1 compiler to be stable. It will have to track every future D language variant, missteps and all.
Re: Looking for champion - std.lang.d.lex
On 19/11/2010 23:45, Todd VanderVeen wrote: == Quote from Bruno Medeiros (brunodomedeiros+s...@com.gmail)'s article I think much sooner we will have a full D compiler written in D than a (competitive) D IDE written in D. I agree. I do like the suggestion for developing the D grammar in Antlr though and it is something I would be interested in working on. With this in hand, the prospect of adding D support as was done for C++ to Eclipse or Netbeans becomes much more feasible. Has a complete grammar been defined/compiled or is anyone currently working in this direction? Having a robust IDE seems far more important than whether it is written in D itself. See the comment I made below, to Michael Stover. ( news://news.digitalmars.com:119/ic71pa$1le...@digitalmars.com ) -- Bruno Medeiros - Software Engineer
Re: Looking for champion - std.lang.d.lex
On 27/10/2010 05:39, Walter Bright wrote: bearophile wrote: Walter: Java was designed to be simple! Simple means to have a more uniform semantics. So was Pascal. See the thread about how useless it was as a result. There's good simple, and there's bad simple... -- Bruno Medeiros - Software Engineer
Re: Simple @tagged attribute for unions [OT]
On Fri, Nov 19, 2010 at 5:46 PM, Bruno Medeiros wrote: > On 22/10/2010 04:04, Andrei Alexandrescu wrote: > >> On 10/21/2010 08:41 PM, bearophile wrote: >> >>> I have suggested yet another attribute, @tagged: >>> http://d.puremagic.com/issues/show_bug.cgi?id=5097 >>> >>> Bye, bearophile >>> >> >> And almost exactly six hours ago: >> >> On the other hand, currently there are many D2 features that are >>> unfinished and buggy, so adding even more stuff is not a good idea. >>> And I think named arguments are a purely additive change. So Walter >>> may add them later when the current features are implemented well >>> enough. Currently it's much more important to focus on eventually >>> needed non-additive changes instead. >>> >> >> Hope you agree with yourself :o). >> >> >> Andrei >> > > How did I miss that! It's bearophile's best comment ever! :D This isn't really related but it's an idea that I randomly had while reading that bug report: What if functionality like this could be implemented in mixins rather than compiler-defined annotations? The idea would be that an annotation, when applied to something, would be "instantiated" in some form, allowing it to mixin code somehow. I know that's vague, but it seems like it would have powerful applications for things like ORM libraries and other libraries. On the other hand, annotations go from metadata to something that potentially changes the code you're writing, which may not be a good idea. Disclaimer: This is utterly random and you're free to tell me it's foolishness.
Re: Linux Agora D thread
On 22/10/2010 11:17, retard wrote: Fri, 22 Oct 2010 02:42:49 -0700, Walter Bright wrote: retard wrote: Why I think the D platform's risk is so high is because the author constantly refuses to give ANY estimates on feature schedules. Would you believe them if I did? http://en.wikipedia.org/wiki/Software_development_process "Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking." http://en.wikipedia.org/wiki/Estimation_in_software_engineering "The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion is a serious problem for software engineers. The use of a repeatable, clearly defined and well understood software development process has, in recent years, shown itself to be the most effective method of gaining useful historical data that can be used for statistical estimation. In particular, the act of sampling more frequently, coupled with the loosening of constraints between parts of a project, has allowed more accurate estimation and more rapid development times." http://en.wikipedia.org/wiki/Application_Lifecycle_Management "Proponents of application lifecycle management claim that it * Increases productivity, as the team shares best practices for development and deployment, and developers need focus only on current business requirements * Improves quality, so the final application meets the needs and expectations of users * Breaks boundaries through collaboration and smooth information flow * Accelerates development through simplified integration * Cuts maintenance time by synchronizing application and design * Maximizes investments in skills, processes, and technologies * Increases flexibility by reducing the time it takes to build and adapt applications that support new business initiatives" http://en.wikipedia.org/wiki/Cowboy_coding "Lack of estimation or implementation planning may cause a project to be delayed. Sudden deadlines or pushes to release software may encourage the use of quick and dirty or code and fix techniques that will require further attention later." "Cowboy coding is common at the hobbyist or student level where developers may initially be unfamiliar with the technologies, such as the build tools, that the project requires." "Custom software applications, even when using a proven development cycle, can experience problems with the client concerning requirements. Cowboy coding can accentuate this problem by not scaling the requirements to a reasonable timeline, and may result in unused or unusable components being created before the project is finished. Similarly, projects with less tangible clients (often experimental projects, see independent game development) may begin with code and never a formal analysis of the design requirements. Lack of design analysis may lead to incorrect or insufficient technology choices, possibly requiring the developer to port or rewrite their software in order for the project to be completed." "Many software development models, such as Extreme Programming, use an incremental approach which stresses functional prototypes at each phase. Non-managed projects may have few unit tests or working iterations, leaving an incomplete project unusable." What's your point with all of this? That Walter should do estimates? -- Bruno Medeiros - Software Engineer
Re: D1 -> D2
On Thu, 18 Nov 2010 19:58:42 +, %u wrote: > == Quote from Denis Koroskin (2kor...@gmail.com)'s article >> On Thu, 18 Nov 2010 22:19:12 +0300, Walter Bright >> wrote: >> > Steven Schveighoffer wrote: >> >> My recommendation -- when you are ready, switch wholly to D2. Don't >> >> bother with compatibility, it's just not possible. >> > >> > From what you wrote, it appears that most of the difficulties were >> > in >> > dealing with strings. >> No, it's not. From my experience, a bigger issue is that version (D2) { >> /* some D2 only code involving const etc */ >> } >> simply won't compile in D1, because even if it's D2-only the code needs >> to be correct D1 code as well. > > Wow, that sucks!! > Can't this simply be mended with special D_DMD1 and D_DMD2 (D_DMD3 :) > version identifiers? > If the compiler version isn't the same then it won't look at the code. No. The contents of a version block is still parsed. If the D2 code doesn't _parse_ as valid D1, then the D1 compiler will reject it, even if the version block will not be processed further than that.
Re: Looking for champion - std.lang.d.lex
so that was 4 months ago - how do things currently stand on that initiative? -Mike On Fri, Nov 19, 2010 at 6:37 PM, Bruno Medeiros wrote: > On 19/11/2010 22:25, Michael Stover wrote: > >> As for D lexers and tokenizers, what would be nice is to >> A) build an antlr grammar for D >> B) build D targets for antlr so that antlr can generate lexers and >> parsers in the D language. >> >> For B) I found http://www.mbutscher.de/antlrd/index.html >> >> For A) A good list of antlr grammars is at >> http://www.antlr.org/grammar/list, but there isn't a D grammar. >> >> These things wouldn't be an enormous amount of work to create and >> maintain, and, if done, anyone could parse D code in many languages, >> including Java and C which would make providing IDE features for D >> development easier in those languages (eclipse for instance), and you >> could build lexers and parsers in D using antlr grammars. >> >> -Mike >> > > Yes, that would be much better. It would be directly and immediately useful > for the DDT project: > > "But better yet would be to start coding our own custom parser (using a > parser generator like ANTLR for example), that could really be tailored for > IDE needs. In the medium/long term, that's probably what needs to be done. " > in > http://www.digitalmars.com/d/archives/digitalmars/D/ide/Future_of_Descent_and_D_Eclipse_IDE_635.html > > -- > Bruno Medeiros - Software Engineer >
Re: Simple @tagged attribute for unions
On 22/10/2010 04:04, Andrei Alexandrescu wrote: On 10/21/2010 08:41 PM, bearophile wrote: I have suggested yet another attribute, @tagged: http://d.puremagic.com/issues/show_bug.cgi?id=5097 Bye, bearophile And almost exactly six hours ago: On the other hand, currently there are many D2 features that are unfinished and buggy, so adding even more stuff is not a good idea. And I think named arguments are a purely additive change. So Walter may add them later when the current features are implemented well enough. Currently it's much more important to focus on eventually needed non-additive changes instead. Hope you agree with yourself :o). Andrei How did I miss that! It's bearophile's best comment ever! :D -- Bruno Medeiros - Software Engineer
Re: Looking for champion - std.lang.d.lex
== Quote from Bruno Medeiros (brunodomedeiros+s...@com.gmail)'s article > I think much sooner we will > have a full D compiler written in D than a (competitive) D IDE written > in D. I agree. I do like the suggestion for developing the D grammar in Antlr though and it is something I would be interested in working on. With this in hand, the prospect of adding D support as was done for C++ to Eclipse or Netbeans becomes much more feasible. Has a complete grammar been defined/compiled or is anyone currently working in this direction? Having a robust IDE seems far more important than whether it is written in D itself.
Re: std.algorithm.remove and principle of least astonishment
On 11/19/10 12:59 PM, Bruno Medeiros wrote: On 16/10/2010 20:51, Andrei Alexandrescu wrote: On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: I suggest wrapping a char[] or wchar[] (of all constancies) with a special range that imposes the restrictions. I did so. It was called byDchar and it would accept a string type. It sucked. char[] and wchar[] are special. They embed their UTF affiliation in their type. I don't think we should make a wash of all that by handling them as arrays. They are not arrays. Andrei "They are not arrays."? So why are they arrays then? :3 Sorry, what I mean is: so we agree that char[] and wchar[] are special. Unlike *all other arrays*, there are restrictions to what you can assign to each element of the array. So conceptually they are not arrays, but in the type system they are very much arrays. (or described alternatively: implemented with arrays). Isn't this a clear sign that what currently is char[] and wchar[] (= UTF-8 and UTF-16 encoded strings) should not be arrays, but instead a struct which would correctly represents the semantics and contracts of char[] and wchar[]? Let me clarify what I'm suggesting: * char[] and wchar[] would be just arrays of char's and wchar's, completely orthogonal with other arrays types, no restrictions on assignment, no further contracts. * UTF-8 and UTF-16 encoded strings would have their own struct-based type, lets called them string and wstring, which would likely use char[] and wchar[] as the contents (but these fields would be internal), and have whatever methods be appropriate, including opIndex. * string literals would be of type string and wstring, not char[] and wchar[]. * for consistency, probably this would be true for UTF-32 as well: we would have a dstring, with dchar[] as the contents. Problem solved. You're welcome. (as John Hodgeman would say) No? I don't think that would mark an improvement. Andrei
Re: Looking for champion - std.lang.d.lex
On 11/19/10 1:03 PM, Bruno Medeiros wrote: On 22/10/2010 20:48, Andrei Alexandrescu wrote: On 10/22/10 14:02 CDT, Tomek Sowiński wrote: Dnia 22-10-2010 o 00:01:21 Walter Bright napisał(a): As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers. It should: 1. support a range interface for its input, and a range interface for its output 2. optionally not generate lexical errors, but just try to recover and continue 3. optionally return comments and ddoc comments as tokens 4. the tokens should be a value type, not a reference type 5. generally follow along with the C++ one so that they can be maintained in tandem It can also serve as the basis for creating a javascript implementation that can be embedded into web pages for syntax highlighting, and eventually an std.lang.d.parse. Anyone want to own this? Interesting idea. Here's another: D will soon need bindings for CORBA, Thrift, etc, so lexers will have to be written all over to grok interface files. Perhaps a generic tokenizer which can be parametrized with a lexical grammar would bring more ROI, I got a hunch D's templates are strong enough to pull this off without any source code generation ala JavaCC. The books I read on compilers say tokenization is a solved problem, so the theory part on what a good abstraction should be is done. What you think? Yes. IMHO writing a D tokenizer is a wasted effort. We need a tokenizer generator. Agreed, of all the things desired for D, a D tokenizer would rank pretty low I think. Another thing, even though a tokenizer generator would be much more desirable, I wonder if it is wise to have that in the standard library? It does not seem to be of wide enough interest to be in a standard library. (Out of curiosity, how many languages have such a thing in their standard library?) Even C has strtok. Andrei
Re: Looking for champion - std.lang.d.lex
On 19/11/2010 22:25, Michael Stover wrote: As for D lexers and tokenizers, what would be nice is to A) build an antlr grammar for D B) build D targets for antlr so that antlr can generate lexers and parsers in the D language. For B) I found http://www.mbutscher.de/antlrd/index.html For A) A good list of antlr grammars is at http://www.antlr.org/grammar/list, but there isn't a D grammar. These things wouldn't be an enormous amount of work to create and maintain, and, if done, anyone could parse D code in many languages, including Java and C which would make providing IDE features for D development easier in those languages (eclipse for instance), and you could build lexers and parsers in D using antlr grammars. -Mike Yes, that would be much better. It would be directly and immediately useful for the DDT project: "But better yet would be to start coding our own custom parser (using a parser generator like ANTLR for example), that could really be tailored for IDE needs. In the medium/long term, that's probably what needs to be done. " in http://www.digitalmars.com/d/archives/digitalmars/D/ide/Future_of_Descent_and_D_Eclipse_IDE_635.html -- Bruno Medeiros - Software Engineer
standardization ISO
hi, why D language doesn't have a standardization (like iso)? http://en.wikipedia.org/wiki/International_Organization_for_Standardization
Re: Looking for champion - std.lang.d.lex
On 19/11/2010 22:02, Jonathan M Davis wrote: On Friday, November 19, 2010 13:53:12 Bruno Medeiros wrote: On 19/11/2010 21:27, Jonathan M Davis wrote: And by providing a lexer and a parser outside the standard library, wouldn't it make it just as easy for those tools to be written? What's the advantage of being in the standard library? I see only disadvantages: to begin with it potentially increases the time that Walter or other Phobos contributors may have to spend on it, even if it's just reviewing patches or making sure the code works. If nothing, else, it makes it easier to keep in line with dmd itself. Since the dmd front end is LGPL, it's not possible to have a Boost port of it (like the Phobos version will be) without Walter's consent. And I'd be surprised if he did that for a third party library (though he seems to be pretty open on a lot of that kind of stuff). Not to mention, Walter and the core developers are _exactly_ the kind of people that you want working on a lexer or parser of the language itself, because they're the ones who work on it. - Jonathan M Davis Eh? That license argument doesn't make sense: if the lexer and parser were to be based on DMD itself, then putting it in the standard library is equivalent (in licensing terms) to licensing the lexer and parser parts of DMD in Boost. More correctly, what I mean by equivalent, is that there no reason why Walter would allow one thing and not the other... (because on both cases he would have to issue that license) As for your second argument, yes, Walter and the core developers would be the most qualified people to work in it, no question about it. But my point is, I don't think Walter and Phobos core devs should be working on it, because it takes time away from other things that are much more important. Their time is precious. I think our main point of disagreement is just how important a D lexer and/or parser would be. I think it would be of very low interest, definitely not a "major benefit to the D community". For starters, regarding its use in IDEs: I think we are *ages* away from the point were an IDE based on D only will be able to compete with IDEs based in Eclipse/Visual-Studio/Xcode/etc.. I think much sooner we will have a full D compiler written in D than a (competitive) D IDE written in D. We barely have mature GUI libraries from what I understand. (What may be more realistic is an IDE partially written in D, and otherwise based on Eclipse/Visual-Studio/etc., but even so, I think it would be hard to compete with other non-D IDEs) -- Bruno Medeiros - Software Engineer
Re: Some new LLVM slides/videos
bearophile wrote: "Implementing Include-What-You-Use using clang": I'd like still D module system to be more tidy and import only the "foo" name when you write: import foo; So you need to use foo.bar and foo.baz. D already does this: static import foo; And to import "bar" and "baz" names and not the "foo" name when you write: import foo: bar, baz; D already does this, too. And to import all the names from "foo" (but not the "foo" name itself) using some syntax with * or "all" or something similar. This makes code more readable and tidy, and makes the work of D analysis tools simpler. This has been discussed many times, and has been soundly rejected for numerous reasons. For one thing, it does not make analysis easier, because it is unknown what files will actually get imported.
Re: Review: A new stab at a potential std.unittests
Leandro Lucarella Wrote: > Sean Kelly, el 19 de noviembre a las 14:59 me escribiste: > > > > This should work: > > > > void func(string x = __FILE__, T...)(T args); > > > > D allows defaulted template arguments to occur before non-defaulted ones. > > And what is func!("blah")(); is supposed to do, make x = "blah"? args[0] > = "blah"? both? void func(string x = __FILE__, T...)(T args) { writeln( x, ' ', args.length ); } void main() { func!("hi")(); } prints: hi 0
Re: Looking for champion - std.lang.d.lex
On 27/10/2010 22:04, retard wrote: Wed, 27 Oct 2010 13:52:29 -0700, Walter Bright wrote: retard wrote: Wed, 27 Oct 2010 12:08:19 -0700, Walter Bright wrote: retard wrote: This is why the basic data structure in functional languages, algebraic data types, suits better for this purpose. I think you recently demonstrated otherwise, as proven by the widespread use of Java :-) I don't understand your logic -- Widespread use of Java proves that algebraic data types aren't a better suited way for expressing compiler's data structures such as syntax trees? You told me that widespread use of Java proved that nothing more complex than what Java provides is useful: "Java is mostly used for general purpose programming so your claims about usefulness and the need for extreme performance look silly." I'd be surprised if you seriously meant that, as it implies that Java is the pinnacle of computer language design, but I can't resist teasing you about it. :-) I only meant that the widespead adoption of Java shows how the public at large cares very little about the performance issues you mentioned. Java is one of the most widely used languages and it's also successful in many fields. Things could be better from programming language theory's point of view, but the business world is more interesting in profits and the large pool of Java coders has given better benefits than more expressive languages. I don't think that says anything against my notes about algebraic data types. "the widespead adoption of Java shows how the public at large cares very little about the performance issues you mentioned" WTF? The widespead adoption of Java means that _Java developers_ at large don't care about those performance issues (mostly because they work on stuff where they don't need to). But it's no statement about all the pool of developers. Java is hugely popular, but not in a "it's practically the only language people use" way. It's not like Windows on the desktop. -- Bruno Medeiros - Software Engineer
Re: Looking for champion - std.lang.d.lex
On Fri, Nov 19, 2010 at 4:20 PM, bearophile wrote: > Bruno Medeiros: > > > Java is quickly becoming a legacy language? the next COBOL? SRSLY?... > > Just two years ago, the now hugely popular Android platform choose Java > > as it's language of choice, and you think Java is becoming legacy?... > > Java on Adroid is not going well, there is a Oracle->Google lawsuit in > progress. Google is interested in using a variant of NaCL on Android too. > I have to agree with Bruno here, Java isn't going anywhere soon. It has an active community, corporations that very actively support it, and an open source effort that's probably the largest of any language (check out the Apache Foundation project lists). Toss in Clojure, Scala, Groovy, and their friends that can build on top of Java libraries, and you wind up with a package that isn't becoming obsolete any time soon.
Re: Looking for champion - std.lang.d.lex
As for D lexers and tokenizers, what would be nice is to A) build an antlr grammar for D B) build D targets for antlr so that antlr can generate lexers and parsers in the D language. For B) I found http://www.mbutscher.de/antlrd/index.html For A) A good list of antlr grammars is at http://www.antlr.org/grammar/list, but there isn't a D grammar. These things wouldn't be an enormous amount of work to create and maintain, and, if done, anyone could parse D code in many languages, including Java and C which would make providing IDE features for D development easier in those languages (eclipse for instance), and you could build lexers and parsers in D using antlr grammars. -Mike On Fri, Nov 19, 2010 at 5:09 PM, Bruno Medeiros wrote: > On 27/10/2010 22:43, Nick Sabalausky wrote: > >> "retard" wrote in message >> news:iaa44v$17s...@digitalmars.com... >> >>> >>> I only meant that the widespead adoption of Java shows how the public at >>> large cares very little about the performance issues you mentioned. >>> >> >> The public at large is convinced that "Java is fast now, really!". So I'm >> not certain widespread adoption of Java necessarily indicates they don't >> care so much about performance. Of course, Java is quickly becoming a >> legacy >> language anyway (the next COBOL, IMO), so that throws another wrench into >> the works. >> >> >> > Java is quickly becoming a legacy language? the next COBOL? SRSLY?... > Just two years ago, the now hugely popular Android platform choose Java as > it's language of choice, and you think Java is becoming legacy?... > > The development of the Java language itself has stagnated over the last 6 > years or so (especially due to corporate politics, which now has become even > worse and uncertain with all the shit Oracle is doing), but that's a > completely different statement from saying Java is becoming legacy. > In fact, all the uproar and concern about the future of Java under Oracle, > of the JVM, of the JCP (the body that regulates changes to Java),etc., is a > testament to the huge popularity of Java. Otherwise people (and > corporations) wouldn't care, they would just let it wither away with much > less concern. > > > -- > Bruno Medeiros - Software Engineer >
Re: Looking for champion - std.lang.d.lex
Bruno Medeiros: > Java is quickly becoming a legacy language? the next COBOL? SRSLY?... > Just two years ago, the now hugely popular Android platform choose Java > as it's language of choice, and you think Java is becoming legacy?... Java on Adroid is not going well, there is a Oracle->Google lawsuit in progress. Google is interested in using a variant of NaCL on Android too. Bye, bearophile
Re: Looking for champion - std.lang.d.lex
On 27/10/2010 22:43, Nick Sabalausky wrote: "retard" wrote in message news:iaa44v$17s...@digitalmars.com... I only meant that the widespead adoption of Java shows how the public at large cares very little about the performance issues you mentioned. The public at large is convinced that "Java is fast now, really!". So I'm not certain widespread adoption of Java necessarily indicates they don't care so much about performance. Of course, Java is quickly becoming a legacy language anyway (the next COBOL, IMO), so that throws another wrench into the works. Java is quickly becoming a legacy language? the next COBOL? SRSLY?... Just two years ago, the now hugely popular Android platform choose Java as it's language of choice, and you think Java is becoming legacy?... The development of the Java language itself has stagnated over the last 6 years or so (especially due to corporate politics, which now has become even worse and uncertain with all the shit Oracle is doing), but that's a completely different statement from saying Java is becoming legacy. In fact, all the uproar and concern about the future of Java under Oracle, of the JVM, of the JCP (the body that regulates changes to Java),etc., is a testament to the huge popularity of Java. Otherwise people (and corporations) wouldn't care, they would just let it wither away with much less concern. -- Bruno Medeiros - Software Engineer
Re: Looking for champion - std.lang.d.lex
On Friday, November 19, 2010 13:53:12 Bruno Medeiros wrote: > On 19/11/2010 21:27, Jonathan M Davis wrote: > > On Friday 19 November 2010 13:03:53 Bruno Medeiros wrote: > >> On 22/10/2010 20:48, Andrei Alexandrescu wrote: > >>> On 10/22/10 14:02 CDT, Tomek Sowiński wrote: > Dnia 22-10-2010 o 00:01:21 Walter Bright > > napisał(a): > > As we all know, tool support is important for D's success. Making > > tools easier to build will help with that. > > > > To that end, I think we need a lexer for the standard library - > > std.lang.d.lex. It would be helpful in writing color syntax > > highlighting filters, pretty printers, repl, doc generators, static > > analyzers, and even D compilers. > > > > It should: > > > > 1. support a range interface for its input, and a range interface for > > its output > > 2. optionally not generate lexical errors, but just try to recover > > and continue > > 3. optionally return comments and ddoc comments as tokens > > 4. the tokens should be a value type, not a reference type > > 5. generally follow along with the C++ one so that they can be > > maintained in tandem > > > > It can also serve as the basis for creating a javascript > > implementation that can be embedded into web pages for syntax > > highlighting, and eventually an std.lang.d.parse. > > > > Anyone want to own this? > > Interesting idea. Here's another: D will soon need bindings for CORBA, > Thrift, etc, so lexers will have to be written all over to grok > interface files. Perhaps a generic tokenizer which can be parametrized > with a lexical grammar would bring more ROI, I got a hunch D's > templates are strong enough to pull this off without any source code > generation ala JavaCC. The books I read on compilers say tokenization > is a solved problem, so the theory part on what a good abstraction > should be is done. What you think? > >>> > >>> Yes. IMHO writing a D tokenizer is a wasted effort. We need a tokenizer > >>> generator. > >> > >> Agreed, of all the things desired for D, a D tokenizer would rank pretty > >> low I think. > >> > >> Another thing, even though a tokenizer generator would be much more > >> desirable, I wonder if it is wise to have that in the standard library? > >> It does not seem to be of wide enough interest to be in a standard > >> library. (Out of curiosity, how many languages have such a thing in > >> their standard library?) > > > > We want to make it easy for tools to be built to work on and deal with D > > code. An IDE, for example, needs to be able to tokenize and parse D > > code. A program like lint needs to be able to tokenize and parse D code. > > By providing a lexer and parser in the standard library, we are making > > it far easier for such tools to be written, and they could be of major > > benefit to the D community. Sure, the average program won't need to lex > > or parse D, but some will, and making it easy to do will make it a lot > > easier for such programs to be written. > > > > - Jonathan M Davis > > And by providing a lexer and a parser outside the standard library, > wouldn't it make it just as easy for those tools to be written? What's > the advantage of being in the standard library? I see only > disadvantages: to begin with it potentially increases the time that > Walter or other Phobos contributors may have to spend on it, even if > it's just reviewing patches or making sure the code works. If nothing, else, it makes it easier to keep in line with dmd itself. Since the dmd front end is LGPL, it's not possible to have a Boost port of it (like the Phobos version will be) without Walter's consent. And I'd be surprised if he did that for a third party library (though he seems to be pretty open on a lot of that kind of stuff). Not to mention, Walter and the core developers are _exactly_ the kind of people that you want working on a lexer or parser of the language itself, because they're the ones who work on it. - Jonathan M Davis
Re: Some new LLVM slides/videos
Emil Madsen: > So these sliders are empty - I take it? I have just lost them a moment behind the table, sorry. Through Reddit I have found a group of new slides/videos on LLVM ("2010 LLVM Developers' Meeting"), some of them are interesting: http://llvm.org/devmtg/2010-11/ Some comments about the PDF slides: "Implementing Include-What-You-Use using clang": I'd like still D module system to be more tidy and import only the "foo" name when you write: import foo; So you need to use foo.bar and foo.baz. And to import "bar" and "baz" names and not the "foo" name when you write: import foo: bar, baz; And to import all the names from "foo" (but not the "foo" name itself) using some syntax with * or "all" or something similar. This makes code more readable and tidy, and makes the work of D analysis tools simpler. "Polly - Polyhedral optimizations in LLVM" and "Symbolic Crosschecking of Floating-Point and SIMD Code": they remind me something said by Walter too recently. It's stupid to use tons of analysis to extract high-level semantics from low-level C-style code and then compile it again in asm. It's much better to give programmers a (little or big) language that allows to directly express the high level semantics of heavy numerical processing code (that often are some nested loops on arrays and sometimes on trees/graphs). In D this may be done using something like this: mixin(Looper!q{ // high-level numerical processing code here }); That's not a tidy thing, and it asks programmers to learn a special little language, but it seems better than the alternative (unless you are able to use languages like Chapel that allow you to express that semantics already). To implement that in D you need a compile-time compiler that returns a string that contains asm{...} or even normal D code. To implement this compile-time compiler you may "just" need to improve D CTFE so it uses memory better, so it becomes fast enough. Example: processing.js is a large JavaScript file that essentially parses Java code and runs it in JavaScript: http://processingjs.org/ JavaScript today is much faster than D CTFE, but there is more space for improvements in D CTFE because the CTFE code is statically typed D, that's much simpler than JavaScript to run efficiently even in an interpreter. "Creating cling, an interactive interpreter interface for clang": the D front-end already contains a partial D interpreter. If this interpreter gets moved (or copied) inside a library that may be used from D code at runtime, then implementing a D interactive interpreter becomes simple, and enbedding Lua/Python/etc inside D becomes less necessary. Having a partial interpreter inside the compiler and not being able to use it at runtime is a wasted opportunity. "Hardening LLVM With Random Testing": eventually DMD/D compilers will enjoy similar random testing, but probably it's too much early now, it's easy still to find enough bugs manually. Bye, bearophile
Re: Looking for champion - std.lang.d.lex
On 19/11/2010 21:27, Jonathan M Davis wrote: On Friday 19 November 2010 13:03:53 Bruno Medeiros wrote: On 22/10/2010 20:48, Andrei Alexandrescu wrote: On 10/22/10 14:02 CDT, Tomek Sowiński wrote: Dnia 22-10-2010 o 00:01:21 Walter Bright napisał(a): As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers. It should: 1. support a range interface for its input, and a range interface for its output 2. optionally not generate lexical errors, but just try to recover and continue 3. optionally return comments and ddoc comments as tokens 4. the tokens should be a value type, not a reference type 5. generally follow along with the C++ one so that they can be maintained in tandem It can also serve as the basis for creating a javascript implementation that can be embedded into web pages for syntax highlighting, and eventually an std.lang.d.parse. Anyone want to own this? Interesting idea. Here's another: D will soon need bindings for CORBA, Thrift, etc, so lexers will have to be written all over to grok interface files. Perhaps a generic tokenizer which can be parametrized with a lexical grammar would bring more ROI, I got a hunch D's templates are strong enough to pull this off without any source code generation ala JavaCC. The books I read on compilers say tokenization is a solved problem, so the theory part on what a good abstraction should be is done. What you think? Yes. IMHO writing a D tokenizer is a wasted effort. We need a tokenizer generator. Agreed, of all the things desired for D, a D tokenizer would rank pretty low I think. Another thing, even though a tokenizer generator would be much more desirable, I wonder if it is wise to have that in the standard library? It does not seem to be of wide enough interest to be in a standard library. (Out of curiosity, how many languages have such a thing in their standard library?) We want to make it easy for tools to be built to work on and deal with D code. An IDE, for example, needs to be able to tokenize and parse D code. A program like lint needs to be able to tokenize and parse D code. By providing a lexer and parser in the standard library, we are making it far easier for such tools to be written, and they could be of major benefit to the D community. Sure, the average program won't need to lex or parse D, but some will, and making it easy to do will make it a lot easier for such programs to be written. - Jonathan M Davis And by providing a lexer and a parser outside the standard library, wouldn't it make it just as easy for those tools to be written? What's the advantage of being in the standard library? I see only disadvantages: to begin with it potentially increases the time that Walter or other Phobos contributors may have to spend on it, even if it's just reviewing patches or making sure the code works. -- Bruno Medeiros - Software Engineer
Re: Looking for champion - std.lang.d.lex [Java and IDE's]
On 27/10/2010 05:39, Walter Bright wrote: What I miss more in Java is not single structs (single values), There's a lot more to miss than that. I find Java code tends to be excessively complex, and that's because it lacks expressive power. It was summed up for me by a colleague who said that one needs an IDE to program in Java because with one button it will auto-generate 100 lines of boilerplate. I've been hearing that a lot, but I find this to be excessively exaggerated. Can you give some concrete examples? Because regarding excessive verbosity in Java, I cab only remember tree significant things at the moment (at least disregarding meta programming), and one of them is nearly as verbose in D as in Java: 1) writing getters and setters for fields 2) verbose syntax for closures. (need to use an anonymous class, outer variables must be final, and wrapped in an array if write access is needed) 3) writing trivial constructors whose parameters mirror the fields, and then constructors assign the parameters to the fields. I don't think 1 and 2 happens that often to be that much of an annoyance. (unless you're one of those Java persons that thinks that directly accessing the public field of another class is a sin, instead every single field must have getters/setters and never ever be public...) As an additional note, I don't think having an IDE auto-generate X lines of boilerplate code is necessarily a bad thing. It's only bad if the alternative of having a better language feature would actually save me coding time (whether initial coding, or subsequent modifications) or improve code understanding. _Isn't this what matters?_ -- Bruno Medeiros - Software Engineer
Re: Some new LLVM slides/videos
So these sliders are empty - I take it? On 19 November 2010 22:29, bearophile wrote: > > -- // Yours sincerely // Emil 'Skeen' Madsen
Some new LLVM slides/videos
Re: Looking for champion - std.lang.d.lex
On Friday 19 November 2010 13:03:53 Bruno Medeiros wrote: > On 22/10/2010 20:48, Andrei Alexandrescu wrote: > > On 10/22/10 14:02 CDT, Tomek Sowiński wrote: > >> Dnia 22-10-2010 o 00:01:21 Walter Bright > >> > >> napisał(a): > >>> As we all know, tool support is important for D's success. Making > >>> tools easier to build will help with that. > >>> > >>> To that end, I think we need a lexer for the standard library - > >>> std.lang.d.lex. It would be helpful in writing color syntax > >>> highlighting filters, pretty printers, repl, doc generators, static > >>> analyzers, and even D compilers. > >>> > >>> It should: > >>> > >>> 1. support a range interface for its input, and a range interface for > >>> its output > >>> 2. optionally not generate lexical errors, but just try to recover and > >>> continue > >>> 3. optionally return comments and ddoc comments as tokens > >>> 4. the tokens should be a value type, not a reference type > >>> 5. generally follow along with the C++ one so that they can be > >>> maintained in tandem > >>> > >>> It can also serve as the basis for creating a javascript > >>> implementation that can be embedded into web pages for syntax > >>> highlighting, and eventually an std.lang.d.parse. > >>> > >>> Anyone want to own this? > >> > >> Interesting idea. Here's another: D will soon need bindings for CORBA, > >> Thrift, etc, so lexers will have to be written all over to grok > >> interface files. Perhaps a generic tokenizer which can be parametrized > >> with a lexical grammar would bring more ROI, I got a hunch D's templates > >> are strong enough to pull this off without any source code generation > >> ala JavaCC. The books I read on compilers say tokenization is a solved > >> problem, so the theory part on what a good abstraction should be is > >> done. What you think? > > > > Yes. IMHO writing a D tokenizer is a wasted effort. We need a tokenizer > > generator. > > Agreed, of all the things desired for D, a D tokenizer would rank pretty > low I think. > > Another thing, even though a tokenizer generator would be much more > desirable, I wonder if it is wise to have that in the standard library? > It does not seem to be of wide enough interest to be in a standard > library. (Out of curiosity, how many languages have such a thing in > their standard library?) We want to make it easy for tools to be built to work on and deal with D code. An IDE, for example, needs to be able to tokenize and parse D code. A program like lint needs to be able to tokenize and parse D code. By providing a lexer and parser in the standard library, we are making it far easier for such tools to be written, and they could be of major benefit to the D community. Sure, the average program won't need to lex or parse D, but some will, and making it easy to do will make it a lot easier for such programs to be written. - Jonathan M Davis
Re: Shared pain
Steve Teale Wrote: > On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote: > > > A cast to immutable is required when constructing immutable objects. The > > type system can't prove that's safe. It's a design limitation to keep > > complexity low. > > > Jason, > > But design limitations like that will force programmers who are on a > tight schedule to just say __gshared, and to hell with it. > > Languages can't be designed just on theory - some recognition of > practicality is also required. I didn't say I liked the need for the cast or even that I think D has the proper design! IIRC, the cast with object creation was in lieu of adding "unique" tepe qualifier and the extra complexity to get that right. In your example, I believe the object was created once, so a cast really isn't that bad. The bad part to me was the need to cast away immutability with every use. That's why I encouraged a bugzilla entry. I did't check this case, but Phobos had a bad track record with adopting type qualifiers after they were added to D2.
Re: Review: A new stab at a potential std.unittests
On Friday 19 November 2010 12:39:20 Leandro Lucarella wrote: > Sean Kelly, el 19 de noviembre a las 14:59 me escribiste: > > Jonathan M Davis Wrote: > > > On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > > > > Jonathan M Davis Wrote: > > > > > In particular, needing to pass LineInfo() to assertExcThrown!() to > > > > > know the file and line number was disliked (though it was by far > > > > > the best solution that I'd been able to come up with). > > > > > > > > Not sure if this helps, but if you default-initialize template > > > > function parameters with __LINE__ and __FILE__ they get the line and > > > > file of where the template was instantiated. > > > > > > Yes. The problem was that the function was a _variadic_ template. So, > > > you couldn't have default arguments. > > > > This should work: > > > > void func(string x = __FILE__, T...)(T args); > > > > D allows defaulted template arguments to occur before non-defaulted ones. > > And what is func!("blah")(); is supposed to do, make x = "blah"? args[0] > = "blah"? both? > > (I don't have a compiler at hand to try it =P) T... is filled in be args, so if there are no args, T is empty. It can't confuse x for T... - Jonathan M Davis
state & effects
Hello, In a recent thread about pure functions, I argued about the fact that what we actually need, and miss, is a clear definition of what state is and is not. I just stepped on a paper by Alessandro Warth (author of OMeta) and Alan Kay (author of... ;-) prcisely on this topic: Worlds: Controlling the Scope of Side Effects http://www.vpri.org/pdf/rn2008001_worlds.pdf FWIW... Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Review: A new stab at a potential std.unittests
Sean Kelly, el 19 de noviembre a las 14:59 me escribiste: > Jonathan M Davis Wrote: > > > On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > > > Jonathan M Davis Wrote: > > > > In particular, needing to pass LineInfo() to assertExcThrown!() to know > > > > the file and line number was disliked (though it was by far the best > > > > solution that I'd been able to come up with). > > > > > > Not sure if this helps, but if you default-initialize template function > > > parameters with __LINE__ and __FILE__ they get the line and file of where > > > the template was instantiated. > > > > Yes. The problem was that the function was a _variadic_ template. So, you > > couldn't have default arguments. > > This should work: > > void func(string x = __FILE__, T...)(T args); > > D allows defaulted template arguments to occur before non-defaulted ones. And what is func!("blah")(); is supposed to do, make x = "blah"? args[0] = "blah"? both? (I don't have a compiler at hand to try it =P) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- He used to do surgery On girls in the eighties But gravity always wins
Re: Looking for champion - std.lang.d.lex
On 22/10/2010 20:48, Andrei Alexandrescu wrote: On 10/22/10 14:02 CDT, Tomek Sowiński wrote: Dnia 22-10-2010 o 00:01:21 Walter Bright napisał(a): As we all know, tool support is important for D's success. Making tools easier to build will help with that. To that end, I think we need a lexer for the standard library - std.lang.d.lex. It would be helpful in writing color syntax highlighting filters, pretty printers, repl, doc generators, static analyzers, and even D compilers. It should: 1. support a range interface for its input, and a range interface for its output 2. optionally not generate lexical errors, but just try to recover and continue 3. optionally return comments and ddoc comments as tokens 4. the tokens should be a value type, not a reference type 5. generally follow along with the C++ one so that they can be maintained in tandem It can also serve as the basis for creating a javascript implementation that can be embedded into web pages for syntax highlighting, and eventually an std.lang.d.parse. Anyone want to own this? Interesting idea. Here's another: D will soon need bindings for CORBA, Thrift, etc, so lexers will have to be written all over to grok interface files. Perhaps a generic tokenizer which can be parametrized with a lexical grammar would bring more ROI, I got a hunch D's templates are strong enough to pull this off without any source code generation ala JavaCC. The books I read on compilers say tokenization is a solved problem, so the theory part on what a good abstraction should be is done. What you think? Yes. IMHO writing a D tokenizer is a wasted effort. We need a tokenizer generator. Agreed, of all the things desired for D, a D tokenizer would rank pretty low I think. Another thing, even though a tokenizer generator would be much more desirable, I wonder if it is wise to have that in the standard library? It does not seem to be of wide enough interest to be in a standard library. (Out of curiosity, how many languages have such a thing in their standard library?) -- Bruno Medeiros - Software Engineer
Re: std.algorithm.remove and principle of least astonishment
On 16/10/2010 20:51, Andrei Alexandrescu wrote: On 10/16/2010 01:39 PM, Steven Schveighoffer wrote: I suggest wrapping a char[] or wchar[] (of all constancies) with a special range that imposes the restrictions. I did so. It was called byDchar and it would accept a string type. It sucked. char[] and wchar[] are special. They embed their UTF affiliation in their type. I don't think we should make a wash of all that by handling them as arrays. They are not arrays. Andrei "They are not arrays."? So why are they arrays then? :3 Sorry, what I mean is: so we agree that char[] and wchar[] are special. Unlike *all other arrays*, there are restrictions to what you can assign to each element of the array. So conceptually they are not arrays, but in the type system they are very much arrays. (or described alternatively: implemented with arrays). Isn't this a clear sign that what currently is char[] and wchar[] (= UTF-8 and UTF-16 encoded strings) should not be arrays, but instead a struct which would correctly represents the semantics and contracts of char[] and wchar[]? Let me clarify what I'm suggesting: * char[] and wchar[] would be just arrays of char's and wchar's, completely orthogonal with other arrays types, no restrictions on assignment, no further contracts. * UTF-8 and UTF-16 encoded strings would have their own struct-based type, lets called them string and wstring, which would likely use char[] and wchar[] as the contents (but these fields would be internal), and have whatever methods be appropriate, including opIndex. * string literals would be of type string and wstring, not char[] and wchar[]. * for consistency, probably this would be true for UTF-32 as well: we would have a dstring, with dchar[] as the contents. Problem solved. You're welcome. (as John Hodgeman would say) No? -- Bruno Medeiros - Software Engineer
Re: duck!
On 11/11/2010 15:22, Andrei Alexandrescu wrote: On 11/11/10 6:30 AM, Bruno Medeiros wrote: On 17/10/2010 20:11, Andrei Alexandrescu wrote: On 10/17/2010 01:09 PM, Jeff Nowakowski wrote: On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote: It's a subset of duck typing. I don't think calling a function that supports a limited form of duck typing "duck" is a lie. I'm sure if it was on a Go slide you would. Probably not in as strong terms, but if you want to point out that I'm biased... what can I do? I'm a simple man. Andrei When I first heard you say you were biased (in the Google Talk), I thought you were being facetious, or just exaggerating. I'm not so sure anymore, and I hope that is not the case. Because, as I'm sure you must realize, being biased for D will only result in an outcome of mild to severe annoyance and loss of credibility from: * people biased for languages which are perceived to be competitors to D (like Go). * people who are (or strive to be) unbiased. And given who you are (one of the designers of D), this outcome will apply not just to yourself, but D as well, which obviously is not a good thing. I think I ascribe a milder meaning than you to "bias". It's in human nature to have preferences, and it's self-evident that I'm biased in favor of various facets of D's approach to computing. A completely unbiased person would have a hard time working on anything creative. Andrei I don't think the bias above is just a case of preferences of one thing over the other. Having preferences is perfectly fine, as in "I prefer this approach", or even "I think this approach is more effective than that one". Another thing is to describe reality in inaccurate terms ("I think approach A has property Z", when it doesn't), and/or to have a double standard when describing or analyzing something else. -- Bruno Medeiros - Software Engineer
Re: Review: A new stab at a potential std.unittests
On Friday 19 November 2010 11:59:18 Sean Kelly wrote: > Jonathan M Davis Wrote: > > On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > > > Jonathan M Davis Wrote: > > > > In particular, needing to pass LineInfo() to assertExcThrown!() to > > > > know the file and line number was disliked (though it was by far the > > > > best solution that I'd been able to come up with). > > > > > > Not sure if this helps, but if you default-initialize template function > > > parameters with __LINE__ and __FILE__ they get the line and file of > > > where the template was instantiated. > > > > Yes. The problem was that the function was a _variadic_ template. So, you > > couldn't have default arguments. > > This should work: > > void func(string x = __FILE__, T...)(T args); > > D allows defaulted template arguments to occur before non-defaulted ones. If so, then I obviously assumed that that wouldn't work. You certainly can't do that with the function arguments. I think that the new solution is still better though, because it allows you to write the function call like you normally would. You just have to put it in string form. That, and there were problems with passing the function as an alias. Still, it's definitely good to know that you can have default template arguments before non-defaulted ones. Thanks. - Jonathan M Davis
Re: Review: A new stab at a potential std.unittests
Jonathan M Davis Wrote: > On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > > Jonathan M Davis Wrote: > > > In particular, needing to pass LineInfo() to assertExcThrown!() to know > > > the file and line number was disliked (though it was by far the best > > > solution that I'd been able to come up with). > > > > Not sure if this helps, but if you default-initialize template function > > parameters with __LINE__ and __FILE__ they get the line and file of where > > the template was instantiated. > > Yes. The problem was that the function was a _variadic_ template. So, you > couldn't have default arguments. This should work: void func(string x = __FILE__, T...)(T args); D allows defaulted template arguments to occur before non-defaulted ones.
Re: Review: A new stab at a potential std.unittests
On Friday, November 19, 2010 11:37:16 Sean Kelly wrote: > Jonathan M Davis Wrote: > > In particular, needing to pass LineInfo() to assertExcThrown!() to know > > the file and line number was disliked (though it was by far the best > > solution that I'd been able to come up with). > > Not sure if this helps, but if you default-initialize template function > parameters with __LINE__ and __FILE__ they get the line and file of where > the template was instantiated. Yes. The problem was that the function was a _variadic_ template. So, you couldn't have default arguments. LineInfo had default arguments in its opCall() which were the file and line number, so you passed LineInfo() as the first argument to the function, thereby not having to pass __FILE__ and __LINE__, but ideally, they would be default arguments of the original function as you suggest. It's just that the variadic part got in the way. The new version is neither variadic (since whole call is a single string rather than passing the function name and arguments separately), and it doesn't even need the __FILE__ and __LINE__ number as default arguments, since they're just used directly in the string that's mixed in. - Jonathan M Davis
Re: Review: A new stab at a potential std.unittests
Jonathan M Davis Wrote: > > In particular, needing to pass LineInfo() to assertExcThrown!() to know the > file > and line number was disliked (though it was by far the best solution that I'd > been able to come up with). Not sure if this helps, but if you default-initialize template function parameters with __LINE__ and __FILE__ they get the line and file of where the template was instantiated.
Re: DIP9 -- Redo toString API
On Friday, November 19, 2010 10:26:40 Steven Schveighoffer wrote: > On Fri, 19 Nov 2010 12:51:29 -0500, Jonathan M Davis > > wrote: > > On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote: > >> On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer > >> > >> wrote: > >> > I just created a new D Improvement Proposal to fix the toString > >> > >> problem > >> > >> > I brought up several posts ago. > >> > > >> > See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 > >> > >> I've made suggested changes, please review again. > >> > >> Thanks > > > > The difference between the text and the function signature still exists > > (the text > > says that sink is const scope whereas the signature just says scope), > > Maybe you are confusing sink with sink's parameter, which is marked 'in'? > I reworded the text to make it clearer. The way I read it was that the delegate was supposed to be scope const, so if that's not the case, the original text wasn't clear enough, bu it's definitely clearer now. - Jonathan M Davis
Re: DIP9 -- Redo toString API
On Fri, 19 Nov 2010 12:51:29 -0500, Jonathan M Davis wrote: On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote: On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote: > I just created a new D Improvement Proposal to fix the toString problem > I brought up several posts ago. > > See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I've made suggested changes, please review again. Thanks The difference between the text and the function signature still exists (the text says that sink is const scope whereas the signature just says scope), Maybe you are confusing sink with sink's parameter, which is marked 'in'? I reworded the text to make it clearer. -Steve
Review: A new stab at a potential std.unittests
Updated code: http://is.gd/hqPb2 Okay. As mentioned before, I have helper unit test functions which I use heavily in std.datetime and which are pretty much going to have to either end up as private helper functions in std.datetime or actually get added in a separate module for everyone to use (I'd prefer the latter). My last post on it seems to have met with positive feedback overall for the basic idea but not necessarily the execution. In particular, needing to pass LineInfo() to assertExcThrown!() to know the file and line number was disliked (though it was by far the best solution that I'd been able to come up with). Overall, it's worked quite well, but periodically (for reasons that I _still_ don't understand) passing the function as an alias didn't work properly (sometimes the template constraint which checked that calling the function - exactly how it was called in the code - compiled failed, whereas the template would compile if the constraint was removed, which makes no sense at all to me). So, there were enough problems in using it and enough dislike for how it worked, that I mucked around with it a bit to find a better way to do it, and I believe that I've found one. You end up passing the entire function call as a string (preferably a WYSIWYG string). So, instead of assertExcThrown!(Exception, myfunc)(LineInfo(), param1, param2); you get the much shorter and cleaner mixin(assertExcThrown!(Exception, `myfunc(param1, param2)`)); It mixes the whole thing in on that one line, so it doesn't affect the line count and the call is actually done at the local scope, so it's exactly as if you'd written the function call directly in the function (since that's how it gets compiled in). It also manages to deal with __FILE__ and __LINE__ internally this way without even needing to pass them as default parameters. The one downside is that - being a string mixin - it does come with higher compilation overhead. But that should improve as the compiler improves ( http://d.puremagic.com/issues/show_bug.cgi?id=1382 is likely the main culprit). The list of functions is unchanged, but a few of them became eponymous templates to be mixed in as strings rather than being templated function calls. It is bit annoying to have to use mixin to do it, but the result is much cleaner on the whole, I believe. So, it's a huge useability change. In any case, I'm presenting the updated for your review, so tell me what you think. - Jonathan M Davis P.S. My most recent update of std.datetime doesn't use the updated unit test functions yet, so the only examples of how to use them are in the docs and source of my unittest module - both of which are included in the link above. I'll likely post a version of std.datetime with the updated unit tests later today, so if you really want to see the functions used on a larger scale, you can check that out then.
Re: DMD Automatic Dependency Linking
On 10-11-16 12:04 PM, Matthias Pleh wrote: Am 16.11.2010 18:38, schrieb Travis: The one thing I have been wondering however is why doesn't DMD have a flag for easy project building which compiles dependencies in a single command. [...] Thanks, tbone Have you tried 'rdmd' ? Son of a bitch, I didn't realize rdmd did the dependencies as well. Previously I have only used rdmd for D 'scripts' and unittesting. I have done some testing with it using derelict (with some modifications to work with D2) and gtkd and it works perfectly (slow for gtkd, but gtkd is kinda slow to compile anyway). I'll start using rdmd and suggest it to others. Thanks!
Re: DIP9 -- Redo toString API
Steven Schveighoffer Wrote: > On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer > wrote: > > I just created a new D Improvement Proposal to fix the toString > > problem I brought up several posts ago. > > See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 > I've made suggested changes, please review again. I like this design. Thanks for proposing it. Cheers, Pillsy
Re: DIP9 -- Redo toString API
On Friday, November 19, 2010 05:54:15 Steven Schveighoffer wrote: > On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer > > wrote: > > I just created a new D Improvement Proposal to fix the toString problem > > I brought up several posts ago. > > > > See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 > > I've made suggested changes, please review again. > > Thanks The difference between the text and the function signature still exists (the text says that sink is const scope whereas the signature just says scope), though now the example (which I don't think was there before) is another place where just scope is used, so if the text is right and the actual function signature is wrong (as opposed to the other way around), then there are two places that need to be fixed. - Jonathan M Davis
Re: Shared pain
Steve Teale: > I admire your dedication to language theory and purity, but there are > many who'd translate that to impracticality and obscurity. I like that idea about immutables & strong pure functions, but it was not an idea of mine :-) That enhancement request in Bugzilla is not written by me. > I came to D in the first place because I found it refreshingly clear and > easy to use after C++ and Java. But now it's getting painful. But strongly pure functions are already present in D. So it's morally good to push its usages and implications as far as possible, otherwise we are wasting possibilities. That implicit cast idea is another implication of purity. It's a clean thing, it's not a hack or workaround or a dangerous thing or something like that, it comes from a clean & logical reasoning about consequences of purity. So it can't be compared to many other dirty things present in D2. It actually helps to clean the programs a little, because removes the need for one important use case of casts. So I can't agree. There is a large complexity difference between extending the logical implications of an already present feature, and adding a true special case. > What's your estimate of how long it will be before D is a stable language? I have no idea, I am not that expert, and probably no one knows. D is developed by a small group of devs, and despite in life you seem to "need" to be fast everything you do (for example because otherwise others do it before you and you miss the train), D is not a commercial project, so it has less timing pressures. Often commercial software projects produce a worse result, despite having more resources, because of the strict development timing requirements. If you look at the PyPy Python project it's may years out of schedule, it was started by lot of money coming from European Union, but in the end it may deliver something good any way. Open Source projects too need to respect some timing schedules, but in OS you are sometimes able to say "it will be done when it will be done," while in most commercial software projects you can't say that. The "feature" we are describing here probably needs only few lines of code to be implemented in the compiler (but I can't be sure) and it's backward-compatible (because it removes the need of a cast in some cases), so it's a kind of additive change. Bye, bearophile
Re: Shared pain
On 19-nov-10, at 17:42, Steve Teale wrote: On Fri, 19 Nov 2010 11:23:44 -0500, bearophile wrote: Regarding the creation of immutable data structures, there is a proposal that is probably able to remove some of the pain: the result of strongly pure functions may become implicitly castable to immutable. Bye, bearophile BP, I admire your dedication to language theory and purity, but there are many who'd translate that to impracticality and obscurity. I came to D in the first place because I found it refreshingly clear and easy to use after C++ and Java. But now it's getting painful. I've bailed out several times, just keep coming back to see how it is doing. I have a bunch of code that worked with D1 and D2 at one time. I've given up on D1, since it is now obviously legacy, but even without the complexity of supporting both, It's been real hard this visit to get things working again. What's your estimate of how long it will be before D is a stable language? well D1 is pretty stable I think, if you are interested in stability that is a good choice, has worked well for me. This does not mean that I will not consider D2, but D1 is my main workhorse. Fwzi Thanks Steve
Re: Shared pain
On Fri, 19 Nov 2010 11:23:44 -0500, bearophile wrote: > Regarding the creation of immutable data structures, there is a proposal > that is probably able to remove some of the pain: the result of strongly > pure functions may become implicitly castable to immutable. > > Bye, > bearophile BP, I admire your dedication to language theory and purity, but there are many who'd translate that to impracticality and obscurity. I came to D in the first place because I found it refreshingly clear and easy to use after C++ and Java. But now it's getting painful. I've bailed out several times, just keep coming back to see how it is doing. I have a bunch of code that worked with D1 and D2 at one time. I've given up on D1, since it is now obviously legacy, but even without the complexity of supporting both, It's been real hard this visit to get things working again. What's your estimate of how long it will be before D is a stable language? Thanks Steve
Re: windows debug [Shared pain]
19.11.2010 19:08, Steve Teale пишет: On Fri, 19 Nov 2010 16:58:26 +0300, Stanislav Blinov wrote: Have you tried OutputDebugString()? It's WinAPI function that sends strings to the 'debugger'. DebugView application from SysInternals suite nicely prints those strings, and also times them. How is this better than the event log. It only takes one line of code, but it's still a pain in the arse. It's better precisely in that it doesn't need event log. Cluttering system log with debug messages is not a thing I personally like :) In any case, if it's a service, where does it output the debug string to? It's not a console output. That function generates special Windows debug event that can be captured by external application (i.e. debugger, but not necessarily). It is very useful with things like services when console is not available and you don't feel like creating log file. SysInternals suite has a DebugView application that captures these debug strings from currently running processes and displays them as a kind of log: they are numbered and timed (see attached screenshot). <>
Re: Shared pain
Steve Teale: > Languages can't be designed just on theory - some recognition of > practicality is also required. In the case of creation of immutable data structures it looks the opposite to me: DMD is too much pragmatic and there isn't enough theory behind it :-) > But design limitations like that will force programmers who are on a > tight schedule to just say __gshared, and to hell with it. Regarding the creation of immutable data structures, there is a proposal that is probably able to remove some of the pain: the result of strongly pure functions may become implicitly castable to immutable. Bye, bearophile
Re: windows debug [Shared pain]
On Fri, 19 Nov 2010 16:58:26 +0300, Stanislav Blinov wrote: > Have you tried OutputDebugString()? It's WinAPI function that sends > strings to the 'debugger'. DebugView application from SysInternals suite > nicely prints those strings, and also times them. How is this better than the event log. It only takes one line of code, but it's still a pain in the arse. In any case, if it's a service, where does it output the debug string to? Thanks for you suggestion Stanislav, but I'm pretty much worked through it by now - albeit somewhat pissed off ;=) Steve
Re: Shared pain
On Fri, 19 Nov 2010 08:25:17 -0500, Jason House wrote: > A cast to immutable is required when constructing immutable objects. The > type system can't prove that's safe. It's a design limitation to keep > complexity low. > Jason, But design limitations like that will force programmers who are on a tight schedule to just say __gshared, and to hell with it. Languages can't be designed just on theory - some recognition of practicality is also required. As to the thread - I don't think that is under my control. I believe the Windows service dispatcher does its own thing. Thanks for taking the trouble Steve
Faster uniform() in [0.0 - 1.0(
Some kind of little D programs I write need a lot of random values, and tests have shown me that std.random.uniform is slow. So I have suggested to add a faster special case to generate a random double in [0.0, 1.0), see: http://d.puremagic.com/issues/show_bug.cgi?id=5240 Bye, bearophile
Re: DIP9 -- Redo toString API
On Fri, 19 Nov 2010 09:30:11 -0500, bearophile wrote: Steven Schveighoffer: Who said setting an array to null is bad practice? I disagree. null is a better way to represent it, because it sets both the ptr and the length to 0, while "" only sets the length to 0. char[] arr = ""; assert(arr == null); // passes assert(arr is null); // fails I see, I didn't know this. BTW, the default value is not part of the function signature, if you want to in your code use = "", as long as you do the comparison correct, it should be valid. -Steve
Re: DIP9 -- Redo toString API
Steven Schveighoffer: > Who said setting an array to null is bad practice? I disagree. null is a > better way to represent it, because it sets both the ptr and the length to > 0, while "" only sets the length to 0. > > char[] arr = ""; > > assert(arr == null); // passes > assert(arr is null); // fails I see, I didn't know this. Bye, bearophile
Re: DIP9 -- Redo toString API
On Fri, 19 Nov 2010 09:14:07 -0500, bearophile wrote: Steven Schveighoffer: I've made suggested changes, please review again. Good, thank you. Just a note: a DIP is a public document so it's better to encourage good idioms inside it. "null" to represent empty arrays/strings is a bad practice, so instead of this: void writeTo(scope delegate(in char[] data) sink, string format = null) const { formattedWrite(sink, "(%s, %s)", first, second); } I suggest you to write something like: void writeTo(scope delegate(in char[] data) sink, string format="") const { formattedWrite(sink, "(%s, %s)", first, second); } Who said setting an array to null is bad practice? I disagree. null is a better way to represent it, because it sets both the ptr and the length to 0, while "" only sets the length to 0. char[] arr = ""; assert(arr == null); // passes assert(arr is null); // fails I'd rather use a value that also allows code like: if(format is null) { // default to decimal format = "d"; } -Steve
Re: DIP9 -- Redo toString API
Steven Schveighoffer: > I've made suggested changes, please review again. Good, thank you. Just a note: a DIP is a public document so it's better to encourage good idioms inside it. "null" to represent empty arrays/strings is a bad practice, so instead of this: void writeTo(scope delegate(in char[] data) sink, string format = null) const { formattedWrite(sink, "(%s, %s)", first, second); } I suggest you to write something like: void writeTo(scope delegate(in char[] data) sink, string format="") const { formattedWrite(sink, "(%s, %s)", first, second); } More info about it: http://d.puremagic.com/issues/show_bug.cgi?id=3889 Bye, bearophile
windows debug [Shared pain]
18.11.2010 21:53, Steve Teale пишет: As you can imagine, this is terrible to debug - printf or similar is bad enough, but for the service I'm pushing entries into the Windows event logger system. [...] But first I think I'll stop and do some carpentry for a couple of days. Then eventually something might dawn on me. Have you tried OutputDebugString()? It's WinAPI function that sends strings to the 'debugger'. DebugView application from SysInternals suite nicely prints those strings, and also times them.
Re: DIP9 -- Redo toString API
On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I've made suggested changes, please review again. Thanks -Steve
Re: Shared pain
A cast to immutable is required when constructing immutable objects. The type system can't prove that's safe. It's a design limitation to keep complexity low. http://www.digitalmars.com/d/2.0/phobos/std_regexp.html Looking at the Regexp docs, find isn't marked const or pure. If that's an oversite, file it in bugzilla. If it can't be const, then you should find another approach. When this stuff crashes for you, is it accessing a different thread's TLS or is it simply unable to handle TLS at all? Steve Teale Wrote: > On Thu, 18 Nov 2010 11:26:39 +, Steve Teale wrote: > > > I had D code that provided a basis for creation of Windows services, > > which I have just tried to get working with the latest D2. > > > > No dice. > > > I have made some progress in understanding this. It appears that any D > static data structures containing function pointers will now cause a > Windows service to crash. > > For happiness, these must be forced into the global data segment. > > I have demonstrated this within a vestigial service for a couple of cases > - plain old struct containing an int and a function pointer, and for > Regexp objects by using and not using __gshared on the offending objects. > > Now that I'm reasonably sure what's happening, I ought to be able to make > these things work by making such static members immutable, and > initializing them in static this(). > > However, I then run into a slew of complier errors. Lets start with this > simple framework: > > import std.stdio; > import std.regexp; > > class ThingWithStatic > { >static RegExp rex; >string ns; > >static this() >{ > rex = RegExp("ab+a"); >} > >this() >{ > ns = "abbaabba"; >} > >int getFromStatic() { return rex.find(ns); } > } > > void main() > { >ThingWithStatic tws = new ThingWithStatic(); >writefln("%d", tws.getFromStatic()); > } > > This compiles fine, but if I include this class in a service, and call > getFromStatic(), the service will crash. If I change to: > > __gshared RegExp rex; > > It compiles fine, and the service does not crash. > > If I change to: > >static immutable RegExp rex; > > Then I get errors: > > triv.d(11): Error: cannot implicitly convert expression (opCall("ab > +a",null)) of type std.regexp.RegExp to immutable(RegExp) > triv.d(19): Error: function std.regexp.RegExp.find (string string) is not > callable using argument types (string) immutable > st...@ubuntu:~/scratch$ > > So then I use a cast: > > rex = cast(immutable(RegExp)) RegExp("ab+a"); > > and get down to: > > triv.d(19): Error: function std.regexp.RegExp.find (string string) is not > callable using argument types (string) immutable > > as somewhat wierd message in itself. So I use a cast in the call to find > (): > > return (cast(RegExp) rex).find(ns); > > At this point it compiles, and if it's used in the service, the service > does not crash. > > BUT - all these complicated casts will be extremely tedious to > administer to code that uses RexExp methods all over the place, so > __gshared is a great temptation. The compiler should try to eliminate > such temptations in the interests of safety. > > Also why are these casts necessary. If I am assigning to something that > is the same type and was declared as immutable should not at least the > first cast be done implicitly. In the second case, I'm using a Regexp > object, wherever it may be stored, so why the cast? If find was pure > would the cast still be required? > > Thanks > Steve
Re: Shared pain
On Fri, 19 Nov 2010 01:49:30 -0500, Steve Teale wrote: As I said before, I don't know if the thread being created by the windows service procedure is properly initializing the D modules of the library/runtime. Try as the first line of ServiceMain to initialize the current thread: auto mythread = thread_attachThis(); see http://www.digitalmars.com/d/2.0/phobos/core_thread.html -Steve Steve, I don't think it gets as far as ServiceMain. Anyway, I tried it there, and at the point just before the first WINAPI call, but it still crashes. I can fix it, by making my statically initialized RegExp objects __gshared or immutable, but the latter involves inserting a slew of tedious casts into my XML parser, since RexExp calls are used all over the place. See my separate post for my thoughts on that. OK, I'm out of ideas, sorry :( It certainly looks like there is an issue with TLS. I wouldn't suggest band-aiding things how you are doing, because some modules in phobos/druntime use TLS also. It's reasonable to assume that if your uses of TLS are failing, those may fail as well. -Steve
Re: D1 -> D2
On Fri, 19 Nov 2010 01:47:27 -0500, Fawzi Mohamed wrote: From the discussion it seems that defining something like: version(D_Version2){ template Const(T){ alias const(T) Const; } template Immutable(T){ alias immutable(T) Immutable; } immutable(T) Idup(T)(T val){ return val.idup; } alias const(char)[] cstring; } else { template Const(T){ alias T Const; } template Immutable(T){ alias T Immutable; } T Idup(T)(T val){ return val.dup; } alias char[] string; alias char[] cstring; } could help a lot later one can simply replace Const! with const and Immutable! with immutable, Idup replacement is more complicated, but doable What is not so clear is how to cope with scope, because I have lot of delegates around that will need it. For it a preprocessing step might really be the best thing, or someone knows a smart way to cope with that? BTW, this doesn't work as well as you would think. The problem is with IFTI. For example, IFTI can handle this: void foo(T)(const(T) arg) but cannot handle this: void foo(T)(Const!(T) arg) It was one of the things we were trying to do in Tango for D2, we had aliases for const/immutable/mutable strings templated on character type, but all of Tango's IFTI usage failed to compile. It's a really old bug I filed: http://d.puremagic.com/issues/show_bug.cgi?id=1653 which was superseded by: http://d.puremagic.com/issues/show_bug.cgi?id=1807 -Steve
Re: DIP9 -- Redo toString API
On Fri, 19 Nov 2010 02:27:07 -0500, Lars T. Kyllingstad wrote: On Thu, 18 Nov 2010 17:21:20 -0500, Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I think it's best to leave out the '%' from the format string, like Don has done with BigInt. This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than writeTo/ toString. Example: writefln("%2$s, %1$s!", "World", "Hello"); It's not clear from the DIP whether this is what you intended, so I think it should be specified. Yes, I was not clear on what is passed in via format specifier. It should be more clear, will fix. Other than that, I think this proposal looks solid. What's cool about this, apart from the performance benefits, is that it allows custom format specifiers to be used in a seamless manner. It would be even more powerful with Tango-like format specifiers, i.e. "{...}", but I guess that ship sailed a long time ago. ("%{...}s" could be an alternative, though.) I think it leaves room for improvement, all that is necessary is to change the grammar for format specifiers to allow some kind of bracketing, and then we can have as much custom specifier as necessary. I didn't want to pretend I was good at tweaking format grammar specs, so I left it out :) All I said was that the format specifiers should follow the rules for standard format specifiers. -Steve
Re: DIP9 -- Redo toString API
On Thu, 18 Nov 2010 17:43:51 -0500, bearophile wrote: Steven Schveighoffer: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. Thank you for writing the DIP. It looks interesting. I suggest to add an example, the implementation of toString() and writeTo() for a simple struct like this (or a class), so it's easy to compare them (code untested): struct Pair(T1, T2) { T1 first; T2 second; string toString() { return format("Pair(%s, %s)", first, second); } void writeTo(scope void delegate(in char[] data) sink, string format="") const { // code here... } } Will do. -Steve
Re: The D Scripting Language
spir Wrote: > On Tue, 16 Nov 2010 09:44:06 +0100 > Per à ngström wrote: > > > On 2010-11-16 01:10, Daniel Murphy wrote: > > > I think allowing the second expression in the ternary operator to be > > > omitted > > > would be a better fit for D, and provide the same function. > > > > > > ie. > > > auto x = a ? a : b; > > > auto x = a ? : b; > > > > Personally I had '|||' in mind, but I'm OK with '?:'. I think it should > > be one single token and not an extension of the tertiary operator, though: > > > > auto x = condition ? a : b; // tertiary operator > > auto x = condition ? : b; // error, did you forget the middle operand? > > auto x = a ?: b; // OK > > Yes, then it becomes a binary operator :-) Read "a if defined, else b". > > > Denis > -- -- -- -- -- -- -- > vit esse estrany ⣠> > spir.wikidot.com > They now added Scala to scriptometer http://rigaux.org/language-study/scripting-language/ it sees abomination i/o classes don't stop it being better script language then d. What can do? Scala bad competition and straight better. Next release has std.script?
Re: DIP9 -- Redo toString API
On Thu, 18 Nov 2010 20:18:19 -0500, Jonathan M Davis wrote: On Thursday, November 18, 2010 14:21:20 Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 Looks good overall, but I would point out that the text claims that sink is const scope - i.e. in - but the signature that's given is only scope. I assume that you intended to make the signature use in (or an explicit const scope) instead? I looked at it again, I see 'in' there, is there something I'm missing? Reiterating here: void writeTo(scope void delegate(>>> in <<< char[] data) sink, string format = null) const -Steve
Re: datetime review part 2 [Update 5]
On 19.11.2010 15:00, Lars T. Kyllingstad wrote: On Fri, 19 Nov 2010 14:56:30 +0300, Dmitry Olshansky wrote: On 19.11.2010 8:10, Jonathan M Davis wrote: Most Recent: http://is.gd/hovyR Other than some minor documentation changes, all of the changes are to the implementation rather than the API, though those changes are fairly minimal as well (albeit important). I fixed it so that the stopwatch code uses a monotonic clock on both Windows and Linux (at least, it will once clock_gettime() is fully in druntime rather than commented out) and so that getting the current time doesn't use a monotonic clock (before Linux was using a normal or real time clock for both whereas Windows was using a monotonic clock for both). I also consolidated some of the code in static ifs to minimize code duplication. As a reminder, if you want to use the code on Windows, you need to link with advapi32.lib. - Jonathan M Davis Great! Have you found a way to deal with high redundancy in API docs? For instance in PosInfInterval (and in the others, most likely): template expand(D) if (__traits(compiles,begin + duration)) Expands the interval backwards in time. Effectively, it does begin -= duration. Parameters: durationThe duration to expand the interval by. dirThe direction in time to expand the interval. Examples: [snip] nothrow void expand(D duration); Expands the interval backwards in time. Effectively, it does begin -= duration. ...[exactly the same as above with examples ].. This appears to plague all the templated in such a way methods of all Interval structs. Also, as I said before, summary table with common methods won't hurt. In fact it would show the implicit interface - what TP provides, most Intervals provide. As to my suggested API changes, now I have a better plan for more generic and easy to use API wrt ranges, just need some time to experiment and write it down. I don't think there is much he can do about it, it's a bug in the compiler: http://d.puremagic.com/issues/show_bug.cgi?id=4107 -Lars Ouch, thanks for the explanation. -- Dmitry Olshansky
Re: D1 -> D2
On 19-nov-10, at 08:44, Walter Bright wrote: Fawzi Mohamed wrote: I don't find a valid D1 expression to put in place of scope, or to somehow hide it, i.e. how do you write something like module t; void f(scope void delegate() action){ action(); } void main(){ f(scope delegate(){ printf("bla\n"); }); } so that it is valid D1 and D2? Just remove the 'scope'. removing scope causes heap allocation in D2 that I want to avoid. Still maybe you are right, I will use /+scope+/, so that one has something working, and easily go to the efficient D2 version
Re: datetime review part 2 [Update 5]
On Fri, 19 Nov 2010 14:56:30 +0300, Dmitry Olshansky wrote: > On 19.11.2010 8:10, Jonathan M Davis wrote: >> Most Recent: http://is.gd/hovyR >> >> Other than some minor documentation changes, all of the changes are to >> the implementation rather than the API, though those changes are fairly >> minimal as well (albeit important). >> >> I fixed it so that the stopwatch code uses a monotonic clock on both >> Windows and Linux (at least, it will once clock_gettime() is fully in >> druntime rather than commented out) and so that getting the current >> time doesn't use a monotonic clock (before Linux was using a normal or >> real time clock for both whereas Windows was using a monotonic clock >> for both). I also consolidated some of the code in static ifs to >> minimize code duplication. >> >> As a reminder, if you want to use the code on Windows, you need to link >> with advapi32.lib. >> >> - Jonathan M Davis > Great! > Have you found a way to deal with high redundancy in API docs? For > instance in PosInfInterval (and in the others, most likely): > > template expand(D) if (__traits(compiles,begin + duration)) Expands the > interval backwards in time. Effectively, it does begin -= duration. > Parameters: > durationThe duration to expand the interval by. dirThe direction > in time to expand the interval. Examples: > [snip] > nothrow void expand(D duration); > Expands the interval backwards in time. Effectively, it does begin > -= duration. > ...[exactly the same as above with examples ].. > > This appears to plague all the templated in such a way methods of all > Interval structs. > > Also, as I said before, summary table with common methods won't hurt. > In fact it would show the implicit interface - what TP provides, most > Intervals provide. > > As to my suggested API changes, now I have a better plan for more > generic and easy to use API wrt ranges, just need some time to > experiment and write it down. I don't think there is much he can do about it, it's a bug in the compiler: http://d.puremagic.com/issues/show_bug.cgi?id=4107 -Lars
Re: datetime review part 2 [Update 5]
On 19.11.2010 8:10, Jonathan M Davis wrote: Most Recent: http://is.gd/hovyR Other than some minor documentation changes, all of the changes are to the implementation rather than the API, though those changes are fairly minimal as well (albeit important). I fixed it so that the stopwatch code uses a monotonic clock on both Windows and Linux (at least, it will once clock_gettime() is fully in druntime rather than commented out) and so that getting the current time doesn't use a monotonic clock (before Linux was using a normal or real time clock for both whereas Windows was using a monotonic clock for both). I also consolidated some of the code in static ifs to minimize code duplication. As a reminder, if you want to use the code on Windows, you need to link with advapi32.lib. - Jonathan M Davis Great! Have you found a way to deal with high redundancy in API docs? For instance in PosInfInterval (and in the others, most likely): template expand(D) if (__traits(compiles,begin + duration)) Expands the interval backwards in time. Effectively, it does begin -= duration. Parameters: durationThe duration to expand the interval by. dirThe direction in time to expand the interval. Examples: [snip] nothrow void expand(D duration); Expands the interval backwards in time. Effectively, it does begin -= duration. ...[exactly the same as above with examples ].. This appears to plague all the templated in such a way methods of all Interval structs. Also, as I said before, summary table with common methods won't hurt. In fact it would show the implicit interface - what TP provides, most Intervals provide. As to my suggested API changes, now I have a better plan for more generic and easy to use API wrt ranges, just need some time to experiment and write it down. -- Dmitry Olshansky
Re: DIP9 -- Redo toString API
On 19-nov-10, at 11:13, Lars T. Kyllingstad wrote: On Fri, 19 Nov 2010 10:22:29 +0100, Jacob Carlborg wrote: On 2010-11-18 23:21, Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 -Steve Why do we have to remove toString, can't toString call writeTo and behave as it does now? Nobody's forcing anyone to remove toString(), the point is that Phobos just won't be using it anymore. Furthermore, std.conv.to!string() should be defined to call writeTo(), so you won't have to define both toString() and writeTo() for your types. -Lars I think that it is a good, a breaking change, but good. having something like what I did with writeOut would minimize the hassles, because then you have a uniform way to print out a type: writeOut(sink,type,possiblyExtraArgs) that works for everything, basic types, old style objects with toString,... it is useful for generic code.
Re: DIP9 -- Redo toString API
On 19-nov-10, at 10:22, Jacob Carlborg wrote: On 2010-11-18 23:21, Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 -Steve Why do we have to remove toString, can't toString call writeTo and behave as it does now? that is what I do in blip. toString by default is char[] toString(){ return collectAppender(&desc); } I called the method desc because I saw it as description of the object. and if the object implements serialization then the description if just a serialization to json format (both of those are added by mixin printOut!();
Re: DIP9 -- Redo toString API
On Fri, 19 Nov 2010 10:22:29 +0100, Jacob Carlborg wrote: > On 2010-11-18 23:21, Steven Schveighoffer wrote: >> >> I just created a new D Improvement Proposal to fix the toString problem >> I brought up several posts ago. >> >> See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 >> >> -Steve > > Why do we have to remove toString, can't toString call writeTo and > behave as it does now? Nobody's forcing anyone to remove toString(), the point is that Phobos just won't be using it anymore. Furthermore, std.conv.to!string() should be defined to call writeTo(), so you won't have to define both toString() and writeTo() for your types. -Lars
Re: casting class pointer
Jesse Phillips wrote: auto hi = "hello" in b.all; auto foo = cast(B) hi; The result was that b.label wasn't the same, and printing out stuff resulted in a bunch of garbage. Not surprising. hi is pointing to a reference (pointer) to a B instance, not a proper B, and certainly not the one you hope for. Thus, random garbage from the memory surrounding the reference is outputted. The questions I have are, should casting a class pointer to a class change its behavior so it just gives you the class? Is is there a use case for the current behavior? And should I bother working to reproduce this? The idea behind the in operator for AAs is that it indicate whether there was something at the specified index, by returning null if there wasn't. IOW, 'a in AA' does not return a class reference, and shouldn't. You may have reasons to put nulls in your AA, in which case the returned B* may be non-null, while *hi is null. I have not thought of a good use case for this, though. However, the main reason I see is symmetry. Having to explain that for T[U] t, 'a in t' returns a T* is ok. Having to explain that this simple rule breaks when T is a class, is not good. Last, a cast is a message to the compiler of "Trust me, I know what I'm doing". That could mean that your B* is actually a B (a reference), that somehow ended up being a B*. In such a case, the only reasonable thing to do is interpreting the bits as a B instead of a B*. What you should do in the above code is auto foo = *hi; tl;dr: making the casting of class reference pointers to class references do the shortcut of interpreting the pointer as a reference is asymmetric and limits the language. -- Simen
Re: DIP9 -- Redo toString API
On 2010-11-18 23:21, Steven Schveighoffer wrote: I just created a new D Improvement Proposal to fix the toString problem I brought up several posts ago. See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 -Steve Why do we have to remove toString, can't toString call writeTo and behave as it does now? -- /Jacob Carlborg