Re: Windows API Translation
On Tue, 08 Feb 2011 09:52:24 +0200, Lars T. Kyllingstad public@kyllingen.nospamnet wrote: Wow, I didn't know this existed. I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? Currently, core.sys.windows.windows only contains a small subset of the Windows API. That would be great. I had to use Tango, Phobos (via Tangobos), these bindings and dwin in the same project once, and three of those four had their own definitions of the basic Win32 types. Not fun. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
map filter for AAs
Hello,
Is there map filter for AAs? Is it useful?
Below example,
Denis
struct Pair (K,V) { K k; V v; }
V2[K2] map (K1,V1, K2,V2) (V1[K1] aa1, Pair!(K2,V2) delegate (K1,V1) f) {
V2[K2] aa2;
Pair!(K2,V2) pair;
foreach (k,v ; aa1) {
pair = f(k,v);
aa2[pair.k] = pair.v;
}
return aa2;
}
V1[K1] filter (K1,V1) (V1[K1] aa1, bool delegate (K1,V1) f) {
V1[K1] aa2;
foreach (k,v ; aa1) {
if (f(k,v))
aa2[k] = v;
}
return aa2;
}
unittest {
char[uint] aa1 = [65:'a', 66:'b', 67:'c'];
// map
Pair!(char,uint) inversed (uint u,char c) { return Pair!(char,uint)(c,u); }
auto aa2 = map!(uint,char, char,uint)(aa1, inversed);
writefln(map inversed : [%s] -- [%s], aa1,aa2);
// filter
bool odd (uint u,char c) { return (u%2 == 1); }
auto aa3 = filter!(uint,char)(aa1, odd);
writefln(filter odd: [%s] -- [%s], aa1,aa3);
bool c (uint u,char c) { return (c == 'c'); }
auto aa4 = filter!(uint,char)(aa1, c);
writefln(filter c : [%s] -- [%s], aa1,aa4);
}
void main() {}
--
_
vita es estrany
spir.wikidot.com
Re: Another Phobos2 test
Adam Ruppe:
My implementation
http://arsdnet.net/tictactoe.d
Thank you for your answers and code. Your code is better.
This kind of indentations is interesting:
string positionString(int pos)
in {
assert(...);
}
out(ret) {
assert(...);
}
body {
// ...
}
I don't think it helps your case at all to use such horribly
awful code to make points. Half of your statements are the direct result of
the source code being garbage.
The original code was not mine, and I know it's bad code. That's why I have
suggested you to not work on it. I have used it just because it contains
several compact constructs used in Python. My next posts I'll use a different
strategy to explain things.
source: 138 lines, 2420 bytes
You can see the byte count is comparable to the python 2, but I have
more lines.
Replacing the tabs with spaces, as in the original Python and D versions, and
using Windows newlines, it becomes 3278 bytes.
I usually prefer Introduction to Programming style code than
functional code golf style, so you see that too.
Your code is not functional-style, it's procedural and contains some mutables.
My discussion was about improving Phobos things that are especially useful if
you write code in functional style.
Programs in ML-derived functional languages are often written in a more compact
style. This doesn't make them significantly more bug-prone because purity,
immutability, very strong type systems, and some other of their features avoid
many bugs.
I also put in a lot of contracts just because i can. I'm trying to
get into the habit of that.
Very good, I do the same.
That code was not production code, it was an experiment focused on showing some
possible improvements for Phobos. Adding contracts (and annotations as pure,
const, immutable), and several other things to the code was just a way to
distract the people that read that code from the purposes of the discussion.
D2 shows that there are three (or more) sizes of functional programming:
- Micro scale: when you use a line of code that uses array(map(filter())).
- Medium scale: when you use normal procedural code inside small
functions/methods, but the small functions are mostly pure and use mostly
const/immutable data.
- Large scale: when your functions are mostly procedural and sometimes use
mutable inputs too, but the main fluxes of data in your large application are
managed in a immutable/functional way (like from the DBMS, etc).
Large-scale functional programming is done in Java programs too, and it's not
much influenced by Phobos, it's a matter of how your very large program is
structured.
Medium-scale functional programming is well doable in D2 thanks to pure
annotations and transitive const/immutable.
So a question is how much micro-scale functional programming is
right/acceptable in a very little or very large D2 program. I don't have an
answer yet (probably the answer is: not too much). Some Scala programmers use
lot of micro-scale functional style (see some little examples here:
http://aperiodic.net/phil/scala/s-99/ ), but Scala allows to write that code
with a significantly less noisy syntax. What I am able to say is that currently
using a micro-scale functional programming style in D2 is awkward, there's too
much syntax noise, making the code not so readable and maintenable. But that
tictactoe code was an experiment, you need to perform some experiments, because
they reveal you new things.
In production code, in larger programs written in a mostly procedural language,
I usually write code more similar to yours, it's just better if you need to
maintain lot of code for years. In a more functional language I use a different
style, but I avoid golfing if the code needs to be used for a lot of time.
In script-like programs I sometimes use a little more compact style, but not as
compact as the original Python code. In such Python/D scripts I don't write
stuff like this:
string toString() {
string lineSeparator = -+-+-\n;
string row(int start) {
return format(%s|%s|%s\n,
positionString(start + 0),
positionString(start + 1),
positionString(start + 2));
}
string ret;
ret ~= row(0);
ret ~= lineSeparator;
ret ~= row(3);
ret ~= lineSeparator;
ret ~= row(6);
return ret;
}
Using what Python offers functional-style allows to write code about equally
safe. Too many lines of code require more time to be written (experiments have
shown that programmer tend to write approximately the same number of lines /
hour. This doesn't hold up to code golfing, of course). This style of writing
code is seen as bloated and Java-style by lot of people (by me too). This is
why Java programs are sometimes 10+ times longer than Python ones, I prefer
more compact Python code. On the other hand too much compact code gives
problems. So as usual in programming you need to find a balance (the
Re: map filter for AAs
spir: Is there map filter for AAs? Is it useful? Of course it's useful to map and filter on associative arrays. But I think a much better solution is to turn byValue() and byKey() into ranges, and add a byPair() range to AAs: http://d.puremagic.com/issues/show_bug.cgi?id=5466 Bye, bearophile
Re: std.unittests/exception Update and Vote
*Sigh* I was hoping for a clearer vote than this. assertThrown, assertNotThrown, and collectExceptionMsg are clearly in, but the vote on assertPred is not so clear. No --- Brad Roberts (I appeared to be against but didn't vote outright) David Nadlinger Don Jim? (I _think_ that he was voting no, but he didn't seem to think that he could vote) Michel Fortin SHOO Spir Yes --- Andrei Alexandrescu (at least he was until the most recent discussion on improving assert) Andrej Mitrovic Andrew Wiley Jens Mueller Lars T. Kyllingstad (from his comments, he appears to be in favor, but he never outright voted) Nick Sabalausky Tomek Sowiński (he definitely seems to be in favor but didn't vote outright) I _think_ that I got everyone, but most of the discussion on it has been how to improve it, not voting on whether it went in or not. In some cases, it's not entirely clear that someone actually voted even if their intent was clear. And there are definitely people who were involved in the discussion who never voted. I think that in the future, we need to try and separate the improvement discussions from the votes, with a specific, relatively short time frame (as in more like a week than a month) for votes - rather than having them spread throughout the discussion. I _tried_ to get people to vote at the end, but I guess that I wasn't clear enough or not enough people were paying attention. So, it's around a tie with regards to assertPred, with a definite lack of voting. We have not gotten a commitment that assert will be improved, and assertPred does more than assert could do even if it were improved (out of the 8 overloads of assertPred, assert could only replace two of them at best - albeit the most useful two). Don asked me to open an enhancement request for improving assert, which I still need to do, but it's not clear that it's actually going to happen, and at least some of the voting seems to be done with the idea that if we're going to get an improved assert, then there's no need for assertPred (which I'm not sure I agree with, but it could be debated). So, it's obvious from those who voted that there is no overwhelming vote in favor of adding assertPred to Phobos, but it's not exactly against either - though there are some people on both sides who are very strongly. We got a fairly ambigous vote IMHO. So, I don't know what that means we should do. Ideally, I'd prefer to have a second vote to make it clear, since so few people voted (and many of those who did weren't clear about it), and I had to scour older posts to find most of them. But it's not like we have formalized rules on all of this yet. Looking at the Boost page that Andrei gave previously ( http://www.boost.org/community/reviews.html ) does not make it all clear about what Boost does with regards to voting. - Jonathan M Davis
Re: Another Phobos2 test
== Quote from Adam Ruppe (destructiona...@gmail.com)'s article My implementation http://arsdnet.net/tictactoe.d after your permtion i post your code in http://rosettacode.org/wiki/Tic-tac-toe
Re: Another Phobos2 test
Hamad: == Quote from Adam Ruppe (destructiona...@gmail.com)'s article My implementation http://arsdnet.net/tictactoe.d after your permtion i post your code in http://rosettacode.org/wiki/Tic-tac-toe On Rosettacode they don't want too much long lines, so I suggest you to reduce indents to just 4 spaces, keeping lines under 75 chars. Bye, bearophile
Re: Windows API Translation
I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? They definitely need to be merged.
Re: Windows API Translation
HANDLE WINAPI FindFirstChangeNotification( __in LPCTSTR lpPathName, __in BOOL bWatchSubtree, __in DWORD dwNotifyFilter ); FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not.
Re: std.unittests/exception Update and Vote
On Tue, 08 Feb 2011 03:52:30 -0800, Jonathan M Davis wrote: *Sigh* I was hoping for a clearer vote than this. assertThrown, assertNotThrown, and collectExceptionMsg are clearly in, but the vote on assertPred is not so clear. No --- Brad Roberts (I appeared to be against but didn't vote outright) David Nadlinger Don Jim? (I _think_ that he was voting no, but he didn't seem to think that he could vote) Michel Fortin SHOO Spir Yes --- Andrei Alexandrescu (at least he was until the most recent discussion on improving assert) Andrej Mitrovic Andrew Wiley Jens Mueller Lars T. Kyllingstad (from his comments, he appears to be in favor, but he never outright voted) Sorry, forgot to place my vote. I am definitely in favour of adding assertThrown, assertNotThrown and collectExceptionMsg, but as of lately I'm on the fence regarding assertPred. If it turns out to be both possible and desirable to improve the messages produced by built-in assert, that may be better. I'd like to see how that plays out before placing a definitive vote. Also, if it turns out only the exception-related stuff goes into Phobos, maybe std.exception will be the best place to put it after all? -Lars
Re: Calling method by name.
On 2011-02-08 05:54, Robert Jacques wrote:
On Sat, 05 Feb 2011 13:14:42 -0500, Jacob Carlborg d...@me.com wrote:
On 2011-02-04 05:07, Jonathan M Davis wrote:
[snip]
Most of the good examples of runtime reflection that I'm aware of
require user-
defined attributes. But there are libraries in Java (and presumably
C#) that do
stuff like allow you to mark your classes with certain attributes
indicating what
type of XML elements that they should be, and then another library
which knows
_nothing_ about your classes is able to serialize them to and from
XML. Another
example would be Hibernate, which does the same sort of stuff only it
deals with
talking to databases. Full-on runtime reflection combined with
user-defined
attributes can do some powerful stuff. However, I do think that
runtime reflection
without user-defined attributes doesn't tend to be anywhere near as
useful. To
really get that sort of stuff working, we'd need D to properly
support both user-
defined attributes and runtime reflection. Both are future
possibilities but
obviously aren't happening any time soon.
- Jonathan M Davis
Ruby seems to get along without any kind of attributes/annotations.
But on the other hand you can call a method in a class declaration and
this will behave much the same as a attribute.
ActiveRecord in Rails is a good example of runtime reflection. Also
the Ruby XML library builder is a good example of runtime
reflection. Maybe not acutally runtime reflection but is uses the
method_missing method, equivalent to the opDispatch method in D,
heavily.
http://builder.rubyforge.org/
I'm still reading up on Ruby, but so far, there are two major difference
between serialization in Ruby and in D. First, Ruby isn't a systems
programming language with pointers/unions/etc, so serializing all
members of a class is generally okay in Ruby but isn't in D. This is the
major advantage of annotations: its a fast, simple way of declaring what
should and shouldn't be serialized. Second, Ruby's support for
serialization creates a back door around its variable protection
annotations (i.e. private,package,protected,public). Now, Ruby doesn't
actually have user defined annotations as far as I can tell, but methods
are always public and variables are always private. I don't believe that
a reflection system should bypass encapsulation. The advantage of
annotations is that they allow you to declare programmer intent and
possibly separate APIs (ala const(T)) for special purposes.
Ok, lets have a look at how a serialization annotation could look like in D:
class Foo
{
@NonSerialized int x = 3;
}
Now the same can be done in Ruby, without any special syntax, like this:
class Foo
@x = 3
non_serialized :x
end
In the Ruby example non_serialized would be a class/static method
which recives a symbol indicating what field to skip during
serialization. Actually since Ruby is a dynamically typed language I
don't have declare x.
What I'm trying to say is that Ruby doesn't need a special syntax for
annotations since you can in Ruby do all (most of) the things you can do
with annotations but with class methods instead.
In general, serialization breaks encapsulation, not just in Ruby. You
can break encapsulation in D as well using .tupleof and delegates to
methods.
Ruby just has a different attitude. It allows you to
* Call private methods using send
* Add/remove/change methods on existing classes
* Change variables declared as const
It's no like Java which holds your hand all the time. It's the same with
D, but in a different way. In D there's instead:
* Pointers
* Unions
* malloc/free/delete
--
/Jacob Carlborg
Re: std.unittests/exception Update and Vote
On Tue, 08 Feb 2011 06:52:30 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: *Sigh* I was hoping for a clearer vote than this. Sorry for the lack of voting/attention, I've had barely any time to work with D lately, and I haven't even looked at your lib. -Steve P.S. I'm f***ing sick of snow...
Re: basic incomplete NetBSD support
On Sun, Jan 30, 2011 at 09:23:50PM +0100, Thomas Klausner wrote: Since it looked like I would need D for a project, I started porting it to NetBSD. The project has been cancelled in the meantime, but I don't want my patches to be lost, so I offer them here for inclusion. Anyone interested? Thomas
Re: Another Phobos2 test
bearophile:
This kind of indentations is interesting:
I'm still trying to find something I like for this. Currently,
I see the contracts as part of the public interface, just like
the name, so I'm indenting them like I would if the argument list
ran too long.
void doSomethingBig(
int arg1,
int arg2)
{
}
(Sometimes I put the { on the same line as the ) but then I often
find it hard to see the difference between the arguments and local
variables.)
So, similarly, the in and out get indented. It would be messy to
shove them all on one line, but without the indent, it'd look
like it's all part of the body.
In such Python/D scripts I don't write stuff like this:
[snip toString ]
One practical reason for such separation is this (seen in Python
but D does it too):
s = [1,2,3]
print s[34], s[44]
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: list index out of range
Error messages give a line number... but if there's still several
points of similar failure on that one line, it doesn't help as much
as it could.
This leads me to write things like this sometimes too:
auto author =
stuff[data]
[0]
[from]
[name];
So if the data isn't what I expected, the line number in the error
message tells exactly what was missing. (This is also a good
example of why semicolons are a gift from God)
s = ((1,2), (3,4), (5,6))
print s[1]
(3, 4)
Ahhh, I wanted a child of it!
Now, I'm forced to do it on one monster line...
print s[1][3]
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: tuple index out of range
Gah, which one? I guess I'll use a temp variable...
Anyway, sometimes this can be fixed in the runtime by including
the data and the index as part of the exception, but not always
(what if you did [0][0]?). Putting them on separate lines is
an easy, reliably way to get more information out of the error.
I know, but I was suggesting something different, to turn the JSON
creation into some kind of Phobos library that you may call at
compile-time from normal D code. Then a compile-time JSON reader in
Phobos will allow to perform certain kinds of static introspection,
that later will be quite useful to create user-defined @annotations.
We could do that today with a combination of -X, -J, and a CTFE
JSON parser (it's possible that std.json would work today. I haven't
tried it specifically, but ctfe tends to surprise me with its
capabilities).
Of course, you'd have to run the compiler twice, but there's other
advantages to that too (like getting dependencies - my build tool
does this - and the first run is fast anyway.
I'm tempted to do it now just to prove we can... but I'm already
a bit loaded with stuff to do.
With new Tuple!()() you need to manually specify the types of all
the fields, while tuple() spares this need, but allocates on the
stack. A newTuple() function allows to do both, but I don't know
how much often it is needed.
Maybe a generic toHeap!(T) function would be good for this. It
takes an existing object and copies it to the heap if necessary.
return toHeap!(tuple(1, 2, 3));
However, it seems to me that most tuples are likely to be small
value types anyway. You had an int, char[]. When I use tuples, they
are usually small collections of ints and strings too.
Value types don't really need to be on the heap. You can just
return them and pass them to functions normally and it works fine.
What I'd like is a way to tell the type system that I am creating a
sequence of 8-bit chars, and not a string of chars.
Maybe try ubyte[]?
I know, but programming life is not orthogonal :-)
That's part of the reason I said it... I'm only half serious.
Though, on the other hand, I've used the ncurses library which does
this kind of thing. The number of function names is obscene, and
the benefit is quite small. I'm not convinced the parentheses are
a big deal. (Hell, I've done lisp before... and kinda liked it. :P)
I think to!int('1') == 1 is useful, but I am not sure if C-derived
programmers accept/like to!int to work differtly from cast(int) in
this case.
The way I see it is if you are working with single chars, it is
probably because you want to do some work with the char itself -
it's numeric value. Thus it fits the same general area as int.
Perhaps you want to just work with one length strings? str[0..1]
instead of str[0].
Please reply to this to vote to collectExceptionMsg in std.unittests
Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. Andrei
Please reply to this to vote to collectExceptionMsg in std.unittests
Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Andrei
std.unittests vote tally
Vote has closed last night at 23:59:59:99, but I accepted Lars' late vote. Thanks Jonathan for responding to comments and suggestions, and for a very dedicated attitude throughout. YES votes mean wholesale acceptance of the library. NO means either partial acceptance or no acceptance at all. We have eight NOs and even YESs. (In fairness I have changed my vote after Don committed to improve assert(), but forgot to submit it.) NO: SHOO (arguments: unittest code should be easy to read without prior knowledge) Don (arguments: assertPred is harder to read than assert, don't use if you don't like doesn't apply to Phobos, Phobos becomes difficult to read if we continue adopting clever functions, something that has any appearance of being complicated needs VERY strong justification. Voted yes for assertThrown and assertNotThrown. Asked for bugzilla enhancement requests to have assert obviate assertPred) Michel Fortin Brad Roberts David Nadlinger (yes for assertThrown, 50/50 for assertNotThrown and collectExceptionMsg, no for assertPred) spir (yes to assertThrown, abstain for assertNotThrown and collectExceptionMsg) Jim (reiterates that at best assert should be improved) Lars T. Kyllingstad (on the fence with assertPred) YES: Jens Mueller bearophile Andrej Mitrovic Nick Sabalausky Andrei Alexandrescu (contingent on reducing the size of examples) Masahiro Nakagawa (with a few notes) Andrew Wiley Reviewer Manager's decision: We have had an unexpected development: we can change assert() to obviate assertPred(), and Don all but promised he'll look into it. This means if we accept the library as it is, we'll look at a function on the brink of deprecation for the sake of a short-term benefit. Perhaps this is not the best course of action. So let's not put assertPred() for now in Phobos, though Jonathan is to be commended for his work which is leading to a vast improvement to a core facility. assertThrown seems to be liked by a vast majority - please add to std.exception at your earliest convenience. assertNotThrown and collectExceptionMsg are on the fence and it's unclear whether some NO voters want them as isolated functions. Let us take a one-week vote for each. I will create one thread for each. Thanks to everyone for participating, and special thanks to Jonathan! Andrei
Please reply to this to vote to assertNotThrown in std.unittests
Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Andrei
Please reply to this to vote to assertNotThrown in std.unittests
Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Vote closes on Feb 15. Andrei
Re: High performance XML parser
Tomek Sowiński wrote: I am now intensely accumulating information on how to go about creating a high-performance parser as it quickly became clear that my old one won't deliver. And if anything is clear is that memory is the key. One way is the slicing approach mentioned on this NG, notably used by RapidXML. I already contacted Marcin (the author) to ensure that using solutions inspired by his lib is OK with him; it is. But I don't think I'll go this way. One reason is, surprisingly, performance. RapidXML cannot start parsing until the entire document is loaded and ready as a random-access string. Then it's blazingly fast but the time for I/O has already elapsed. Besides, as Marcin himself said, we need a 100% W3C-compliant implementation and RapidXML isn't one. I think a much more fertile approach is to operate on a forward range, perhaps assuming bufferized input. That way I can start parsing as soon as the first buffer gets filled. Not to mention that the end result will use much less memory. Plenty of the XML data stream is indents, spaces, and markup -- there's no reason to copy all this into memory. To sum up, I belive memory and overlapping I/O latencies with parsing effort are pivotal. Please comment on this. Few years ago I needed to write my own parser in Delphi for my XMPP (Jabber) client and server. In XMPP you get socket-streamed XML document with xml elements as protocol messages (XMPP stanzas). The problem I had was no Delphi parser had hybrid support of SAX/DOM, i.e. I wanted to parse xml nodes like SAX, but when I received whole message then I wanted to return it as XML Element (like in DOM). This way I could easily process incoming messages - now it's accomplishable with pull parsers. I think std needs both SAX/pull and DOM parsers. For DOM, if whole document is in memory, maybe this approach could be advantageous: http://en.wikipedia.org/wiki/VTD-XML http://vtd-xml.sourceforge.net/
Re: Windows API Translation
Wow, I didn't know this existed. I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? Currently, core.sys.windows.windows only contains a small subset of the one bad (imho) thing - functions parameters names removed :( just types remains. it is make self-documentation or fast-look-to-remember harder :(
Re: std.unittests vote tally
On Tuesday 08 February 2011 07:27:55 Andrei Alexandrescu wrote: Vote has closed last night at 23:59:59:99, but I accepted Lars' late vote. Thanks Jonathan for responding to comments and suggestions, and for a very dedicated attitude throughout. YES votes mean wholesale acceptance of the library. NO means either partial acceptance or no acceptance at all. We have eight NOs and even YESs. (In fairness I have changed my vote after Don committed to improve assert(), but forgot to submit it.) NO: SHOO (arguments: unittest code should be easy to read without prior knowledge) Don (arguments: assertPred is harder to read than assert, don't use if you don't like doesn't apply to Phobos, Phobos becomes difficult to read if we continue adopting clever functions, something that has any appearance of being complicated needs VERY strong justification. Voted yes for assertThrown and assertNotThrown. Asked for bugzilla enhancement requests to have assert obviate assertPred) Michel Fortin Brad Roberts David Nadlinger (yes for assertThrown, 50/50 for assertNotThrown and collectExceptionMsg, no for assertPred) spir (yes to assertThrown, abstain for assertNotThrown and collectExceptionMsg) Jim (reiterates that at best assert should be improved) Lars T. Kyllingstad (on the fence with assertPred) YES: Jens Mueller bearophile Andrej Mitrovic Nick Sabalausky Andrei Alexandrescu (contingent on reducing the size of examples) Masahiro Nakagawa (with a few notes) Andrew Wiley Reviewer Manager's decision: We have had an unexpected development: we can change assert() to obviate assertPred(), and Don all but promised he'll look into it. This means if we accept the library as it is, we'll look at a function on the brink of deprecation for the sake of a short-term benefit. Perhaps this is not the best course of action. So let's not put assertPred() for now in Phobos, though Jonathan is to be commended for his work which is leading to a vast improvement to a core facility. assertThrown seems to be liked by a vast majority - please add to std.exception at your earliest convenience. assertNotThrown and collectExceptionMsg are on the fence and it's unclear whether some NO voters want them as isolated functions. Let us take a one-week vote for each. I will create one thread for each. Thanks to everyone for participating, and special thanks to Jonathan! Enhancement request for assert: http://d.puremagic.com/issues/show_bug.cgi?id=5547 Okay. I'll look at doing another proposal which has the functionality of assertPred which doesn't make sense to add to assert, though I'll probably wait until the voting for assertNotThrown and collectExceptionMsg is done. I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test _both_ that a function succeeds as it's supposed to _and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. collectExceptionMsg isn't as critical, but it really does make it easy to test that exception messages are correct, since if you use collectException, you have to worry about checking for null before you can check the message. With collectExceptionMsg, it can be a an easy one-liner to check exception messages. Without it, you end up taking several lines, because you have to save and check the exception for null before you can check its message. I'll wait for the vote on assertNotThrown and collectExceptionMsg to be completed before putting assertThrown in Phobos. Then it can just all be taken care of at once. - Jonathan M Davis
Re: Efficient outputting of to-string conversions
On 02/07/2011 11:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? I haven't read a solution like the proposal for writeTo would not apply to primitives. Is it really so? (If only for language consistency, I would prefere this big shift to apply to all types.) -- _ vita es estrany spir.wikidot.com
Re: Overloading opEquals(T)(T y)
On 02/08/2011 12:16 AM, bearophile wrote:
Charles McAnany:
Hi, all. So I'm trying to make a BigRational struct, to get more comfortable
with D.
I suggest to ask similar questions in the D.learn newsgroup.
bool opEquals(Tdummy = void)(BigRational y){
auto temp = this-y;
if (temp.numerator == 0)
return true;
return false;
}
bool opEquals(T)(T y){
return this == BigRational(y);
}
But this is an ambiguity error.
One possible solution:
bool opEquals(T)(T y) if (is(T == BigRational)) { ... }
bool opEquals(T)(T y) if (!is(T == BigRational)) { ... }
Another solution:
bool opEquals(T)(T y) {
static if (is(T == BigRational)) {
// ...
} else {
// ...
}
}
Bye,
bearophile
I just thought at this alternative between a constraint and a static if a few
hours ago. In which case, and according to which reasoning, would one choose
one or the other? (I chose static if only for the very bad reason I can hardly
stand is().)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Efficient outputting of to-string conversions
On Tuesday 08 February 2011 07:55:23 spir wrote: On 02/07/2011 11:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? I haven't read a solution like the proposal for writeTo would not apply to primitives. Is it really so? (If only for language consistency, I would prefere this big shift to apply to all types.) Umm. _How_ would it apply to primitives. Does _toString_ apply to primitives? No. toString and writeTo apply to user-defined types that they're defined on. That doesn't mean that we can't or shouldn't find a buffered solution for dealing with primitives and I/O similar to writeTo, but primitives can't have writeTo defined on them any more than they can have toString defined on them. - Jonathan M Davis
Re: Efficient outputting of to-string conversions
On Tue, 08 Feb 2011 10:55:23 -0500, spir denis.s...@gmail.com wrote: On 02/07/2011 11:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? I haven't read a solution like the proposal for writeTo would not apply to primitives. Is it really so? (If only for language consistency, I would prefere this big shift to apply to all types.) writeTo does not need to apply to primitives because primitives can be written to streams without first converting to char[]. For instance, one does not write: writeln(to!string(5)) The whole point of writeTo is to allow easy output of custom data types that the standard library does not know how to output. It was not meant to extend to primitives. As far as Tomek's request, I would expect std.format.formattedWrite(buffer, %s, 7) to work, or std.format.formatValue (with associated FormatSpec, which I don't feel like looking up the usage of) -Steve
Re: Overloading opEquals(T)(T y)
On Tue, 08 Feb 2011 10:52:35 -0500, spir denis.s...@gmail.com wrote:
On 02/08/2011 12:16 AM, bearophile wrote:
Charles McAnany:
Hi, all. So I'm trying to make a BigRational struct, to get more
comfortable
with D.
I suggest to ask similar questions in the D.learn newsgroup.
bool opEquals(Tdummy = void)(BigRational y){
auto temp = this-y;
if (temp.numerator == 0)
return true;
return false;
}
bool opEquals(T)(T y){
return this == BigRational(y);
}
But this is an ambiguity error.
One possible solution:
bool opEquals(T)(T y) if (is(T == BigRational)) { ... }
bool opEquals(T)(T y) if (!is(T == BigRational)) { ... }
Another solution:
bool opEquals(T)(T y) {
static if (is(T == BigRational)) {
// ...
} else {
// ...
}
}
Bye,
bearophile
I just thought at this alternative between a constraint and a static if
a few hours ago. In which case, and according to which reasoning, would
one choose one or the other? (I chose static if only for the very bad
reason I can hardly stand is().)
The point of constraints are to intercept the compilation earlier. For
the discussed example, it's not as important. Let's try a smaller example.
What is the difference between:
bool opEquals(T)(T y) if (is(T == BigRational)) {...}
and
bool opEquals(T)(T y)
{
static if(is(T == BigRational)) {...}
else static assert(0, invalid type);
}
With an example like myBigRational == 5?
The difference is, with the first, the compiler simply skips compiling
that function due to the constraint. With the second, the compiler still
tries to compile the opEquals. The difference is really in the error the
compiler generates. With the first, the error is no function found, the
second is function doesn't compile. This is all pretty much equivalent,
until you want to overload the template. Perhaps you want to overload it
in different modules. With the second method, this is impossible, all
overloads must be in the single definition. This also makes it somewhat
less readable.
Plus, with the second, its really easy to forget that else static
assert, meaning the function will compile, and simply do nothing
(actually, it won't compile because it doesn't return a value, but still,
that error message is going to be way more confusing than no function
found).
I'd say a rule of thumb is, if the entire function is going to be
different based on the types, you should use a constraint. If there is
one small difference in the function, then using the static if might be a
better approach, but you still might want to use the constraints to
restrict to what you expect.
-Steve
Re: Efficient outputting of to-string conversions
On Tue, 08 Feb 2011 11:09:44 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 08 Feb 2011 10:55:23 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 11:38 PM, Tomek Sowiński wrote:
Jonathan M Davis napisał:
On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote:
Looks like std.conv.to always allocates behind the scenes. It's a
shame as
the returned string is immediately processed and discarded in my XML
writer. Are there plans to include a custom output variant, e.g.
to!string(7, outputRange)?
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
I know about Steven's proposal but it applies only to user types not
primitives. Either way std.conv.to would need a buffered output range
as integers are written from the right. Any chance for an abstraction
analogous to buffered input ranges discussed recently?
I haven't read a solution like the proposal for writeTo would not apply
to primitives. Is it really so? (If only for language consistency, I
would prefere this big shift to apply to all types.)
writeTo does not need to apply to primitives because primitives can be
written to streams without first converting to char[]. For instance,
one does not write:
writeln(to!string(5))
The whole point of writeTo is to allow easy output of custom data types
that the standard library does not know how to output. It was not meant
to extend to primitives.
As far as Tomek's request, I would expect
std.format.formattedWrite(buffer, %s, 7) to work, or
std.format.formatValue (with associated FormatSpec, which I don't feel
like looking up the usage of)
BTW, I think we probably should have a formatValue override like this
void formatValue(Char, Writer, T)(Writer w, T t)
{
FormatSpec!Char fs; // use default options
formatValue(w, t, fs);
}
Having to construct a FormatSpec when I just want the default seems like
overkill. Esp. since FormatSpec arg is always ref.
-Steve
Re: Another Phobos2 test
On 02/08/2011 04:11 PM, Adam Ruppe wrote:
I know, but I was suggesting something different, to turn the JSON
creation into some kind of Phobos library that you may call at
compile-time from normal D code. Then a compile-time JSON reader in
Phobos will allow to perform certain kinds of static introspection,
that later will be quite useful to create user-defined @annotations.
We could do that today with a combination of -X, -J, and a CTFE
JSON parser (it's possible that std.json would work today. I haven't
tried it specifically, but ctfe tends to surprise me with its
capabilities).
Of course, you'd have to run the compiler twice, but there's other
advantages to that too (like getting dependencies - my build tool
does this - and the first run is fast anyway.
I'm tempted to do it now just to prove we can... but I'm already
a bit loaded with stuff to do.
What I dream of is something a bit different: a D decoder (lexical,
syntactic, semantic(*) analyser) that constructs an AST as a plain D data
structure --without any fancy stuff. And writes it out on demand as a D module
(in static this(), since for a reason I haven't yet caught data description can
only go there).
I can't even start to imagine all what we could then do /easily/. (we would
even have type defs in D... would change from obscure RTTI)
=
import std.stdio;
a = 1;
void main () {
writeln(a);
}
=
==
=
import AST; // Node types, mainly
Module module;
static this () {
module = Module ([
Import(std.stdio),
Assignment(a, Integer(1)),
FunctionDef(
/* name */ main,
/* params */[],
/* block */ [
FunctionCall(
/* name */ writeln,
/* args */ [Symbol(a)]
)
]
)
]);
}
=
Too bad we're missing named args, would be highly helpful here; but we can
probably survive that...
(Yes, Bearophile, there's certainly a bug report for this ;-)
I would enjoy writing a prototype when I have some time (not tomorrow), for a
tiny subset of D (kind of proof of concept).
Denis
(*) As far as possible.
--
_
vita es estrany
spir.wikidot.com
Re: Windows API Translation
Trass3r Wrote: HANDLE WINAPI FindFirstChangeNotification( __in LPCTSTR lpPathName, __in BOOL bWatchSubtree, __in DWORD dwNotifyFilter ); FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not. D string encoding is not configurable. What configuration are you talking about?
Re: std.unittests vote tally
On 2/8/11 10:54 AM, Jonathan M Davis wrote: Enhancement request for assert: http://d.puremagic.com/issues/show_bug.cgi?id=5547 Thanks! Okay. I'll look at doing another proposal which has the functionality of assertPred which doesn't make sense to add to assert, though I'll probably wait until the voting for assertNotThrown and collectExceptionMsg is done. I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test _both_ that a function succeeds as it's supposed to _and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. I think many people would emulate assertNotThrown by simply calling the function and... well if it throws then the unittest fails. collectExceptionMsg isn't as critical, but it really does make it easy to test that exception messages are correct, since if you use collectException, you have to worry about checking for null before you can check the message. With collectExceptionMsg, it can be a an easy one-liner to check exception messages. Without it, you end up taking several lines, because you have to save and check the exception for null before you can check its message. I'll wait for the vote on assertNotThrown and collectExceptionMsg to be completed before putting assertThrown in Phobos. Then it can just all be taken care of at once. Sounds great. Thanks! Andrei
Re: Windows API Translation
On Tue, Feb 8, 2011 at 10:40 AM, Kagamin s...@here.lot wrote: Trass3r Wrote: HANDLE WINAPI FindFirstChangeNotification( __in LPCTSTR lpPathName, __in BOOL bWatchSubtree, __in DWORD dwNotifyFilter ); FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not. D string encoding is not configurable. What configuration are you talking about? It's a setting in Visual Studio that translates into a compiler switch for Visual C++, or such is my understanding. He was talking about configuration on the Microsoft C/C++ side, not the D side. In D, I just have to add a suffix to the name to choose the one I want.
Re: Windows API Translation
Am 08.02.2011 17:40, schrieb Kagamin: Trass3r Wrote: HANDLE WINAPI FindFirstChangeNotification( __in LPCTSTR lpPathName, __in BOOL bWatchSubtree, __in DWORD dwNotifyFilter ); FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not. D string encoding is not configurable. What configuration are you talking about? he talks about stuff like that (from winbase.h - vs2010) WINBASEAPI __out HANDLE WINAPI CreateFileA( __in LPCSTR lpFileName, __in DWORD dwDesiredAccess, __in DWORD dwShareMode, __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes, __in DWORD dwCreationDisposition, __in DWORD dwFlagsAndAttributes, __in_opt HANDLE hTemplateFile ); WINBASEAPI __out HANDLE WINAPI CreateFileW( __in LPCWSTR lpFileName, __in DWORD dwDesiredAccess, __in DWORD dwShareMode, __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes, __in DWORD dwCreationDisposition, __in DWORD dwFlagsAndAttributes, __in_opt HANDLE hTemplateFile ); #ifdef UNICODE #define CreateFile CreateFileW #else #define CreateFile CreateFileA #endif // !UNICODE not the string itself - look at lpFileName
Re: Windows API Translation
Am 08.02.2011 17:40, schrieb Kagamin: Trass3r Wrote: HANDLE WINAPI FindFirstChangeNotification( __in LPCTSTR lpPathName, __in BOOL bWatchSubtree, __in DWORD dwNotifyFilter ); FindFirstChangeNotification is - like any other Windows function that receives a string - just an alias that points to a version with suffix W or A depending on whether your project is configured to be Unicode or not. D string encoding is not configurable. What configuration are you talking about? or these typical win-api phobos constructs from std.file auto h = useWfuncs ? CreateFileW(std.utf.toUTF16z(name), defaults) : CreateFileA(toMBSz(name), defaults);
Re: Overloading opEquals(T)(T y)
On 02/08/2011 05:17 PM, Steven Schveighoffer wrote:
On Tue, 08 Feb 2011 10:52:35 -0500, spir denis.s...@gmail.com wrote:
On 02/08/2011 12:16 AM, bearophile wrote:
Charles McAnany:
Hi, all. So I'm trying to make a BigRational struct, to get more comfortable
with D.
I just thought at this alternative between a constraint and a static if a few
hours ago. In which case, and according to which reasoning, would one choose
one or the other? (I chose static if only for the very bad reason I can
hardly stand is().)
The point of constraints are to intercept the compilation earlier. For the
discussed example, it's not as important. Let's try a smaller example.
What is the difference between:
bool opEquals(T)(T y) if (is(T == BigRational)) {...}
and
bool opEquals(T)(T y)
{
static if(is(T == BigRational)) {...}
else static assert(0, invalid type);
}
Thank you very much, Steven.
I'd say: in the first case, there are as many functions as constraints variants
(provided other variants are implemented, indeed) triggered by actual calls to
opEquals.
Tell me if i'm right on this: In the second case, there is a single function
generated, and branches of static if are inserted according to actual calls. Is
that right? If yes then I don't really care of this use of static f (I'm aware
there are other, maybe more relevant, use cases).
With an example like myBigRational == 5?
The difference is, with the first, the compiler simply skips compiling that
function due to the constraint. With the second, the compiler still tries to
compile the opEquals. The difference is really in the error the compiler
generates. With the first, the error is no function found, the second is
function doesn't compile. This is all pretty much equivalent, until you want
to overload the template. Perhaps you want to overload it in different modules.
With the second method, this is impossible, all overloads must be in the single
definition. This also makes it somewhat less readable.
Plus, with the second, its really easy to forget that else static assert,
meaning the function will compile, and simply do nothing (actually, it won't
compile because it doesn't return a value, but still, that error message is
going to be way more confusing than no function found).
Right.
I'd say a rule of thumb is, if the entire function is going to be different
based on the types, you should use a constraint. If there is one small
difference in the function, then using the static if might be a better
approach, but you still might want to use the constraints to restrict to what
you expect.
Right again, makes full sense now.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Windows API Translation
On 2/8/11, Andrew Wiley debio...@gmail.com wrote: I'm trying to use the Windows file change notification API from D, and I'm having trouble translating Microsoft's macro-laden signatures into D. I thought I had it figured out, but optlink says otherwise: The original function is this: That's odd, I was just going through its documentation yesterday because I need it for a personal project. I've also looked at ReadDirectoryChangesW, which should give me the exact file or folder that was changed. Just in case you haven't found already (or if someone else is interested), there's a few good pages describing these functions: FindFirstChangeNotification function: http://msdn.microsoft.com/en-us/library/aa364417%28v=vs.85%29.aspx Example C++ Code: http://msdn.microsoft.com/en-us/library/aa365261%28v=vs.85%29.aspx FindNextChangeNotification function: http://msdn.microsoft.com/en-us/library/aa364427%28v=vs.85%29.aspx ReadDirectoryChangesW function: http://msdn.microsoft.com/en-us/library/aa365465%28v=vs.85%29.aspx FILE_NOTIFY_INFORMATION Structure: http://msdn.microsoft.com/en-us/library/aa364391%28v=vs.85%29.aspx WaitForMultipleObjects Function: http://msdn.microsoft.com/en-us/library/ms687025%28v=vs.85%29.aspx http://stackoverflow.com/questions/342668/how-to-use-readdirectorychangesw-method-with-completion-routine The C++ example of FindFirstChangeNotification works great. There's no I/O polling going on, the thread is waiting for WaitForMultipleObjects to return and get notifications from the OS for any file/folder changes, and they're pretty much instantaneous.
Re: std.unittests vote tally
On 02/08/2011 04:54 PM, Jonathan M Davis wrote: I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test_both_ that a function succeeds as it's supposed to_and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. I do agree failure cases must be tested (maybe even more) and are very often neglected by programmers in unittests. But in a no-throw case the proper assertion is just a regular assert (at least, in my use of unittests): // dunno the syntax assertThrown ( 1/0, DivisionByZero ); assert ( 1/1 == 1 ); If 1/1 throws DivisionByZero, I get all the information I need. Reason for my question mark about including assertNotThrown. When do I need it? What new does it bring? Sorry, I should have asked/commented earlier on this point (but had too much...). Denis -- _ vita es estrany spir.wikidot.com
Re: std.unittests vote tally
Am 08.02.2011 18:00, schrieb spir: On 02/08/2011 04:54 PM, Jonathan M Davis wrote: I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test_both_ that a function succeeds as it's supposed to_and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. I do agree failure cases must be tested (maybe even more) and are very often neglected by programmers in unittests. But in a no-throw case the proper assertion is just a regular assert (at least, in my use of unittests): // dunno the syntax assertThrown ( 1/0, DivisionByZero ); assert ( 1/1 == 1 ); If 1/1 throws DivisionByZero, I get all the information I need. Reason for my question mark about including assertNotThrown. When do I need it? What new does it bring? Sorry, I should have asked/commented earlier on this point (but had too much...). Denis Maybe it can be nested like assertThrown!Exception( assertNotThrown!MyException( fun(42) ) ); to ensure that fun() doesn't throw a MyException, but does throws another Exception? Cheers, - Daniel
Re: Overloading opEquals(T)(T y)
On Tue, 08 Feb 2011 11:49:47 -0500, spir denis.s...@gmail.com wrote:
On 02/08/2011 05:17 PM, Steven Schveighoffer wrote:
What is the difference between:
bool opEquals(T)(T y) if (is(T == BigRational)) {...}
and
bool opEquals(T)(T y)
{
static if(is(T == BigRational)) {...}
else static assert(0, invalid type);
}
Thank you very much, Steven.
I'd say: in the first case, there are as many functions as constraints
variants (provided other variants are implemented, indeed) triggered by
actual calls to opEquals.
Tell me if i'm right on this: In the second case, there is a single
function generated, and branches of static if are inserted according to
actual calls. Is that right? If yes then I don't really care of this use
of static f (I'm aware there are other, maybe more relevant, use cases).
No, there are multiple functions generated, and in each function, the
correct static if branch is compiled. It's technically no different
code-generation wise than the constraint version.
The difference comes in the compiler decision of whether to compile a
function or not, and who is responsible for reporting the error (in the
first, the compiler reports the error, in the second, you are responsible
for reporting the error via static assert).
-Steve
Re: std.unittests vote tally
On Tuesday, February 08, 2011 08:36:27 Andrei Alexandrescu wrote: On 2/8/11 10:54 AM, Jonathan M Davis wrote: Enhancement request for assert: http://d.puremagic.com/issues/show_bug.cgi?id=5547 Thanks! Okay. I'll look at doing another proposal which has the functionality of assertPred which doesn't make sense to add to assert, though I'll probably wait until the voting for assertNotThrown and collectExceptionMsg is done. I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test _both_ that a function succeeds as it's supposed to _and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. True. But the test is clearer if you're explicitly testing that the function doesn't throw instead of just having a stray function call that isn't tested. For instance. assertNotThrown!DateTimeException(TimeOfDay(23, 59, 59)); is clearer than TimeOfDay(23, 59, 59); In the first case, it's clear that you're testing that the function call does not throw. In the second, it's a function call that seems to do nothing, since its result isn't saved, it takes no references, and it's not part of an assert. Also, the first one results in an AssertError that clearly states that the problem is that the function threw when it wasn't supposed to, whereas in the second, you just get a stray exception which is likely going to be a bit hard to track down - even with a stack trace - because the unit test blocks get named with seemingly random numbers rather than real names and tracking down which unittest block an exception was thrown from is a royal pain (one more reason why we really should have named unit tests). So, I think that assertNotThrown definitely helps with clarity, and it makes it much easier to track down the failure. - Jonathan M Davis
Re: Please reply to this to vote to assertNotThrown in std.unittests
On 2/8/11 4:30 PM, Andrei Alexandrescu wrote: Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Vote closes on Feb 15. Sorry, I didn't phrase the part of my previous message concerning assertNotThrown and collectExceptionMsg quite clearly. What I meant is that I personally never felt the need for assertNotThrown and collectExceptionMsg, contrary to assertThrown, which I use pretty regularly. If others find these useful, I don't see any reasons not to include them, though. Concerning assertNotThrown specifically, I usually just call the function in question – if it throws unexpectedly, the exception makes the unit test fail anyway. This approach obviously doesn't allow you to filter only a single exception type, but I have a hard time trying to imagine where you would really need something like that. Also, you can't specify an extra assert message, but I'd rather like to be able to use named unit test blocks for that (what was the result of the discussion on them again?). David
Re: std.unittests vote tally
So in the most basic form assertThrown is used to check that our functions throw on bad (user) input, and assertNotThrown is used to check that our functions work with valid input? Looks good to me.
Re: std.unittests vote tally
On Tuesday, February 08, 2011 09:26:23 Andrej Mitrovic wrote: So in the most basic form assertThrown is used to check that our functions throw on bad (user) input, and assertNotThrown is used to check that our functions work with valid input? Looks good to me. Yes. - Jonathan M Davis
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
On 2/8/11 4:29 PM, Andrei Alexandrescu wrote: Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. As I stated in the assertNotThrown thread, I don't see any reason why this shouldn't be included if it's helpful for other people, even though I personally didn't feel the need for it so far. Since the main use case seems to be in unit tests to check if the correct exception messages are produced, I'd suggest adding a short note about that to the documentation comment – or is this going to end up in a new std.unittest module anyway? I thought it would be merged into std.exception… David
Re: Windows API Translation
Btw, how up-to-date are the import libs in windows/lib that ships with DMD2? Can they be used with e.g. Win7?
Re: Please reply to this to vote to assertNotThrown in std.unittests
Voting Yes.
Re: Please reply to this to vote to assertNotThrown in std.unittests
Am 08.02.2011 16:30, schrieb Andrei Alexandrescu: Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Vote closes on Feb 15. Andrei Voting YES, because (quoting my post in another Thread): Maybe it can be nested like assertThrown!Exception( assertNotThrown!MyException( fun(42) ) ); to ensure that fun() doesn't throw a MyException, but does throws another Exception [which is a super-class of the Exception that may not be thrown]? Cheers, - Daniel
Re: Writing XML
On 2/6/11 8:32 PM, spir wrote: When does one need to write by hand, in source, structured data needing to be serialised into XML (or any other format)? In my (admittedly very limited), such data always are outputs of some processing (if only reading from other file). denis If you have a website API that exposes its data via XML, you would like to generate it like that. What do you mean outputs of some processing? As far as I know, the code that Tomek showed is some processing. :-P
Re: std.unittests vote tally
On 2011-02-08 12:26:23 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com said: So in the most basic form assertThrown is used to check that our functions throw on bad (user) input, and assertNotThrown is used to check that our functions work with valid input? Most functions are said to work whey they have the desired effect, not when they do not throw. To make sure a function works, you should call it and then check the return value and/or whatever the side effects should be. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Windows API Translation
Andrej Mitrovic wrote: Btw, how up-to-date are the import libs in windows/lib that ships with DMD2? Can they be used with e.g. Win7? They are horribly outdated. But I have a vague recollection that Walter has explicit permission from Microsoft to redistribute updated versions.
Re: Windows API Translation
novice2 wrote: Wow, I didn't know this existed. I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? Currently, core.sys.windows.windows only contains a small subset of the one bad (imho) thing - functions parameters names removed :( just types remains. it is make self-documentation or fast-look-to-remember harder :( That's because the code is derived from MingW, not from the Microsoft headers.
Re: Windows API Translation
On 2/8/11, Don nos...@nospam.com wrote: Andrej Mitrovic wrote: Btw, how up-to-date are the import libs in windows/lib that ships with DMD2? Can they be used with e.g. Win7? They are horribly outdated. But I have a vague recollection that Walter has explicit permission from Microsoft to redistribute updated versions. So, implib /s on my system DLLs, right? Does anyone have a script to do that? I'm lazy. :p
Re: Windows API Translation
So, implib /s on my system DLLs, right? Does anyone have a script to do that? I'm lazy. :p Something like: FOR %%i IN (*.dll) DO implib /system %%~ni.lib %%i
Re: Efficient outputting of to-string conversions
Andrei Alexandrescu napisał: I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? Generally I found it more difficult to define a solid output buffer abstraction. This is a great motivating example though. To my surprise, an API of the same form seems to be what the doctor prescribed. Here's a semi-formal definition: A buffered output range R is defined as such: R.front returns the currently uncommitted buffer of type T[] R.moreFront(n) makes n more elements available for writing R.commitFront(n) writes the first n elements in front() R.flushFront() writes the buffer currently held in front() and makes another buffer available (initially empty). I was thinking along the same lines. There's one missing: R.skipFront(n) skips the first n elements without outputting Why? Look at integral conversions in std.conv.to. It first calculates maximum string size, then writes numbers to the char array back to front, then returns result[$ - ndigits .. $] where ndigits is how long the string turned out. Returning to Steven's DIP, I think writeTo should take the above rather than void delegate(char[]). With the latter you still have to allocate the pieces. Our buffered output range is friends with polymorphism too. If you set T=char, its API is devoid of generics. Such interface can be placed in object.d with an official blessing. -- Tomek
Re: std.unittests vote tally
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1401.1297185535.4748.digitalmar...@puremagic.com... On Tuesday, February 08, 2011 08:36:27 Andrei Alexandrescu wrote: On 2/8/11 10:54 AM, Jonathan M Davis wrote: Enhancement request for assert: http://d.puremagic.com/issues/show_bug.cgi?id=5547 Thanks! Okay. I'll look at doing another proposal which has the functionality of assertPred which doesn't make sense to add to assert, though I'll probably wait until the voting for assertNotThrown and collectExceptionMsg is done. I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test _both_ that a function succeeds as it's supposed to _and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. True. But the test is clearer if you're explicitly testing that the function doesn't throw instead of just having a stray function call that isn't tested. For instance. assertNotThrown!DateTimeException(TimeOfDay(23, 59, 59)); is clearer than TimeOfDay(23, 59, 59); In the first case, it's clear that you're testing that the function call does not throw. In the second, it's a function call that seems to do nothing, since its result isn't saved, it takes no references, and it's not part of an assert. Also, the first one results in an AssertError that clearly states that the problem is that the function threw when it wasn't supposed to, whereas in the second, you just get a stray exception which is likely going to be a bit hard to track down - even with a stack trace - because the unit test blocks get named with seemingly random numbers rather than real names and tracking down which unittest block an exception was thrown from is a royal pain (one more reason why we really should have named unit tests). So, I think that assertNotThrown definitely helps with clarity, and it makes it much easier to track down the failure. This is why I've always felt that assert/assertPred/etc should always check whether an exception was thrown and report it accordingly. That way, the test to make sure the result is correct will *automatically* provide all the benefits of assertNotThrown, but without the developer needing to compulsively assertNotThrown every single function they write/test. However, that said, I think assertNotThrown would still be useful for void functions since those don't have a result to assert(). Plus, AIUI, assertNotThrown lets you make sure that a *specific* type of exception isn't thrown for the given arguments, which I can imagine would be useful in certain cases (for instance, if a function had been throwing the wrong type of exception upon bad input and you want to prevent regressions).
Re: Windows API Translation
That's exactly what I did a minute ago: For %%a in (*.dll) do implib /s %%~na.lib %%a :) Gotta hate that cryptic batch syntax though.. I am still missing these two though: uuid.dll winspool.dll From what I can tell uuid is used with COM, but it isn't installed on my system for some reason. Winspool is for printers, right? I don't care about that one.
Re: Please reply to this to vote to assertNotThrown in std.unittests
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:iirnmf$28ig$5...@digitalmars.com... Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Vote closes on Feb 15. YES
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:iirnm1$28ig$4...@digitalmars.com... Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. Andrei YES
Re: std.unittests/exception Update and Vote
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqk74auaeav7ka@steve-laptop... On Tue, 08 Feb 2011 06:52:30 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: *Sigh* I was hoping for a clearer vote than this. Sorry for the lack of voting/attention, I've had barely any time to work with D lately, and I haven't even looked at your lib. -Steve P.S. I'm f***ing sick of snow... I got sick of snow ten years ago. Makes me wonder why I'm still in Cleveland...
Re: Efficient outputting of to-string conversions
Andrei Alexandrescu napisał: For the latter, Tomek's idea of passing an output range as an optional second parameter seems appropriate. Please file as an enhancement to bugzilla. If anyone has time to work on this, please do. If not, I'll work on it as my schedule allows. http://d.puremagic.com/issues/show_bug.cgi?id=5548 -- Tomek
Re: std.unittests/exception Update and Vote
On Tue, 08 Feb 2011 15:36:14 -0500, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqk74auaeav7ka@steve-laptop... On Tue, 08 Feb 2011 06:52:30 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: *Sigh* I was hoping for a clearer vote than this. Sorry for the lack of voting/attention, I've had barely any time to work with D lately, and I haven't even looked at your lib. -Steve P.S. I'm f***ing sick of snow... I got sick of snow ten years ago. Makes me wonder why I'm still in Cleveland... I'd wonder why you were in Cleveland for a number of reasons ;) This is the worst winter I've ever experienced. My whole body aches from battling ice dams for weeks. There's few things worse than having to put on snow clothes still wet (and smelly) from yesterday to go up on a ladder in the rain and whack ice you cleared just yesterday because water is again seeping in your house... -Steve
Re: Windows API Translation
Nevermind, uuid isn't an import library, apparently it holds some GUID's for COM objects(?). Replacing those import libs now seems like a bad idea because phobos can't find a ton of symbols. Eh, it's never easy, is it..
Re: Windows API Translation
Correction: Not Phobos, druntime.
Re: Windows API Translation
How many corrections? I thought snn.lib was druntime in disguise. It's Digital Mars C/C++ runtime library. I'll just put all the originals back.
Re: Another Phobos2 test
Adam Ruppe: I'm still trying to find something I like for this. Me too. Error messages give a line number... but if there's still several points of similar failure on that one line, it doesn't help as much as it could. I understand. But splitting lines too much make the code a bit too much thin. I think a better solution is this request (from Lewis): http://d.puremagic.com/issues/show_bug.cgi?id=5521 We could do that today with a combination of -X, -J, and a CTFE JSON parser (it's possible that std.json would work today. I haven't tried it specifically, but ctfe tends to surprise me with its capabilities). Currently the JSON data is not computed at compile-time, and it's written as file text on the disk, while a library is meant to not touch the disk. So the situation isn't good enough yet. Maybe try ubyte[]? There are moments when I want an array of ubytes, other moments when I want an array of 8 bit chars, and other situations where I want a string of chars. An ubyte[] is a workaround for a type system not good enough yet. Though, on the other hand, I've used the ncurses library which does this kind of thing. The number of function names is obscene, and the benefit is quite small. I agree that too many functions are going to give problems. But an a suffix is burden smaller than two names fully new. I'm not convinced the parentheses are a big deal. (Hell, I've done lisp before... and kinda liked it. :P) Scala, Ruby, ML-class languages like Haskell, etc have means to reduce parentheses count. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). I have used Scheme, but parentheses tire me after a while. Perhaps you want to just work with one length strings? str[0..1] instead of str[0]. I have done this some times. I presume I will need to use this more. Bye and thank you, bearophile
Re: Please reply to this to vote to assertNotThrown in std.unittests
Andrei Alexandrescu Wrote: Reply here to vote ONLY for the function assertNotThrown in Jonathan M Davis's std.unittests. Vote closes on Feb 15. Andrei Yes!
Re: Windows API Translation
On 08/02/2011 12:25, Trass3r wrote: I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? They definitely need to be merged. Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart.
Re: Windows API Translation
fwiw, I've had more luck using coffimplib on the libs from the Windows platform SDK than i have using implib on the dlls.
Re: Windows API Translation
Am 08.02.2011 22:37, schrieb Stewart Gordon: On 08/02/2011 12:25, Trass3r wrote: I wonder if these bindings would be suitable for inclusion in the core.sys.windows package? They definitely need to be merged. Merged? The whole point of the bindings project is that it will one day be complete. As such, it needs to _replace_ the current std.c.windows.* and core.sys.windows.*. Stewart. VisualD has some code for automated winapi-conversion: quoteto build the necessary D translations from the Windows and Visual Studio SDK/quote http://www.dsource.org/projects/visuald/wiki/Build_from_source greets Matthias
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
Andrei Alexandrescu napisał: Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. I'm in two minds. Since Jonathan has improved collectException the proposed function is just a short-hand for: auto e = collectException!MyException(expression); assert (e); assert (e.msg == ...); or: assert (collectException!MyException(expression) == new MyException(msg)); I would use these because of the possibility to test properties other than .msg. Also, there's an ambiguity ex.msg is null vs. didn't throw. But perhaps msg is important enough to deserve a dedicated wrapper. I'll vote in favour, given that the docs are shrunk to something like: Convenience function for extracting the exception's message. Equivalent of: --- auto e = collectException(mayThrow); string msg = e ? e.msg : null; --- And put a link to collectException. -- Tomek
Re: Windows API Translation
Andrew Wiley wrote:
I'm trying to use the Windows file change notification API from D, and
I'm having trouble translating Microsoft's macro-laden signatures into
D. I thought I had it figured out, but optlink says otherwise:
The original function is this:
HANDLE WINAPI FindFirstChangeNotification(
__in LPCTSTR lpPathName,
__in BOOL bWatchSubtree,
__in DWORD dwNotifyFilter
);
I translated it into:
extern(Windows) {
uint FindFirstChangeNotification(
const(char)* lpPathName,
bool bWatchSubtree,
uint dwNotifyFilter
);
}
Optlink is giving me undefined symbol errors, but I can't seem to
figure out what I have wrong. Any help would be appreciated.
Here is the declaration from \dm\include\win32\winbase.h:
WINBASEAPI
HANDLE
WINAPI
FindFirstChangeNotificationA(
LPCSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
WINBASEAPI
HANDLE
WINAPI
FindFirstChangeNotificationW(
LPCWSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
#ifdef UNICODE
#define FindFirstChangeNotification FindFirstChangeNotificationW
#else
#define FindFirstChangeNotification FindFirstChangeNotificationA
#endif // !UNICODE
Note the W postfix and the LPCWSTR arg, which should be wchar* (in D).
With the Digital Mars C compiler, getting the de-macro'd version is easy:
dmc -c foo.c -e -l
and the macro expanded version will be written to foo.lst. Very handy.
Re: Windows API Translation
Don wrote: Andrej Mitrovic wrote: Btw, how up-to-date are the import libs in windows/lib that ships with DMD2? Can they be used with e.g. Win7? They are horribly outdated. True, but MS never changes the api's, so they work and continue to work fine.
Re: Another Phobos2 test
bearophile: I understand. But splitting lines too much make the code a bit too much thin. I like it being thin so for me, it's a win/win. I use small and split windows as well as 8 character tab stops. (4 characters just blend into the background..) I think a better solution is this request (from Lewis): http://d.puremagic.com/issues/show_bug.cgi?id=5521 That wouldn't help with runtime errors... and I don't think it would help much for compile either, as a general rule. Something like cannot call function foo() with args abc puts you in the right place anyway, even on a pretty complex line. Currently the JSON data is not computed at compile-time, and it's written as file text on the disk, while a library is meant to not touch the disk. So the situation isn't good enough yet. dmd -X -Xf- file.d That dumps it to stdout, which you can pipe out to where it needs to be. Though, getting it into the program being compiled might be a little tricky without touching the disk. But then again, does it really matter? The compile process writes files as part of its normal operation anyway. An ubyte[] is a workaround for a type system not good enough yet. I wouldn't say that it isn't good enough. It's just that you and Andrei have a different philosophy about this. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). Remember, one man's noise is another's parsing anchors. For example, I find an if without parens to just look... naked.
Re: High performance XML parser
Steven Schveighoffer napisał:
The design I'm thinking is that the node iterator will own a buffer. One
consequence is that the fields of the current node will point to the
buffer akin to foreach(line; File.byLine), so in order to lift the input
the user will have to dup (or process the node in-place). As new nodes
will be overwritten on the same piece of memory, an important trait of
the design emerges: cache intensity. Because of XML namespaces I think
it is necessary for the buffer to contain the current node plus all its
parents.
That might not scale well. For instance, if you are accessing the 1500th
child element of a parent, doesn't that mean that the buffer must contain
the full text for the previous 1499 elements in order to also contain the
parent?
Maybe I'm misunderstanding what you mean.
Let's talk on an example:
a name=value
b
Some Text 1
c2 !-- HERE --
Some text 2
/c2
Some Text 3
/b
/a
The buffer of the iterator positioned HERE would be:
[Node a | Node b | Node c2]
Node c2 and all its parents are available for inspection. Node a's attribute is
stored in the buffer, but not b's Some text 1 as it is c2's sibling; Some
text 1 was available in the previous iteration, now it's overwritten by c2. To
get to Some text 2 let's advance the iterator in depth to get:
[Node a | Node b | Node c2 | Text node Some text 2]
Advancing it once more we get to:
[Node a | Node b | Text node Some text 3]
So Some text 3 is written where c2 and the text node 2 used to be.
The element type of the range would always be the child, parents available
through pointers:
foreach (node; xmlRange) {
doStuff(node);
if (Node* parent = node.parent)
doOtherStuff(parent);
}
Having no access to siblings is quite limiting but the iterator can form an
efficient (zero-allocation) basis on which more convenient schemes are built
upon. It's still just brain-storming, though. I fear there's something that'll
make the whole idea crash burn.
I would start out with a non-compliant parser, but one that allocates
nothing beyond the I/O buffer, one that simply parses lazily and can be
used as well as a SAX parser. Then see how much extra allocations we need
to get it to be compliant. Then, one can choose the compliancy level
based on what performance penalties one is willing to incur.
Yeah, 100% compliance is a long way.
--
Tomek
Re: Another Phobos2 test
Adam D. Ruppe:
I like it being thin so for me, it's a win/win.
I use small and split windows as well as
8 character tab stops. (4 characters just blend into the background..)
I see. I prefer to see a chunk of code that does something, on the screen, and
to not scroll too much.
For lot of time the common indent for Delphi code was of 2 spaces :-)
That wouldn't help with runtime errors... and I don't think
it would help much for compile either, as a general rule.
Something like cannot call function foo() with args abc puts
you in the right place anyway, even on a pretty complex line.
The column number of errors helps a little when you have lines of code like
(and in other situations):
void main() {
int[2] f;
auto r = f[1] + f[2];
}
Currently the JSON data is not computed at compile-time, and it's
written as file text on the disk, while a library is meant to not
touch the disk. So the situation isn't good enough yet.
dmd -X -Xf- file.d
That dumps it to stdout, which you can pipe out to where it needs
to be.
I meant something different. I don't want to convert JSON tree from-to text,
I'd like to bypass the text representation fully. So the compile-time JSON
Phobos library returns a data structure that represents the JSON tree (created
by the compiler) in memory. There are zero files, stdout, pipes and text
streams.
Though, getting it into the program being compiled might
be a little tricky without touching the disk. But then again,
does it really matter? The compile process writes files as
part of its normal operation anyway.
It matters if you want to use the JSON data in a larghish program as a static
reflection mean to implement good user defined attributes. The less you convert
and parse data, the faster and more usable the whole game is.
An ubyte[] is a workaround for a type system not good enough yet.
I wouldn't say that it isn't good enough. It's just that you
and Andrei have a different philosophy about this.
I don't remember Andrei's opinion about that idea.
Reducing syntax noise in functional-style code is something that
a lot of people wants (me too).
Remember, one man's noise is another's parsing anchors. For example,
I find an if without parens to just look... naked.
Removing some syntax noise is not a so optional thing in functional languages.
In Haskell you often have code like:
vmoot xs = (xs++).map (zipWith (+) lxs). flip matmul r_90.
map (flip (zipWith (-)) lxs) .reverse . init $ xs
where lxs = last xs
If you start putting parentheses everywhere, you produce something less
readable than Lisp.
I have never suggested to introduce optional parenthesis in D (the opposite:
I'd like function calls to always require them in D), I have just suggested to
replace two functions like array(map()) with amap().
Bye,
bearophile
Re: std.unittests vote tally
On 2/8/11 12:20 PM, Jonathan M Davis wrote: On Tuesday, February 08, 2011 08:36:27 Andrei Alexandrescu wrote: On 2/8/11 10:54 AM, Jonathan M Davis wrote: Enhancement request for assert: http://d.puremagic.com/issues/show_bug.cgi?id=5547 Thanks! Okay. I'll look at doing another proposal which has the functionality of assertPred which doesn't make sense to add to assert, though I'll probably wait until the voting for assertNotThrown and collectExceptionMsg is done. I would point out, however, that it would be rather silly to include assertThrown and not assertNotThrown. Good unit tests should test _both_ that a function succeeds as it's supposed to _and_ that it fails as it's supposed to. So, I would hope that people vote in favor of assertNotThrown. True. But the test is clearer if you're explicitly testing that the function doesn't throw instead of just having a stray function call that isn't tested. For instance. assertNotThrown!DateTimeException(TimeOfDay(23, 59, 59)); is clearer than TimeOfDay(23, 59, 59); In the first case, it's clear that you're testing that the function call does not throw. In the second, it's a function call that seems to do nothing, since its result isn't saved, it takes no references, and it's not part of an assert. Also, the first one results in an AssertError that clearly states that the problem is that the function threw when it wasn't supposed to, whereas in the second, you just get a stray exception which is likely going to be a bit hard to track down - even with a stack trace - because the unit test blocks get named with seemingly random numbers rather than real names and tracking down which unittest block an exception was thrown from is a royal pain (one more reason why we really should have named unit tests). So, I think that assertNotThrown definitely helps with clarity, and it makes it much easier to track down the failure. - Jonathan M Davis I think I'd write that as assert(!collectException(TimeOfDay(23, 59, 59)); Andrei
Re: std.unittests/exception Update and Vote
On 2/8/11 3:50 PM, Steven Schveighoffer wrote: On Tue, 08 Feb 2011 15:36:14 -0500, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqk74auaeav7ka@steve-laptop... On Tue, 08 Feb 2011 06:52:30 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: *Sigh* I was hoping for a clearer vote than this. Sorry for the lack of voting/attention, I've had barely any time to work with D lately, and I haven't even looked at your lib. -Steve P.S. I'm f***ing sick of snow... I got sick of snow ten years ago. Makes me wonder why I'm still in Cleveland... I'd wonder why you were in Cleveland for a number of reasons ;) This is the worst winter I've ever experienced. My whole body aches from battling ice dams for weeks. There's few things worse than having to put on snow clothes still wet (and smelly) from yesterday to go up on a ladder in the rain and whack ice you cleared just yesterday because water is again seeping in your house... -Steve I'm completely weird I guess. I love snow and winter. I'm just back from a skiing day non-stop 11am to 4pm on the most difficult slopes (including two extreme terrain runs starting at 3963 meters). My water and food froze in my pockets. At times I could hardly feel my face. I still breathe twice the normal rate. Every cubic inch of my body aches. And... I'm loving every minute of it. Andrei
Re: Writing XML
On 02/08/2011 07:44 PM, Ary Manzana wrote: On 2/6/11 8:32 PM, spir wrote: When does one need to write by hand, in source, structured data needing to be serialised into XML (or any other format)? In my (admittedly very limited), such data always are outputs of some processing (if only reading from other file). denis If you have a website API that exposes its data via XML, you would like to generate it like that. What do you mean outputs of some processing? As far as I know, the code that Tomek showed is some processing. :-P No, in his example, the data were hardcoded as plain constant in source code. Denis -- _ vita es estrany spir.wikidot.com
Re: Another Phobos2 test
On 02/08/2011 10:11 PM, bearophile wrote: Adam Ruppe: I'm still trying to find something I like for this. Me too. I like Adam's solution as well, but it's not perfect. The only other solution (like for constraints) would be a syntactic difference, but since we're limited by keyboard keys, this would instead certainly augment visual noise. Error messages give a line number... but if there's still several points of similar failure on that one line, it doesn't help as much as it could. I understand. But splitting lines too much make the code a bit too much thin. I think a better solution is this request (from Lewis): http://d.puremagic.com/issues/show_bug.cgi?id=5521 Just done it for my parser. Once you get the line nr... Maybe try ubyte[]? There are moments when I want an array of ubytes, other moments when I want an array of 8 bit chars, and other situations where I want a string of chars. An ubyte[] is a workaround for a type system not good enough yet. After some more interrogations on the topic, I think there should be 4 somewhat related types. * Bytes -- processing of data at plain binary/numeric level, no link to text (eg pixmap) * ByteString -- single-byte charset text (ascii, latin-X,...) On the implementation side, there no difference in data structure (not even code check like for D chars). But conceptually and semantically, these types are unrelated. (It would be a bit strange for me to process a pixmap using a type that exposes tons of text-processing functionality.) ByteString is, I guess, more or less what Steven proposed. * D' utf-8 string for i/O of unicode text without any manipulation (except concat). * A Text like what I proposed for unicode text manipulation, conceptually an array of univoque text-characters (an array of no-copy-slices into a normalised utf-8 string). Though, on the other hand, I've used the ncurses library which does this kind of thing. The number of function names is obscene, and the benefit is quite small. I agree that too many functions are going to give problems. But an a suffix is burden smaller than two names fully new. I like your proposal. But -a suffixes are no good, use -Array or array- prefix instead. I'm not convinced the parentheses are a big deal. (Hell, I've done lisp before... and kinda liked it. :P) Scala, Ruby, ML-class languages like Haskell, etc have means to reduce parentheses count. Reducing syntax noise in functional-style code is something that a lot of people wants (me too). I have used Scheme, but parentheses tire me after a while. Editors do that for you, don't they? Even for languages they don't know... (never been annoyed by paren counts, not even in Lisp-like slangs) Denis -- _ vita es estrany spir.wikidot.com
Filtering even numbers in various languages
https://gist.github.com/817504 I added a D version. Andrei
Re: Another Phobos2 test
On 02/09/2011 01:35 AM, bearophile wrote: I meant something different. I don't want to convert JSON tree from-to text, I'd like to bypass the text representation fully. So the compile-time JSON Phobos library returns a data structure that represents the JSON tree (created by the compiler) in memory. There are zero files, stdout, pipes and text streams. Just what I would like to rip from a D parser in D (which doesn't prevent to write it into a D source module if useful). Denis -- _ vita es estrany spir.wikidot.com
Re: Filtering even numbers in various languages
Andrei: https://gist.github.com/817504 I added a D version. Good :-) They have missed the lazy Python2.x version: (x for x in xrange(1, 5) if not x % 2) Bye, bearophile
Re: Windows API Translation
I don't know why I thought this would be easy. ReadDirectoryChangesW
is a b**ch to use. Someone even wrote a wrapper for it:
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
It clocks in at over 1500 lines. For a single API function. Yikes!
Compare this to .Net's FileSystemWatcher. Create an object, pass a
delegate, and get back some info: Console.WriteLine(File: {0} renamed
to {1}, e.OldFullPath, e.FullPath);
Your work is done.
With ReadDirectoryChangesW I have to keep count of bytes to skip
forward, use casts and keep separate pointers and length variables.
Not to mention the function is not fully documented as this long blog
post shows:
http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html
Re: Please reply to this to vote to collectExceptionMsg in std.unittests
On 02/08/2011 06:29 PM, David Nadlinger wrote: On 2/8/11 4:29 PM, Andrei Alexandrescu wrote: Reply here to vote ONLY for the function collectExceptionMsg in Jonathan M Davis's std.unittests. Vote closes on Tue Feb 15. As I stated in the assertNotThrown thread, I don't see any reason why this shouldn't be included if it's helpful for other people, even though I personally didn't feel the need for it so far. Since the main use case seems to be in unit tests to check if the correct exception messages are produced, I'd suggest adding a short note about that to the documentation comment – or is this going to end up in a new std.unittest module anyway? I thought it would be merged into std.exception… This is just one use case reason why me preferred assert idiom has the form assert ( expression, expectation) if expectation is a string --and the outcome isn't one-- then the outcome is to!string'ed. just what you need. Very useful too, in several other cases of outcomes (I mean only when throws, just regular results that are not easily expressible in code). Denis -- _ vita es estrany spir.wikidot.com
Re: Another Phobos2 test
bearophile: I see. I prefer to see a chunk of code that does something, on the screen, and to not scroll too much. That's what functions are for! I meant something different. I don't want to convert JSON tree from-to text, I'd like to bypass the text representation fully. Yes, that would be the ideal implementation. But as a practical matter, who's going to write that code? I don't know the compiler well enough to do it myself, but I am confident that I could write a little program to call and parse dmd -X; it's something we could do ourselves without bugging Walter. We need to look more at imperfect solutions we can do ourselves with the existing tools than the perfect solutions that need smart people like Walter and Don to do for us. It matters if you want to use the JSON data in a larghish program as a static reflection mean to implement good user defined attributes. The less you convert and parse data, the faster and more usable the whole game is. If the build tool was sufficiently smart (something as simple as plain old make is good enough for this), it could only parse the json once. Again not ideal, but something simple we could do ourselves. On user defined attributes, I wish the @attrs were done differently, but what's done is done and I don't know the compiler well enough to write a patch. Instead, we might look at some template ideas that define some enums we can use to access the attributes. As I understand it, Ruby does something similar to this too. I don't remember Andrei's opinion about that idea. It's been discussed on the Phobos list pretty recently. Look for the threads about new string types (I don't remember the exact subject, but Steven did a lot of work on it so searching for his name with the string keyword should find the thread.) If you start putting parentheses everywhere, you produce something less readable than Lisp. Gah, that Haskell already is significantly less readable to Lisp! Actually, on optional parens in D, I'm almost split on that. I resisted dropping them from templates at first, but now I love it. I like the property syntax just the way it is too (well, usually. It's annoying when it calls the function when I don't want it to though!)
Re: std.unittests/exception Update and Vote
On 02/09/2011 01:38 AM, Andrei Alexandrescu wrote: On 2/8/11 3:50 PM, Steven Schveighoffer wrote: On Tue, 08 Feb 2011 15:36:14 -0500, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vqk74auaeav7ka@steve-laptop... On Tue, 08 Feb 2011 06:52:30 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: *Sigh* I was hoping for a clearer vote than this. Sorry for the lack of voting/attention, I've had barely any time to work with D lately, and I haven't even looked at your lib. -Steve P.S. I'm f***ing sick of snow... I got sick of snow ten years ago. Makes me wonder why I'm still in Cleveland... I'd wonder why you were in Cleveland for a number of reasons ;) This is the worst winter I've ever experienced. My whole body aches from battling ice dams for weeks. There's few things worse than having to put on snow clothes still wet (and smelly) from yesterday to go up on a ladder in the rain and whack ice you cleared just yesterday because water is again seeping in your house... -Steve I'm completely weird I guess. I love snow and winter. I'm just back from a skiing day non-stop 11am to 4pm on the most difficult slopes (including two extreme terrain runs starting at 3963 meters). My water and food froze in my pockets. At times I could hardly feel my face. I still breathe twice the normal rate. Every cubic inch of my body aches. And... I'm loving every minute of it. Can understand you. But, by me (south-west of F) get about 15 °C these days... abnormal temperatures upwards, after having frozen as early as late October. Denis -- _ vita es estrany spir.wikidot.com
Re: High performance XML parser
On 02/09/2011 01:16 AM, Tomek Sowiński wrote: Steven Schveighoffer napisał: The design I'm thinking is that the node iterator will own a buffer. One consequence is that the fields of the current node will point to the buffer akin to foreach(line; File.byLine), so in order to lift the input the user will have to dup (or process the node in-place). As new nodes will be overwritten on the same piece of memory, an important trait of the design emerges: cache intensity. Because of XML namespaces I think it is necessary for the buffer to contain the current node plus all its parents. That might not scale well. For instance, if you are accessing the 1500th child element of a parent, doesn't that mean that the buffer must contain the full text for the previous 1499 elements in order to also contain the parent? Maybe I'm misunderstanding what you mean. Let's talk on an example: a name=value b Some Text 1 c2 !-- HERE -- Some text 2 /c2 Some Text 3 /b /a The buffer of the iterator positioned HERE would be: [Node a | Node b | Node c2] Node c2 and all its parents are available for inspection. Node a's attribute is stored in the buffer, but not b's Some text 1 as it is c2's sibling; Some text 1 was available in the previous iteration, now it's overwritten by c2. To get to Some text 2 let's advance the iterator in depth to get: [Node a | Node b | Node c2 | Text node Some text 2] Advancing it once more we get to: [Node a | Node b | Text node Some text 3] So Some text 3 is written where c2 and the text node 2 used to be. That's very similar to what I was thinking at. What I wonder is whether, in your buffer representations above, 'Node x' represents an instanciated node, or collected data necessary to later instanciate --once the current part of the source is validated (proved correct). What i mean is, the whole a node will be validated only when /a is matched, so that if your parsing process fails on the way (and/or it was just following a wrong parsing path), then all nodes instanciated along tha way are just to throw away, aren't they (unless some memoisation may be useful). Possibly all what say here is just stupid, depending on the parsing algo and nature of the grammar, and also how costly Node creation is. In my case, all of this seems relevant. Thus, I'm thinking at just collecting data along the way (rather easy far cheaper than node construction), and (recursively) instanciate only once a section is validated. (needs to be tried concretely --maybe there are issues I'm not yet aware of) Denis -- _ vita es estrany spir.wikidot.com
Re: Filtering even numbers in various languages
On 2/8/11 8:02 PM, Andrei Alexandrescu wrote: https://gist.github.com/817504 I added a D version. Andrei Added a comment too (andralex). Andrei
Re: Windows API Translation
On Tue, Feb 8, 2011 at 7:16 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I don't know why I thought this would be easy. ReadDirectoryChangesW
is a b**ch to use. Someone even wrote a wrapper for it:
http://www.codeproject.com/KB/files/directorychangewatcher.aspx
It clocks in at over 1500 lines. For a single API function. Yikes!
Compare this to .Net's FileSystemWatcher. Create an object, pass a
delegate, and get back some info: Console.WriteLine(File: {0} renamed
to {1}, e.OldFullPath, e.FullPath);
Your work is done.
With ReadDirectoryChangesW I have to keep count of bytes to skip
forward, use casts and keep separate pointers and length variables.
Not to mention the function is not fully documented as this long blog
post shows:
http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html
Honestly, API-wise, it feels a lot like most of the Posix C APIs (I'm
using iNotify on Linux for this already), but less polished. That bit
about missing events though, that's pretty crappy.
And I love how their docs imply that you can somehow use it with
FindFirstChangeNotification.
From reading about the performance problems, it seems that the lovely
thin layer I built on iNotify on Linux might have to have to become a
multithreaded heavy backend on Windows. Ah well.
Stupid little iota of an idea
AUIU, foreach has both of these forms: foreach(x; 0..5) foreach(x; someRange) Also, we have: auto someRange = iota(0, 5); Little idea: How about this genralized lowering? 0..5 // iota says Gimme some sugar, baby. // and thus it is lowered to - iota(0, 5) Of course, if that hinders optimization for foreach(x; 0..5), then the compiler could just optimize that particular case by not bothering with the lowering and doing as it currently does. But the benefit is things like this: // Stealing Andrei's filter even example: filter!`a % 2 == 0`(iota(1, 5)) // Give iota some sugar, baby: filter!`a % 2 == 0`(1..5) I suppose the obnoxious float-literal definition could get in the way, but when is it ever legal syntax in D to have two numeric literals next to each other? (And foreach seems ok with it anyway) Pardon if this has already been suggested.
Re: More on the necessity and difficulty of a package management system
On 01/26/11 16:45, Andrei Alexandrescu wrote: Seems to be unduly difficult in Python: http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps We need to have a good solution for D. Andrei This seems related to a project I've been planning on: https://sites.google.com/site/dagazpreview/home Now if I could just find a little more spare time and get the be-damned thing's design finished and the code written. -- Chris N-S
Re: Writing XML
On Wed, 2011-02-09 at 00:16 -0600, Christopher Nicholson-Sauls wrote: [ . . . ] xml.book(...) as sugar for xml.tag(book,...) make it xml.bookTag(...) using xml.bookTag would ruin it for me. I'd use something that allowed just book, xml.book is already not enough of a DSL. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Stupid little iota of an idea
On 9/02/11 3:08 AM, Nick Sabalausky wrote: AUIU, foreach has both of these forms: foreach(x; 0..5) foreach(x; someRange) Also, we have: auto someRange = iota(0, 5); snip Pardon if this has already been suggested. I have suggested it in the past, and I believe people had suggested it before me. I agree, it does make perfect sense to add that syntax, although it probably shouldn't be tied into Phobos (maybe add a druntime version of iota?)
Operator overloading giving encrypted error messages.
Hi, all. I'm playing around with a BigRational struct to get more comfortable
with D.
The plan:
Allow binary operators so that a BR (BigRational) is the lhs and one of {BR,
BigInt, int, long} is the rhs.
So BR(5) + 2 compiles just as well as BR(5)+BR(2)
Here's the opBinary code I've worked out:
BigRational opBinary(string op,T)(T arg){
BigRational y = BigRational(arg);
static if(op == +){
BigRational temp = this;
}}} /// and so on, ending with an assert(0) after all the static ifs.
So, unit testing this with
auto br1 = BigRational(25,2);
writefln(br1+1 = %s,br1+1);
works beautifully.
Now, I'd like to define the ++ to increase this by 1.
So, I write:
BigRational opUnary(string op)(){
static if(op == ++){
this = this+1;
return this;
//There are other overloads, too.
}}
Now, when I unittest
writefln(br1++ = %s, br1++); //This is line 166.
I get a weird error message:
C:\DProjects\BigRational\srcdmd BigRational.d -unittest
BigRational.d(166): Error: template BigRational.BigRational.opBinary(string op,T
) does not match any function template declaration
BigRational.d(166): Error: template BigRational.BigRational.opBinary(string op,T
) cannot deduce template function from argument types !()()
My issue here is that I have already used the exact same syntax in the first
unit test as my code for the ++ overload has, but here it fails me. (Plus, why
is line 166 having trouble with opBinary? ++ is unary, no?
Any ideas?
Thanks,
Charles.
begin 644 BigRational.d
M:6UP;W)T('-T9YB:6=I;G0[#0II;7!OG0@W1D+G-TFEN9SL-FEM]R
M=!S=0NW1D:6\[#0II;7!OG0@W1D+FUA=@[#0HO+T$@9\M;F]T:EN
M9R!M86EN+!T;R!M86ME('1H92!C;VUP:6QEB!H87!P2X@5AEF4@:7,@
M82!W87D@=\@;6%K92!A(1L;!OB!S;VUE=AI;FL()U=!))VQL('-T
M:6-K('=I=@@86X@97AE+B`-B\O5\@8V]MEL92!A;F0@G5N('1EW1S
M+!D;60@0FEG4F%T:6]N86PN9`M=6YI='1EW0-G9O:60@;6%I;B@IPT*
M?0T*#0HO*BH-D$@0FEG4F%T:6]N86PN(%!EF9OFUS(%R8FETF%R2UP
MF5C:7-I;VX@87)I=AM971I8R!O;B!N=6UB97)S(`T*=VET:!N=6UEF%T
M;W)S(%N9!D96YO;6EN871OG,N(`T*075T:]R.B!#:%R;5S($UC06YA
M;GDN#0HJ+PT*W1R=6-T($)I9U)A=EO;F%LPT*')I=F%T93H-@E:6=)
M;G0@;G5M97)A=]R.PT*4)I9TEN=!D96YO;6EN871OCL-@D-@DO+R]#
M86QC=6QA=5S('1H92!G8V0@;V8@='=O($)I9TEN=',L('5S:6YG($5U8VQI
M9=S(%L9V]R:71H;2X-@E:6=);G0@9V-D*$)I9TEN=!I;G0Q+!:6=)
M;G0@:6YT,BE[#0H)6EF(AI;G0R(#T](#`I#0H)0ER971UFX@:6YT,3L-
M@D)F5T=7)N(=C9AI;G0R+EN=#$@)2!I;G0R*3L-@E]#0H-@DO+R]!
MW-U;65S('1H870@8F]T:!V86QU97,@87)E('!OVET:79E+@T*4)I9TEN
M=!L8VTH0FEG26YT(EN=#$L($)I9TEN=!I;G0R*7L-@D)F5T=7)N(EN
M=#$J:6YT,B]G8V0H:6YT,2QI;G0R*3L-@E]#0H)#0H)=F]I9!S:6UP;EF
M4UE*E[#0H)2\O1FERW0L(-H96-K(9OB!Z97)ORX@#0H)6EF(AD
M96YO;6EN871OB`]/2`P*7L-@D)71HF]W(YE=R!%-E'1I;VXH(D1I
M=FED92!B2!Z97)O(BD[#0H)7T-@D):68H;G5M97)A=]R(#T](#`IPT*
M0D);G5M97)A=]R(#U:6=);G0H,D[#0H)0ED96YO;6EN871OCT@0FEG
M26YT*#$I.PT*0E]0T*0DO+TEF('1H92!D96YO;6EN871OB!IR!N96=A
M=EV92P@9FQI!T:4@;F5G871I=F4N(`T*0EI9B`H95N;VUI;F%T;W(@
M/`P*7L-@D)61E;F]M:6YA=]R*CT@+3$[#0H)0EN=6UEF%T;W(J/2`M
M,3L)#0H)7T-@D)0FEG26YT(-O;6UO;D9A8W1OB`](=C9AN=6UEF%T
M;W(L95N;VUI;F%T;W(I.PT*0EN=6UEF%T;W(@+ST@8V]M;6]N1F%C=]R
M.PT*0ED96YO;6EN871OB`O/2!C;VUM;VY86-T;W([#0H)?0T*0T*'5B
M;EC.B`-@D-@T*71H:7,H5#$@/2!:6=2871I;VYA;P@5#(@/2!:6=2
M871I;VYA;DH0FEG4F%T:6]N86P@;G5M+!:6=2871I;VYA;!D96XIPT*
M0EA=71O(')ER`](YU;2]D96X[#0H)7-E=%5P4W1A=4HF5S+FYU;65R
M871OBQR97,N95N;VUI;F%T;W(I.PT*7T-@D-@D-@ET:ES*%0Q(#T@
M0FEG26YT+!4,B`]($)I9TEN=DH0FEG26YT(YU;2P@0FEG26YT(1E;BE[
M#0H)7-E=%5P4W1A=4H;G5M+1E;BD[#0H)?0T*0T*71H:7,H5#$@/2!S
M=')I;FL(%0R(#T@W1R:6YG*2AS=')I;F@;G5M+!S=')I;F@95N*7L-
M@D)V5T57!3=%T92A:6=);G0H;G5M*2Q:6=);G0H95N*2D[#0H)?0T*
M0T*71H:7,H5#$](QO;FL(%0R/6QO;FI*QO;F@;G5M+!L;VYG(1E
M;BE[#0H)7-E=%5P4W1A=4H0FEG26YT*YU;2DL0FEG26YT*1E;BDI.PT*
M7T-@D-@EV;VED('-E=%5P4W1A=4H0FEG26YT(YU;2P@0FEG26YT(1E
M;BE[#0H)71H:7,N;G5M97)A=]R(#T@;G5M.PT*0ET:ES+F1E;F]M:6YA
M=]R(#T@95N.PT*0ES:6UP;EF4UE*D[0D-@E]#0H)#0H)=AIRA4
M+$4I*%0@;G5M+!%(1E;BD-@EI9B@A:7,H5`]/2!%*2E[#0H)6%U=\@
M=AE3G5M(#T@0FEG4F%T:6]N86PH;G5M*3L-@D)875T;R!T:5$96X@/2!
M:6=2871I;VYA;AD96XI.PT*0EA=71O(')ER`]('1H94YU;2]T:5$96X[
M#0H)7-E=%5P4W1A=4HF5S+FYU;65R871OBQR97,N95N;VUI;F%T;W(I
M.PT*7T-@D-@ET:ES*%0@/2!:6=2871I;VYA;DH0FEG4F%T:6]N86P@
MW1AG0IPT*0ES9715%-T871E*'-T87)T+FYU;65R871OBP@W1AG0N
M95N;VUI;F%T;W(I.PT*7T-@D-@D-@ET:ES*%0I*%0@;G5M*0T*6EF
M*%IRA4(#T]($)I9U)A=EO;F%L*2E[#0H)4)I9TEN=!T:5.=6T[#0H)
M7-T871I8R!I9B`H(6ES*%0@/3T@0FEG26YT*2E[#0H)0ET:5.=6T@/2!
M:6=);G0H;G5M*3L-@D)?65LV5[#0H)0ET:5.=6T@/6YU;3L-@D)?0T*
M0ES9715%-T871E*'1H94YU;2Q:6=);G0H,2DI.PT*7T-@D-@DO+U-T
MF5SR!T:4@8V]NW1R=6-T;W)S+B`-@EU;FET=5S='L-@D)0FEG4F%T
M:6]N86P@8G(Q(#T@0FEG4F%T:6]N86PH(C$R,S0B+(R-2(I.PT*0E:6=2
M871I;VYA;!BC(@/2!:6=2871I;VYA;A:6=);G0H,C,T-2DI.PT*0EA
MW-EG0H8G(R(#T](#(S-#4I.PT*0E:6=2871I;VYA;!BC,@/2!:6=2
M871I;VYA;@B,3(S-#4V-S@Y,#DX-S8U-#,R,3(S-#4V-S@Y.#V-30S,C,T
M-38W.#V-30S,C,T-38W.#V-30S(BPB,C,T-38W-C4T,S(S-#4V-30S-#4V
M-30S,C,T-38W.#V-30S(BD[#0H)4)I9U)A=EO;F%L()R-`]($)I9U)A
M=EO;F%L*)R,2Q:6=);G0H,C`P,DI.PT*0E:6=2871I;VYA;!BC4@
M/2!:6=2871I;VYA;ABC$L8G(R*3L-@D)875T;R!BC8@/2!:6=2871I
Re: Operator overloading giving encrypted error messages.
It sees the post-increment fires the opBinary template too. I think this is a front-end bug, for Bugzilla if confirmed and not already present. http://d.puremagic.com/issues/show_bug.cgi?id=5551
[Issue 4092] broken memory management for COM objects derived from IUnknown
http://d.puremagic.com/issues/show_bug.cgi?id=4092
--- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2011-02-08 00:41:49
PST ---
The problem with allocating COM objects from the C-heap is that they cannot be
free'd inside Release() due to possible invariants being called after that.
Here's the implementation of Release in std.c.windows.com:
ULONG Release()
{
LONG lRef = InterlockedDecrement(count);
if (lRef == 0)
{
// free object
// If we delete this object, then the postinvariant called upon
// return from Release() will fail.
// Just let the GC reap it.
//delete this;
return 0;
}
return cast(ULONG)lRef;
}
The comment even implies that the memory should be taken from the GC.
Also, any object that has references into other memory blocks needs to add
itself as a root to the GC, which can be very easily forgotten (e.g. if the
references are just strings).
As reported lately, the juno project
(http://www.dsource.org/projects/juno/wiki, probably the largest project trying
to embrace COM), works similar as proposed here. (
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=128956
)
Agreed, changing this might break some code, but probably most applications
creating COM objects have overloaded new anyway.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5546] Assigning and initializing structs from functions make more copies than necessary
http://d.puremagic.com/issues/show_bug.cgi?id=5546 --- Comment #2 from akb...@gmail.com 2011-02-08 00:42:20 PST --- After thinking about the problem a bit more, I have a couple things to add. First, I should mention my second point for assigning the return value of a function to an existing struct applies to all temporaries. Test testVal; testVal = Test(str); can benefit from the same optimizations as Test testVal; testVal = function(); Second, it would be very useful to be able to mark the custom assignment operator to have the same behavior on the above two cases as if there is no overloaded assignment operator. (aka: skip the assignment and reduce it to a blit + post blit and destruction of the old value when assigning from a temporary) I would suggest something like putting @ignoreIfTemp before the opAssign definition, and would be ignored if members of the struct have custom assignment operators without that property. This would allow one of the most useful benefits of rvalue references from C++0x to be used without having to add a whole new type qualifier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1170] Cannot forward reference a type defined in a MixinStatement
http://d.puremagic.com/issues/show_bug.cgi?id=1170 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #8 from Don clugd...@yahoo.com.au 2011-02-08 04:37:34 PST --- The test case in comment 7 was fixed in 2.051 and 1.066. The original test case still doesn't work. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|patch | CC||clugd...@yahoo.com.au --- Comment #5 from Don clugd...@yahoo.com.au 2011-02-08 05:00:41 PST --- Removing patch keyword since it doesn't have a patch :o -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5547] Improve assert to give information on values given to it when it fails
http://d.puremagic.com/issues/show_bug.cgi?id=5547 --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2011-02-08 10:57:27 PST --- Is it too difficult for this to apply only inside unit tests? I mean literally within unit test blocks. This means asserts triggered in non-unit test blocks will not report the extra info, even if called from a unit test block. But I believe this is equivalent to the original proposal of assertPred (which would only be used inside unittest blocks). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
