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