Re: Google C++ needs for Clang
Adam D. Ruppe wrote: D/DMD is not modern/intelligent/good enough to catch this common error yet, this gives no errors nor warnings in D2: If you write the literal though, you do get the error: int kMaxDiskSpace = 10737418240; test66.d(6): Error: cannot implicitly convert expression (10737418240L) of type long to int This might be a bug in the compiler's constant folding, since it catches one form but not the other. The other two errors in that blog are done by D right now, despite it being obsolete, stupid, and not good enough yet. Range propagation is not implemented yet, except for a couple of simple cases. (Bearophile -- do you actually know that? You've made many posts on similar topics, which suggest all sorts of problems, but it's just not implemented yet).
Re: Why does D suck so bad?
http://www.youtube.com/watch?v=dQw4w9WgXcQ The answers lie within.
Re: Decimal Arithmetic
Paul D. Anderson wrote: I've got a D programming language implementation of the General Decimal Arithmetic specification (http://speleotrove.com/decimal/) that's' more or less complete* and am wondering if it would be useful. I worked on this over a year ago but life got in the way, so I neglected it for a time. I now have the time to finish it. It uses std.bigint as the basis for the decimal numbers. I know there are plans to bring BigFloat, decimal32, decimal64, and decimal128 numbers into D. The completed* portion of the code fills the role of BigFloat (although I called it Decimal), and I've got routines that encode/decode the dec32, etc. numbers but they're not as far along as the arbitrary precision version. I guess my question is whether I'm repeating work that's been done or is being done in this area? If so, maybe I can lend a hand. If not, I'd like some feedback on what is needed so I can work on the important things first. Let me know what you think. At this point I'd settle for a go/nogo decision. We can work bikeshed stuff later. Go! We definitely want to get this into Phobos. Thanks, Paul *"more or less complete" == It passes all the tests built in to the spec. No logical operators or exp/ln/power. Still needs work. I suppose it could be called an alpha version.
Re: Why does D suck so bad?
On 5/24/2011 3:33 PM, Bernard Helyer wrote: http://www.youtube.com/watch?v=dQw4w9WgXcQ The answers lie within. Yes. Legacy may be the burden of D. But problem started with C is taught so far and wide into the school system(70-90). Rarely other languages are used. Even when MS/Sun/Google had to mimic some feature from within that family group. C/C++ is in school, OS, Hardware TGINC(Thank God is NOT Cobol) Or many more developers will have figures injuries... -- Matthew Ong email: on...@yahoo.com
Re: [OT] Re: There's new GIT instructions on Github now
Nick Sabalausky Wrote: > The way I see it, msys and mingw are total pains in the ass that should > never be forced on anyone regardless of whether they're just using a program > or compiling it (and cygwin's even worse). If someone wants to use it > themself, then fine, but that garbage should never be forced on anyone. Didn't use msys, but stock mingw+make work just fine for me (I've made some contributions to scintilla and use them for my projects). What's your problem?
Re: Decimal Arithmetic
On 24/05/2011 08:34, Don wrote: Paul D. Anderson wrote: I've got a D programming language implementation of the General Decimal Arithmetic specification (http://speleotrove.com/decimal/) that's' more or less complete* and am wondering if it would be useful. I worked on this over a year ago but life got in the way, so I neglected it for a time. I now have the time to finish it. It uses std.bigint as the basis for the decimal numbers. I know there are plans to bring BigFloat, decimal32, decimal64, and decimal128 numbers into D. The completed* portion of the code fills the role of BigFloat (although I called it Decimal), and I've got routines that encode/decode the dec32, etc. numbers but they're not as far along as the arbitrary precision version. I guess my question is whether I'm repeating work that's been done or is being done in this area? If so, maybe I can lend a hand. If not, I'd like some feedback on what is needed so I can work on the important things first. Let me know what you think. At this point I'd settle for a go/nogo decision. We can work bikeshed stuff later. Go! We definitely want to get this into Phobos. Thanks, Paul *"more or less complete" == It passes all the tests built in to the spec. No logical operators or exp/ln/power. Still needs work. I suppose it could be called an alpha version. Go
What are the reasons for this syntax??
Hi ALL,
Refering to these 2 URL:
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/FileOutputStream.d
// why the public here?
6 public import java.io.File;
7 public import java.io.OutputStream;
9 import java.lang.all; // I can understand this here.
13} else { // Phobos
// Why the import needed static?
14 static import std.file;
15 static import std.path;
16}
// What is the purpose of using alias here?
20 alias java.io.OutputStream.OutputStream.write write;
21 alias java.io.OutputStream.OutputStream.close close;
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d
8 alias java.io.InputStream.InputStream.read read;
9 alias java.io.InputStream.InputStream.skip skip;
10 alias java.io.InputStream.InputStream.available available;
11 alias java.io.InputStream.InputStream.close close;
12 alias java.io.InputStream.InputStream.mark mark;
13 alias java.io.InputStream.InputStream.reset reset;
14 alias java.io.InputStream.InputStream.markSupported markSupported;
Thanks very much.
--
Matthew Ong
email: on...@yahoo.com
Re: What are the reasons for this syntax??
Hi Mathew,
I'm always happy to see people enthusiastic about D, but please keep in
mind that posting the same question multiple times is generally
considered impolite on newsgroups and mailing lists.
Furthermore, you were right about posting to dm.D.learn and not here, as
the issues are clearly described in the docs:
http://www.digitalmars.com/d/2.0/module.html#ImportDeclaration
http://d-programming-language.org/hijack.html
David
On 5/24/11 12:59 PM, Matthew Ong wrote:
Hi ALL,
Refering to these 2 URL:
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/FileOutputStream.d
// why the public here?
6 public import java.io.File;
7 public import java.io.OutputStream;
9 import java.lang.all; // I can understand this here.
13} else { // Phobos
// Why the import needed static?
14 static import std.file;
15 static import std.path;
16}
// What is the purpose of using alias here?
20 alias java.io.OutputStream.OutputStream.write write;
21 alias java.io.OutputStream.OutputStream.close close;
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d
8 alias java.io.InputStream.InputStream.read read;
9 alias java.io.InputStream.InputStream.skip skip;
10 alias java.io.InputStream.InputStream.available available;
11 alias java.io.InputStream.InputStream.close close;
12 alias java.io.InputStream.InputStream.mark mark;
13 alias java.io.InputStream.InputStream.reset reset;
14 alias java.io.InputStream.InputStream.markSupported markSupported;
Thanks very much.
Re: Should binary sharing be done using Mixin Template?
On 21.05.2011 13:03, Jonathan M Davis wrote: Templates are completely different from generics. Generics are compile-time artifacts only and have no effect on the final binary. Templates, on the other hand, are generated for each type that they're instantiated with. Only if you are speaking about Java. In Eiffel, Ada, Modula-3 Ocaml, Haskell, and .Net generics are also handled like C++ templates. They just don't allow the same type of metaprogramming tricks that C++ does, although Template Haskell does allow neat tricks as well. -- Paulo
Re: Building DMD on Linux with Windows Domain Logins
On 05/24/2011 12:34 AM, KennyTM~ wrote: On May 24, 11 12:55, Walter Bright wrote: On 5/23/2011 4:10 PM, KennyTM~ wrote: On May 24, 11 06:37, Kai Meyer wrote: Funny thing happened today. I tried building DMD from source, and got this: dmd: libelf.c:171: void OmToHeader(Header*, ObjModule*): Assertion `len <= 6' failed. Digging around, and it appears that my user ID can only be 6 characters long. Doh! I happen to be on a RHEL 6 workstation that can authenticate users via a Windows Domain Controller (using samba + winbind). My smb.conf looks has these two lines: idmap uid = 16777216-33554431 idmap gid = 16777216-33554431 Which is to say "If a uid or gid appears on the system, use winbind to resolve to a name". On my machine, my user looks like this: [kai.meyer@kai-rhel6 BUILD]$ id uid=16777216(kai.meyer) gid=16777221(domain users) groups=16777221(domain users),16777223(SENSORED),16777224(SENSORED),16777225(SENSORED),16777226(SENSORED) That's right. My UID is 8 characters long. Are we interested in accommodating UID and GID's that are this big? -Kai Meyer An old bug (e.g. http://www.mail-archive.com/dmd-internals@puremagic.com/msg00402.html). The 'uid' > 6 digit problem has been worked-around, but the 'gid' hasn't. Post to bugzilla! http://d.puremagic.com/issues/show_bug.cgi?id=6050 On the bright side, the rpm builds on RHEL6 with no problems if I build it with a UID/GID of 500 :) -Kai Meyer
Re: Google C++ needs for Clang
Don wrote: > Range propagation is not implemented yet, except for a couple of > simple cases. I didn't realize that... those simple cases seem to do a fairly decent job!
Re: map kinds of Ranges
On 24/05/2011 04:28, Jonathan M Davis wrote: Thoughts on this? I believe that the best and most likely to be implemented syntax which has been suggested (it was Andrei's idea IIRC) is to simply add optional clauses to attributes. So, instead of pure, you'd do pure(condition). If the condition is true, the templated function it's on is pure. If the condition is false, then the function isn't pure. Don't expect pure to become @pure or nothrow to become @nothrow though. I think that at this point, any attribute which is a keyword is going to stay one, and any attribute that has @ on the front of it is going to stay that way as well. - Jonathan M Davis Wouldn't it make sense to follow the same syntax as auto ref? auto pure, auto nothrow, auto @safe etc? (Although I guess that doesn't allow for conditions, nevermind :<) -- Robert http://octarineparrot.com/
Re: Decimal Arithmetic
filgood Wrote: > On 24/05/2011 08:34, Don wrote: > > Go! We definitely want to get this into Phobos. > > > Go D, Definitely.
Re: Decimal Arithmetic
Dial D for D Decimal Arithmetic.
Re: map kinds of Ranges
On May 25, 11 01:25, Robert Clipsham wrote:
On 24/05/2011 04:28, Jonathan M Davis wrote:
Thoughts on this?
I believe that the best and most likely to be implemented syntax which
has
been suggested (it was Andrei's idea IIRC) is to simply add optional
clauses
to attributes. So, instead of pure, you'd do pure(condition). If the
condition
is true, the templated function it's on is pure. If the condition is
false,
then the function isn't pure. Don't expect pure to become @pure or
nothrow to
become @nothrow though. I think that at this point, any attribute
which is a
keyword is going to stay one, and any attribute that has @ on the
front of it
is going to stay that way as well.
- Jonathan M Davis
Wouldn't it make sense to follow the same syntax as auto ref? auto pure,
auto nothrow, auto @safe etc? (Although I guess that doesn't allow for
conditions, nevermind :<)
public auto pure auto nothrow auto @safe auto ref front() const {
return f(x.front);
}
:p
Actually I believe the point of having conditional attribute is to get
the most restrictive one, where auto-attribute fit in better than the
more generalized alternative.
Or we could just have an 'auto' condition to let the compiler choose the
most restrictive one.
public pure(auto) nothrow(auto) @safe(auto) auto ref front() const {
return f(x.front);
}
(still way too long :p)
Re: Implementing std.log
Just wanted to let everyone know that I am working on having a review
wordy std.log. I am almost done with the implementation. I am
currently working on improving the documentation. Is there a link that
describes the review process. I would like to get std.log as close to
final to minimize the back and forth.
Also, I will reply to the rest of Andrei's email and Jens's email when
we have something to look at (the code and doc in github).
Thanks,
-Jose
On Wed, May 18, 2011 at 1:09 PM, Andrei Alexandrescu
wrote:
> On 5/18/11 8:00 AM, Jose Armando Garcia wrote:
>>
>> I also think that having competing logging module is a good thing.
>> This process will result in a better module for phobos and as a result
>> a better module for the user.
>
> Clearly there are advantages to competing proposals, but I have mixed
> feelings about the whole thing, with the negative probably being stronger
> than the positive.
>
> At the end of the day one of us will have their work go to waste. Generally
> nobody wants their work to go to waste, and in particular I think I'd harm
> the community's interests by working on redundant stuff when so many other
> things are in need of attention. The reason I started std.log was out of
> desperation that everybody wanted to talk about it instead of working on it,
> and because I figured nobody would implement it the way I thought it needs
> to be done anyway. That's why I wrote on Apr 21st:
>
>> Again, I'd _much_ rather prefer if someone just implemented this:
>>
>> http://google-glog.googlecode.com/svn/trunk/doc/glog.html
>>
>> It's simple, to the point, and brings the bacon home.
>>
>> In fact I'm putting dibs on this. I'll implement the thing and make a
>> proposal.
>
> That message was meant to prevent exactly what's happening now. Honestly it
> hurts me that of all things possible, a new and talented contributor (two,
> to count Jacob's effort on his prototype) chose to work squarely on this one
> artifact.
>
> Right now the two APIs are converging and start differing in minor details,
> which makes it painfully obvious that at the end of the day two people are
> working in separation on virtually identical code. I can't afford this.
>
> I am ceasing work on std.log (feel free to copy from my code) and I
> encourage you to work towards a formal proposal. In doing that, I'll be
> upfront in saying that I'll very strongly advocate staying close to the
> client interface of std.log as it is now. In particular, every departure
> from glog (to which both designs now owe a lot) for equivalent functionality
> is gratuitous unless thoroughly justified. In detail:
>
> * initializeLogging(SharedLogger.getCreator(args[0])); adds too much
> cognitive load, literally at line one. Now I need to know what a shared
> logger is and what a creator is. Just pass the entire command line and let
> the log subsystem pick its parameters. Don't use a delegate unless you can't
> do without. If client code wants to do configuration work, give them
> functions, don't ask them for a callback. The callback complicates things
> for no reason.
>
> * The name initializeLogging is a gratuitous departure from glog. Use
> initLogging.
>
> * Keep the glog flags as they are. In all likelihood any user of glog would
> want to define such flags, so we may as well spare them the work.
>
> * Pick the logging directory like glog does.
>
> * Add programmatic setting of flag names and values before calling
> initLogging. I think that's a good idea that doesn't depart from glog's
> design (google cmdline parser uses global names a la FLAGS_xxx). That would
> allow users to change a flag's name or disable it entirely (by assigning
> null to them). Assigning to a flag's value prior to calling initLogging
> would change its default. Assigning to a flag's value after initLogging
> forces the flag. To simply prevent log to get to any flags, client can call
> initLogging(args[0 .. 1]).
>
> * The obvious action to do with a log is to write to it. I don't want to
> write:
>
> log!info.write(stuff);
>
> I want to write:
>
> logInfo(stuff);
>
> or, fine,
>
> log!info(stuff);
>
> * The names LOGGING_FATAL_DISABLED etc. are gratuitous departures from glog.
> Do what glog does adapted to D's naming convention, hence strip_log_xxx.
>
> * I don't want to write
>
> log!info(args.length > 1).write("Arguments: ", args[1 .. $]);
>
> Putting the condition there makes no sense without the manual. I want to
> write
>
> logInfo.when(args.length > 1)("Arguments: ", args[1 .. $]);
>
> or
>
> log!info.when(args.length > 1)("Arguments: ", args[1 .. $]);
>
> which omits the obvious "write" but adds the non-obvious "when".
>
> * Factoring out every, first, etc. is an interesting idea but I found no use
> for it outside logging. (That doesn't mean there isn't any, it just means we
> should think of it because cool things may happen.) That shouldn't harm
> except when combined with the point above we're forced to:
>
> logInfo.when(every(1000))("text");
Re: Why does D suck so bad?
== Quote from Bernard Helyer (b.hel...@gmail.com)'s article > http://www.youtube.com/watch?v=dQw4w9WgXcQ > The answers lie within. "This video is not available in your country. Learn more. Sorry about that." I've got no idea what the video is about and the YouTube page doesn't offer any clue.
Re: Why does D suck so bad?
Am 24.05.2011 22:54, schrieb %u: > == Quote from Bernard Helyer (b.hel...@gmail.com)'s article >> http://www.youtube.com/watch?v=dQw4w9WgXcQ >> The answers lie within. > > "This video is not available in your country. Learn more. Sorry about that." > > I've got no idea what the video is about and the YouTube page doesn't offer > any clue. I think it's the same video as this one: http://www.youtube.com/watch?v=XZ5TajZYW6Y
Re: Why does D suck so bad?
On 5/24/11, Daniel Gibson wrote: > I think it's the same video as this one: > http://www.youtube.com/watch?v=XZ5TajZYW6Y > Now it will seem like *you* are trolling him. Haha. :P
Re: Why does D suck so bad?
Am 24.05.2011 22:59, schrieb Andrej Mitrovic: > On 5/24/11, Daniel Gibson wrote: >> I think it's the same video as this one: >> http://www.youtube.com/watch?v=XZ5TajZYW6Y >> > > Now it will seem like *you* are trolling him. Haha. :P He could just google the original URL ;)
Re: Why does D suck so bad?
On Tue, 24 May 2011 03:33:35 -0400, Bernard Helyer wrote: http://www.youtube.com/watch?v=dQw4w9WgXcQ The answers lie within. This took me a while to figure out. This is freaking hilarious, I've never heard of it. I will definitely use this sometime :D -Steve
append to immutable array segfaults - anyone else seen it?
One of my apps, seemingly at random, started crashing today. The
part at fault looked mostly like this:
===
immutable(string[])[] records;
foreach(immutableData; inputSource)
records ~= [immutableData[1], immutableData[0]];
===
Nothing really fancy there except most everything was immutable. It
worked fine for a while. All my attempts to reduce it to a small
test case fail; the code works there too.
But, for some reason, the live code failed.
Looking into a debugger told me the segfault happened on lifetime.d
line 1967 in druntime:
/**
* The old way, obsolete.
*/
extern (C) void* _d_arrayliteralT(TypeInfo ti, size_t length, ...)
{
auto sizeelem = ti.next.tsize();// array element size
void* result;
It crashes on the array element size line. Neither ti nor ti.next
were null - both appeared to be valid references.
I changed from an array literal to a temporary object, and got
the same segfault, although in a different function. This, time,
it was here:
/**
* Append y[] to array x[]
*/
extern (C) void[] _d_arrayappendT(TypeInfo ti, ref byte[] x, byte[] y)
{
auto length = x.length;
auto sizeelem = ti.next.tsize();// array element size
Since the problem was consistently related to typeinfo, I did a hack
fix:
===
string[][] records;
foreach(immutableData; inputSource)
records ~= cast(string[]) [immutableData[1], immutableData[0]];
===
That is: I casted away immutable, and everything works now.
The reason I'm in the newsgroup rather than the bugzilla is I really
have no idea what's going on here. Since I can't recreate it
in a minimal test, that makes it all the harder.
Of all the D2 features, I've had the most trouble, by far, with
immutable array typeinfos randomly disappearing...
Has anyone else seen this? While my cast papers over the immediate
problem, I'd really like to get to the bottom of it and fix it
permanently.
If no one else has seen it, it might be a bug in my code, memory
corruption or something, but it seems awfully unlikely that memory
corruption would always hit a typeinfo structure like I've seen.
Re: append to immutable array segfaults - anyone else seen it?
On Tue, 24 May 2011 18:02:19 -0400, Adam D. Ruppe
wrote:
One of my apps, seemingly at random, started crashing today. The
part at fault looked mostly like this:
===
immutable(string[])[] records;
foreach(immutableData; inputSource)
records ~= [immutableData[1], immutableData[0]];
===
Nothing really fancy there except most everything was immutable. It
worked fine for a while. All my attempts to reduce it to a small
test case fail; the code works there too.
But, for some reason, the live code failed.
Looking into a debugger told me the segfault happened on lifetime.d
line 1967 in druntime:
/**
* The old way, obsolete.
*/
extern (C) void* _d_arrayliteralT(TypeInfo ti, size_t length, ...)
{
auto sizeelem = ti.next.tsize();// array element size
void* result;
It crashes on the array element size line. Neither ti nor ti.next
were null - both appeared to be valid references.
Are you doing anything with dynamic libraries? I think that dynamic
libraries can have their own copies of the typeinfo, which might be
invalid if you unload the library.
I can't think of any other reason why a typeinfo would "go away". There's
always the possibility of memory corruption.
-Steve
Re: append to immutable array segfaults - anyone else seen it?
Steven Schveighoffer: > Are you doing anything with dynamic libraries? None, except for the standard C library. It's pretty puzzling.
Re: append to immutable array segfaults - anyone else seen it?
On Tue, 24 May 2011 18:26:52 -0400, Adam D. Ruppe wrote: Steven Schveighoffer: Are you doing anything with dynamic libraries? None, except for the standard C library. It's pretty puzzling. Considering that the functions work in some cases and not in others, it's probably a corruption issue. All I can say is, try to isolate *when* the corruption occurs. What I'd recommend is printing the contents of the typeinfo at the beginning of the program, then examine them after the corruption. See if you can spot a difference. I've done things like start a thread that continuously monitors a specific memory location to see if it ever changes, and then break on that check. Then look at the main thread to see what it is doing. These bugs suck, sorry you got one. -Steve
Re: DustMite, a D test case minimization tool
On Tue, 24 May 2011 00:04:39 +0300, Robert Clipsham wrote: On 20/05/2011 23:01, Vladimir Panteleev wrote: I've tested it with a self-induced "bug" in std.datetime, it seems to work great. If you find that it breaks on something, let me know. Wow, this tool works fantastically! Narrowed down a 5000 line test case to about 80 lines (I've managed to get it down to 26 lines by removing comments/make semantic changes there's no way it would be able to do without some sort of semantic analysis). I'd note that the code wasn't the most simple either, involving templates, mixins, ctfe, objects, etc. A couple of notes that we've already discussed, but I'll paste here for others: * The tool spent about 10 minutes figuring out if it was ok to delete files in .git, then deleting them - this pretty much doubled the time taken to run the tool! * It took me a while to figure out, the test command is run from the directory you pass on the command line. You also score bonus points for being far simpler to set up than delta, and working *a lot* better than it (for D at least, I haven't tried it with anything else). Well done. Thanks! I've improved it based on your and others' feedback, and wrote some documentation: https://github.com/CyberShadow/DustMite/wiki -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Decimal Arithmetic
Paul D. Anderson Wrote: > Let me know what you think. At this point I'd settle for a go/nogo decision. > We can work bikeshed stuff later. > > Thanks, > > Paul > All right. Seems pretty clear it can be useful. Give me a couple of days to tidy up the code and I'll post it. Thanks.
Is std.perf still useful?
It seems to be largely replaced by std.datetime.stopwatch and friends, right? Although I'm not sure IF those thread-specific timers are available in datetime. If it's not going to be deprecated let's at least make its documentation linked from somewhere. This is a 2 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3145
Re: Is std.perf still useful?
On 2011-05-24 22:15, Andrej Mitrovic wrote: > It seems to be largely replaced by std.datetime.stopwatch and friends, > right? Although I'm not sure IF those thread-specific timers are > available in datetime. > > If it's not going to be deprecated let's at least make its > documentation linked from somewhere. This is a 2 year old bug: > http://d.puremagic.com/issues/show_bug.cgi?id=3145 If you'll notice, it has this pragma in it: pragma(msg, "std.perf has been scheduled for deprecation. " "Please use std.datetime instead."); It's going away. If it core.time and std.datetime are missing functionality that it provides that you think should be provided in Phobos, then create an enhancement request. But std.perf has been marked as scheduled for deprecation for a number of months now. And the fact that it wasn't listed in the online docs before is likely an indicator that it wasn't considered ready yet. Modules have been added to Phobos before without being added to the documentation when they weren't really ready yet. I don't know what the state of std.perf is though, other than the fact that it has been scheduled for deprecation. - Jonathan M Davis
Re: Is std.perf still useful?
Oh I must have missed that line. Sorry for the noise!
Re: Implementing std.log
Jose Armando Garcia wrote: >Just wanted to let everyone know that I am working on having a review >wordy std.log. I am almost done with the implementation. I am >currently working on improving the documentation. Is there a link that >describes the review process. I would like to get std.log as close to >final to minimize the back and forth. > >Also, I will reply to the rest of Andrei's email and Jens's email when >we have something to look at (the code and doc in github). > >Thanks, >-Jose > I think the review process is meant to be similar to the boost review process, Andrei posted this link a few times: http://www.boost.org/community/reviews.html -- Johannes Pfau
