[kris]

... is released.

See the readme file for details, but the biggest change is the addition of that Log4J clone.

[Carlos]

did you test it on linux? because i can't compile mango there.
first, i get conflicting time_t's in mango.DateLayout and mango.Event, but they can be fixed (I fully qualified them: std.c.time.time_t).
but the worst is after that, when I get:

[kris]

[kris]

Sorry for the delay Carlos;

We got rid of the std.c.time error (two different linux header files declare time_t) and John has confirmed the error in FileBucket.d, which surely identifies a bug in the linux version of dmd.

I'm having difficulty thinking of a way to resolve this because (a) not having a linux box to work with myself, and (b) trying to narrow this down for Walter is likely to be awkward.

Any suggestions guys?

[kris]

Some good news! John has figured out what the problem is

Stay tuned for the resolution ...

[kris]

Major kudos, and a very big thank-you, to John Reimer for resolving that! I'll let John describe the issue he uncovered.

There's a Beta_7b on the download page that fixes the problem. Alternatively, move the FileConduit.d "private import std.c.linux.linux" up to module scope instead of within the class body, or just get the latest FileConduit.d from SVN.

- Kris

[JJR]

First, I apologize for not keeping up with DWT stuff. I've been preoccupied with some other more important issues of late...

Despite this, Kris somehow brought me out of my reveries and got me distracted on a Mango issue . I actually hadn't been reading any of these posts...

This was kind of a lucky find... but for those who are interested (and in case you run into the problem in some other project), here's what I found out.

I verified that the same errors were occuring on my Linux as mentioned above. After being stumped for a bit, I decided that there might be a name resolution problem going on. To test my guess, I forced the compiler to spit out more details for me.

dmd was complaining about file.close() not having enough arguments, so in order to see what arguments the compiler expected, I inserted first an integer:

file.close(1);

...no complaint from the compiler. I still wanted to see the compiler complain, so then I did...

file.close("a");

... and the compiler complained that expected an "int". So it seemed very sure of what it wanted. It seemed that the 3 arguments expected in bucket.file.read() also indicated the same issue.

So here I looked for anything that might cause the problem, any sort of close() and read() that might be getting in the way. I first looked in phobos and then I looked in std.c.linux.linux and found definitons that might just fit the problem: close(int) and read(int, void*, int) exactly fit the issue. After the fact, I noticed that a local import in the class body existed just above the use of these methods in FileConduit.d: private import std.c.linux.linux. The problem seemed pretty obvious to me, at this point.

So it appears D has issues with importing within a class body (something we found so useful in resolving many forward referencing issues). So watch out: local imports will override the name resolution for class methods if the imported functions match in the method name, regardless of whether the arguments and return types differ. Obviously the signatures are not significant here for name resolution. This is actually a frustrating problem in D.

Here's an example:

[brad]

Found an issue while playing with my Baseball program.


/d/mango/trunk/mango/servlet/ServletProvider.d(343): cannot return value from void function

So I changed:

[kris]

[brad]

So I'll get off my lazy ass and upgrade DMD.
_________________
I really like the vest!

[JJR]

That sounds very odd. I don't understand this. How do you return a value from a void function? Or why would you want to do that? It was my impression that void was there for a reason: to indicate nothing was to be returned from a function. This must have been a new strange feature that I missed.... Was it discussed on the newsgroup?

In need of enlightenment,

John

[kris]

[jcc7]

[JJR]

Ah, I see now. Thanks for the link. Its use in generics now makes sense to me. All it's really doing is just returning void .

Funny how that works. For consistancy in a language, such a feature just makes sense.

Thanks guys,

John