Re: Implementing std.log
Ok, there's clearly been some misunderstanding here. My real point was, why do you need this threading at all? On 5/7/2011 9:01 PM, Jose Armando Garcia wrote: "Eat your own dog food". D goes to great extend to discourage memory sharing and instead favor message passing. So I figure we should eat our own dog food and use message passing in Phobos. I know that is not a technical argument so let me do the following: implement log buffering, implement a shared memory backend and do a performance comparison of the two approaches on my crappy netbook (which will be unfair but I don't currently have access to a multi-core multi-process machine). Thanks! -Jose On Sat, May 7, 2011 at 8:25 PM, dsimcha wrote: On 5/7/2011 5:55 PM, Andrew Wiley wrote: I'll be sure to try it out in the next few days. Passing messages to a separate logging thread seems like it might be a overkill, but it could work. Can you explain why you did this? I admittedly don't know much about logging but my gut instinct is that it's overengineering. Unless there's a good reason that I didn't foresee, I'd much rather just keep things like logging simple and stupid.
Re: D auto-tester
"Robert Clipsham" wrote in message news:iq4ojp$1ate$1...@digitalmars.com... > On 08/05/2011 01:05, Nick Sabalausky wrote: >>> You won't be able to run the resulting binary of course. >> >> Aww, shucks ;) There go my plans of a software-based CPU upgrade! > > Check out QEMU, it will let you run a virtualized 64 bit operating system > on 32 bit hardware, same for arm and a number of other cpu architectures. > It's been a while since I used it, could do what you want though. I > believe there's an extras package for it if you're on Ubuntu which adds a > load of architectures if it's not available by default. Also make sure to > get the kvm package if your hardware supports it, it'll give a significant > speed boost. > Wow, I'm genuinely surprised anyone's even bothered to make anything that can emulate 64-bit on 32-bit hardware.
Re: Implementing std.log
"Eat your own dog food". D goes to great extend to discourage memory sharing and instead favor message passing. So I figure we should eat our own dog food and use message passing in Phobos. I know that is not a technical argument so let me do the following: implement log buffering, implement a shared memory backend and do a performance comparison of the two approaches on my crappy netbook (which will be unfair but I don't currently have access to a multi-core multi-process machine). Thanks! -Jose On Sat, May 7, 2011 at 8:25 PM, dsimcha wrote: > On 5/7/2011 5:55 PM, Andrew Wiley wrote: >> >> I'll be sure to try it out in the next few days. Passing messages to a >> separate logging thread seems like it might be a overkill, but it could >> work. > > Can you explain why you did this? I admittedly don't know much about > logging but my gut instinct is that it's overengineering. Unless there's a > good reason that I didn't foresee, I'd much rather just keep things like > logging simple and stupid. >
Re: D auto-tester
Am 08.05.2011 02:33, schrieb Robert Clipsham: > On 08/05/2011 01:05, Nick Sabalausky wrote: >>> You won't be able to run the resulting binary of course. >> >> Aww, shucks ;) There go my plans of a software-based CPU upgrade! > > Check out QEMU, it will let you run a virtualized 64 bit operating > system on 32 bit hardware, same for arm and a number of other cpu > architectures. It's been a while since I used it, could do what you want > though. I believe there's an extras package for it if you're on Ubuntu > which adds a load of architectures if it's not available by default. > Also make sure to get the kvm package if your hardware supports it, > it'll give a significant speed boost. > If his hardware supports KVM, it has 64bit support anyway (at least for x86/amd64) ;)
Re: D auto-tester
On 08/05/2011 01:05, Nick Sabalausky wrote: You won't be able to run the resulting binary of course. Aww, shucks ;) There go my plans of a software-based CPU upgrade! Check out QEMU, it will let you run a virtualized 64 bit operating system on 32 bit hardware, same for arm and a number of other cpu architectures. It's been a while since I used it, could do what you want though. I believe there's an extras package for it if you're on Ubuntu which adds a load of architectures if it's not available by default. Also make sure to get the kvm package if your hardware supports it, it'll give a significant speed boost. -- Robert http://octarineparrot.com/
Re: D auto-tester
"Robert Clipsham" wrote in message news:iq4gpa$tq0$2...@digitalmars.com... > On 07/05/2011 23:15, Nick Sabalausky wrote: >> "Robert Clipsham" wrote in message >> news:ipv3tv$1eg0$1...@digitalmars.com... >>> * What is "Linux 32/64" vs. "64/32"? >>> >>> 32 bit dmd creating 64 bit binaries, 64 bit dmd creating 32 bit >>> binaries. >>> I believe you get a description if you hover over them. >>> >> >> Probably a stupid question, but 32-bit DMD can't create 64-bit binaries >> when >> running on a 32-bit system, can it? I assume 32-bit DMD can only create >> 64-bit binaries when running on a 64-bit system, right? > > It should be able to if you have a multilib gcc installed, along with the > relevant 64bit libraries Oh, cool :) > (that makes it sound so simple, I know from experience that anything to do > with gcc almost 100% isn't that simple). Definitely. I think I've managed to develop a strong allergy to gcc due to such issues in the past. > You won't be able to run the resulting binary of course. > Aww, shucks ;) There go my plans of a software-based CPU upgrade!
Re: Implementing std.log
On 5/7/2011 5:55 PM, Andrew Wiley wrote: I'll be sure to try it out in the next few days. Passing messages to a separate logging thread seems like it might be a overkill, but it could work. Can you explain why you did this? I admittedly don't know much about logging but my gut instinct is that it's overengineering. Unless there's a good reason that I didn't foresee, I'd much rather just keep things like logging simple and stupid.
Re: D auto-tester
On 07/05/2011 23:15, Nick Sabalausky wrote: "Robert Clipsham" wrote in message news:ipv3tv$1eg0$1...@digitalmars.com... * What is "Linux 32/64" vs. "64/32"? 32 bit dmd creating 64 bit binaries, 64 bit dmd creating 32 bit binaries. I believe you get a description if you hover over them. Probably a stupid question, but 32-bit DMD can't create 64-bit binaries when running on a 32-bit system, can it? I assume 32-bit DMD can only create 64-bit binaries when running on a 64-bit system, right? It should be able to if you have a multilib gcc installed, along with the relevant 64bit libraries (that makes it sound so simple, I know from experience that anything to do with gcc almost 100% isn't that simple). You won't be able to run the resulting binary of course. -- Robert http://octarineparrot.com/
Re: D auto-tester
"Robert Clipsham" wrote in message news:ipv3tv$1eg0$1...@digitalmars.com... > >> * What is "Linux 32/64" vs. "64/32"? > > 32 bit dmd creating 64 bit binaries, 64 bit dmd creating 32 bit binaries. > I believe you get a description if you hover over them. > Probably a stupid question, but 32-bit DMD can't create 64-bit binaries when running on a 32-bit system, can it? I assume 32-bit DMD can only create 64-bit binaries when running on a 64-bit system, right?
Re: Implementing std.log
On Sat, May 7, 2011 at 4:17 PM, Jose Armando Garcia wrote:
> Hey folks,
>
> For the past couple of days I took the liberty of partially
> implementing a logging module for D. I say partially because all the
> features that I want to implement are not currently implement. You
> should really look at the implementation more as a proof of concept
> even thought most of the code will be used in the final
> implementation.
>
> That been said I am really interested in getting some feedback on the
> API. That includes high-level design (e.g. using a thread to perform
> logging. On that note I am planning to also have a shared memory
> implementation), interfaces and the documentation.
>
> When making comment be aware that the design goals of the module are:
> 1) Provide a logging mechanism that is easy to use in the common case.
> 2) The module should allow for as much configuration as possible at
> compile time and execution time without breaking design goal 1.
> 3) It should be possible to extend or replace the backend without
> breaking the semantic exposed by the API.
>
> I am fairly new to the D language so any comment on how I can take
> advantage of D idiom or D features in the API or implementation would
> be greatly appreciated.
>
> My intent, and hopefully we will get there with your help, is to
> include this in Phobos for D2.
>
> logging.d - http://ubuntuone.com/p/rfL/
> logging.html - http://ubuntuone.com/p/rfM/
>
> Thanks,
> -Jose
>
I'll be sure to try it out in the next few days. Passing messages to a
separate logging thread seems like it might be a overkill, but it could
work. I do like that you can get the file and line included with messages.
One thing I'll miss from Log4J and its siblings is that typing
log.info("message")
is a lot more intuitive than log(LogLevel.info, "message"). I don't think
that's a major gripe though.
Re: Implementing std.log
Hey folks, For the past couple of days I took the liberty of partially implementing a logging module for D. I say partially because all the features that I want to implement are not currently implement. You should really look at the implementation more as a proof of concept even thought most of the code will be used in the final implementation. That been said I am really interested in getting some feedback on the API. That includes high-level design (e.g. using a thread to perform logging. On that note I am planning to also have a shared memory implementation), interfaces and the documentation. When making comment be aware that the design goals of the module are: 1) Provide a logging mechanism that is easy to use in the common case. 2) The module should allow for as much configuration as possible at compile time and execution time without breaking design goal 1. 3) It should be possible to extend or replace the backend without breaking the semantic exposed by the API. I am fairly new to the D language so any comment on how I can take advantage of D idiom or D features in the API or implementation would be greatly appreciated. My intent, and hopefully we will get there with your help, is to include this in Phobos for D2. logging.d - http://ubuntuone.com/p/rfL/ logging.html - http://ubuntuone.com/p/rfM/ Thanks, -Jose On Mon, Apr 25, 2011 at 12:03 AM, Andrei Alexandrescu wrote: > On 04/24/2011 02:23 PM, Sean Cavanaugh wrote: >> >> On 4/20/2011 11:09 AM, Robert Clipsham wrote: >>> >>> Hey folks, >>> >>> I've just finished porting my web framework from D1/Tango to D2/Phobos, >>> and in the transition lost logging functionality. As I'll be writing a >>> logging library anyway, I wondered if there'd be interest in a std.log? >>> If so, is there a current logging library we would like it to be based >>> on, or should we design from scratch? >>> >>> I know there has been discussion about Google's >>> http://google-glog.googlecode.com/svn/trunk/doc/glog.html and another >>> candidate may be http://logging.apache.org/log4j/ . Do we want a >>> comprehensive logging library, or just the basics? (Possibly with some >>> method for extension if needed). >>> >> >> >> I just wanted to mention Pantheios as a C++ logging system to take look >> at as well, I didn't see it mentioned in this thread and it seems to >> have all the major requirements for frontend/backend chaining and >> whatnot that people have brought up. The code is on sourceforge to boot. > > I think Pantheios is an example of library design gone bad. It is > fascinatingly overengineered. > > Andrei > >
Re: Implementing std.log
Hey folks,
For the past couple of days I took the liberty of partially
implementing a logging module for D. I say partially because all the
features that I want to implement are not currently implement. You
should really look at the implementation more as a proof of concept
even thought most of the code will be used in the final
implementation.
That been said I am really interested in getting some feedback on the
API. That includes high-level design (e.g. using a thread to perform
logging. On that note I am planning to also have a shared memory
implementation), interfaces and the documentation.
When making comment be aware that the design goals of the module are:
1) Provide a logging mechanism that is easy to use in the common case.
2) The module should allow for as much configuration as possible at
compile time and execution time without breaking design goal 1.
3) It should be possible to extend or replace the backend without
breaking the semantic exposed by the API.
I am fairly new to the D language so any comment on how I can take
advantage of D idiom or D features in the API or implementation would
be greatly appreciated.
My intent, and hopefully we will get there with your help, is to
include this in Phobos for D2.
Thanks,
-Jose
On Mon, Apr 25, 2011 at 12:03 AM, Andrei Alexandrescu
wrote:
> On 04/24/2011 02:23 PM, Sean Cavanaugh wrote:
>>
>> On 4/20/2011 11:09 AM, Robert Clipsham wrote:
>>>
>>> Hey folks,
>>>
>>> I've just finished porting my web framework from D1/Tango to D2/Phobos,
>>> and in the transition lost logging functionality. As I'll be writing a
>>> logging library anyway, I wondered if there'd be interest in a std.log?
>>> If so, is there a current logging library we would like it to be based
>>> on, or should we design from scratch?
>>>
>>> I know there has been discussion about Google's
>>> http://google-glog.googlecode.com/svn/trunk/doc/glog.html and another
>>> candidate may be http://logging.apache.org/log4j/ . Do we want a
>>> comprehensive logging library, or just the basics? (Possibly with some
>>> method for extension if needed).
>>>
>>
>>
>> I just wanted to mention Pantheios as a C++ logging system to take look
>> at as well, I didn't see it mentioned in this thread and it seems to
>> have all the major requirements for frontend/backend chaining and
>> whatnot that people have brought up. The code is on sourceforge to boot.
>
> I think Pantheios is an example of library design gone bad. It is
> fascinatingly overengineered.
>
> Andrei
>
>
Title: std.logging
std.logging
Implements application level logging mechanism.
This module defines a set of functions useful for many common logging tasks. The module must be initialized (ideally in single threaded mode) by calling initializeLogging. Messages of different severity level are logged by calling the template functions log and logf. Verbose messages can be logged by calling the template functions vlog and vlogf.
Examples:
import std.logging;
int main(string[] args)
{
initializeLogging(ActorLogger.getCreator(args[0]));
// ...
logf(Level.info, "Log message from %s", args[0]);
}
Note:
Logging can be disable at compile time by defining the LOGGING_DISABLED version.
enum Level;
Defines the severity levels supported by the logging library.
Logging messages of severity level Level.fatal will also cause the program to halt. Messages of a given severity will be written in the log file of that severity and the log files of lower severity.
fatalerrorwarninginfo
void initializeLogging(shared(Logger) delegate() logCreator, LogConfig logConfig = LogConfig(null,cast(Level)1,null,null));
Initializes the logging infrastructure.
This function must be called ounce before calling any of the logging functions.
Params:
shared(Logger) delegate() logCreator
Delegate which creates the Logger used by the module.
LogConfig logConfig
Module configuration object.
See Also:
LogConfig
void logf(string file = __FILE__, int line = __LINE__, T...)(Level level, lazy T args);
Logs a formatted message.
Logs a formatted message if level is of higher or equal severity as that specified in the LogConfig object passed to initializeLogging.
The first parameter in args will be used as the format string. See std.format.formattedWrite for a description of the format string.
void log(string file = __FILE__, int line = __LINE__, T...)(Level level, lazy T args);
Logs a message
Logs a message if level is of higher or equal severity as that specified in the LogConfig object passed to initializeLogging.
void vlogf(string file = __FILE__, int line = __LINE__, T...)(uint level, lazy T args);
Logs a formatted verbose message
Logs a formatted verbose message if the file and level matches one of the entries specified in the vLogConfigs property of the LogConfig object passed to initializeLogging.
The first parameter in args will be use
Re: dmd2 on Ubuntu
On 5/7/2011 12:03 PM, Brian Myers wrote: So I removed the executables from /usr/local/bin and rather than adding them to my path, I sym linked them to the dmd2/linux/bin directory in my home directory. I did this because I'd like to have the compiler and tools available system wide. I then moved the dmd.conf file from /etc to the linux/bin directory where dmd resides. When I do this I get different messages from dmd, but it still can't make ld find -lphobos2. The two messages I get, however, are: /usr/bin/ld: skipping incompatible /usr/lib/libphobos2.a when searching for -lphobos2 The other message is also about libphobos2.a, it's just finding it relative to the gcc library path. I even extracted all the object files from libphobos2.a and verified that they were 64 bit ELF format. Is it really that libphobos2.a is messed up, or is this message a red herring? There is a libphobos2.a that is 32 bit, and one that is 64 bit. Make sure that you're using one that is compatible with the -m32 or -m64 settings you're using with the compiler. Also, please use dmd.conf, which contains a switch to shut off undesired warning messages from ld. I strongly suggest trying the default install, making sure that works, before modifying it for your own needs.
Re: dmd2 on Ubuntu
So I removed the executables from /usr/local/bin and rather than adding them to my path, I sym linked them to the dmd2/linux/bin directory in my home directory. I did this because I'd like to have the compiler and tools available system wide. I then moved the dmd.conf file from /etc to the linux/bin directory where dmd resides. When I do this I get different messages from dmd, but it still can't make ld find -lphobos2. The two messages I get, however, are: /usr/bin/ld: skipping incompatible /usr/lib/libphobos2.a when searching for -lphobos2 The other message is also about libphobos2.a, it's just finding it relative to the gcc library path. I even extracted all the object files from libphobos2.a and verified that they were 64 bit ELF format. Is it really that libphobos2.a is messed up, or is this message a red herring? Thanx again Brian
Re: Beta List
KennyTM~: > Oh, what flags have you passed to DMD? -w -g, Windows Vista. > I can only get a "Floating point > exception" on OS X, which is, well, expected as it's the CPU that > catches the integer-divide-by-zero error, not the language. Right, I am sorry. Bye, bearophile
Re: Beta List
On May 7, 11 18:54, bearophile wrote:
Jonathan M Davis:
Just a reminder in case you didn't know, but there is a beta list (dmd-beta)
for posting and discussing beta releases of dmd prior to actual releases.
I am not yet a subscriber there. Here are some notes on 2.053beta.
This little program:
int foo(int x, int y) {
return x / y;
}
void main() {
foo(1, 0);
}
Produces the stack trace:
object.Error: Integer Divide by Zero
...\test.d(5): _Dmain
Oh, what flags have you passed to DMD? I can only get a "Floating point
exception" on OS X, which is, well, expected as it's the CPU that
catches the integer-divide-by-zero error, not the language. The stack
trace can be read by the debugger.
#0 0x1e61 in D1y3fooFiiZi ()
#1 0x1e4a in _Dmain ()
#2 0x00012357 in D2rt6dmain24mainUiPPaZi7runMainMFZv ()
#3 0x00011f01 in D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#4 0x0001239f in D2rt6dmain24mainUiPPaZi6runAllMFZv ()
#5 0x00011f01 in D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#6 0x00011e9b in main ()
Throwing an exception manually does produce a stack trace up to 'foo',
just like Python (which traps divide-by-zero in the language).
Re: C++ static analysis
> Timon Gehr: > >> I think it might be a >> good idea though. However, having this feature means requiring one AST >> compare for >> every boolean operator. > > You are worried about compilation time. I think the feature we're talking > about just tests the equivalence of the then/else clauses. > > Clang has a --analyze switch that runs the (potentially slow) static analyser, otherwise it performs a normal amount of static test on the code. This gives you choice between a faster compilation and a slower analysis able to find some other bugs. > > Bye, > bearophile I think Walter does not like introducing new switches, because it doubles the number of compilers to test and maintain. Timon
Re: Beta List
Jonathan M Davis:
> Just a reminder in case you didn't know, but there is a beta list (dmd-beta)
> for posting and discussing beta releases of dmd prior to actual releases.
I am not yet a subscriber there. Here are some notes on 2.053beta.
This little program:
int foo(int x, int y) {
return x / y;
}
void main() {
foo(1, 0);
}
Produces the stack trace:
object.Error: Integer Divide by Zero
...\test.d(5): _Dmain
While this similar Python2 program:
def foo(x, y):
return x / y
def main():
foo(1, 0)
main()
Gives the stacktrace (feel fee to ignore the first global call to main()):
Traceback (most recent call last):
File "...\temp.py", line 5, in
main()
File "...\temp.py", line 4, in main
foo(1, 0)
File "...\temp.py", line 2, in foo
return x / y
ZeroDivisionError: integer division or modulo by zero
On Python the stacktrace is reversed compared to the D one, maybe this is
better.
And as first line it prints this, that's useful for D too:
Traceback (most recent call last):
And the Python stacktrace shows the line/function where the division by zero
happens too, instead of just all the frames of the functions up to the one that
has called the function that has generated the division by zero. I'd like to
see foo() too in the D stacktrace.
--
Bugzilla 1330 is fixed, I have done a little CTFE benchmark:
import std.c.stdio;
size_t counter(size_t v) {
size_t c;
for (c = 0; v; c++)
v &= v - 1; // clear the least significant bit set
return c;
}
int[] tabler(int n) {
int[] result = new int[n];
foreach (i, ref x; result)
x = counter(i);
return result;
}
const int N = 4000;
const int[] t = tabler(N);
void main() {
for (size_t i = N - 5; i < N; i++)
printf("%u %u\n", i, t[i]);
}
Results:
2.052: 0.78 seconds, about 70 MB committed.
2.053beta: 1.56 seconds, about 140 MB committed.
--
The traits.html docs don't seem to contain the new "parent".
--
This little program:
import std.stdio, std.container;
void main() {
auto t = redBlackTree(0, 7, 5, 2);
writeln(t);
writeln(t[]);
}
Prints:
std.container.RedBlackTree!(int).RedBlackTree
[0, 2, 5, 7]
But I'd like one of the two (the first, if possible) to print instead:
redBlackTree(0, 2, 5, 7)
--
This line is present two times in the changelog:
Added parent to __traits for QtD support
--
Regarding this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=4298
This little program:
enum int[] arr = [1, 2, 3];
void main() {
assert(arr.ptr == arr.ptr);
}
Generates this asm:
__Dmain comdat
L0: pushEAX
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
pushEBX
pushESI
push3
push2
push1
push3
pushEAX
callnear ptr __d_arrayliteralT
add ESP,014h
mov ECX,EAX
pushECX
sub ESP,4
mov EDX,offset FLAT:_D11TypeInfo_Ai6__initZ
push3
mov EBX,3
push2
push1
push3
pushEDX
callnear ptr __d_arrayliteralT
mov ECX,EAX
add ESP,014h
add ESP,4
mov ESI,ECX
mov EAX,3
pop ECX
cmp ECX,ESI
je L55
mov EAX,3
callnear ptr _D4test8__assertFiZv
L55:xor EAX,EAX
pop ESI
pop EBX
pop ECX
ret
--
Bye,
bearophile
Re: Beta List
On 5/7/2011 12:24 AM, Andrej Mitrovic wrote: Here's a quick weblink: http://news.gmane.org/gmane.comp.lang.d.dmd.beta/cutoff=624 It works on my machine :-D
