Re: Early review of std.logger
On Monday, 14 October 2013 at 18:29:09 UTC, ilya-stromberg wrote: On Monday, 14 October 2013 at 18:00:12 UTC, Robert Schadek wrote: If you disagree, please tell why. If you want a logger with a particular feature, this module will allow to create a custom logger. It would be a mistake to include something that specific. eg: - we can create new RNG on top of std.random, which follow the same interface - we can use any such std.random-compatible RNG to feed random distributions algorithms
Re: Early review of std.logger
On 10/15/2013 09:32 AM, Sönke Ludwig wrote: > Am 15.10.2013 09:08, schrieb Jacob Carlborg: >> On 2013-10-14 23:22, Dicebot wrote: >> >>> If we need to care about that, D module system is a failure. >>> But I don't think it is a valid concern. >> >> People already complain about conflict function names in Phobos. >> > > And I'd agree with them. At least inside of a library, care IMO should > be taken to minimize overlap (of course functionally equivalent ones > in different overload sets are fine, though). But in case of "logXXX" > this seems to be very unlikely, much in contrast to "log" (std.math.log). yes and no. Of course does logXXX create less conflict, but I like to simply write log and don't care about the LogLevel. So again pros and cons
Re: dmd 2.063 generated code a lot slower then dmd 2.062
On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky wrote: On Mon, 14 Oct 2013 16:19:23 +0200 Andrej Mitrovic wrote: On 10/14/13, Nick Sabalausky wrote: > And any sane editor There's your problem right there. I'd say a sane diff view would make it obvious that CRLF or tabs were injected, and yet github's diff view is a piece of ass. Github's entire web frontend is horrible. They don't even know how to write a freaking web page: http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers (BUt really, I'm not sure there's an ajaxy site in the world that isn't garbage. Ex: http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmar...@puremagic.com ie "For reference, that's considerably less than the chrome process that hosts gmail (200mb!)") Sadly that is the future. :( I am looking forward that native mobile applications kill these web applications trend, but I am in the minority. And I do write web applications as well, so I do know both sides of the fence. -- Paulo
Re: Early review of std.logger
On 10/15/2013 02:44 AM, Kapps wrote:
> A few concerns:
>
> There doesn't seem to be a debug or trace log level. This is quite a
> useful thing to have once your program is deployed.
there is a LogLevel.debug and a LogLevel.info
>
> I don't like the returning by ref for log methods. For example, it
> seems like you can do: log(5 < 4, "This is a test log") = new
> StdIOLogger();
> It could potentially be useful to return the Logger so you can chain
> calls and such, but it should not be possible to set the logger by
> assigning the result of a log call.
I saw this, but this comes from the way you get the default logger. I
don't think that this is that bad, but I bet somebody will disagree.
>
> The simple act of logging a message is very verbose right now:
> log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
> prefer something like log.trace("Creating new pool") and log("Creating
> new pool") where the latter would use opCall to forward to the default
> log level. If it's intentional that you can assign the result of log,
> this also helps that because log = new StdIOLogger would be possible
> (log being a property that returns a Logger, and so a setter could be
> made), but log("Creating new pool") = new StdIOLogger() would not be.
The LogLevel is optional. And always writing log.trace might become more
typing work and assigning a LogLevel and than calling log("..."). Both
have pros and cons
>
>
> There's a lot of suggestions for things like network logging, but I
> think this is far beyond the scope of the module, and the sheer amount
> of different ways of doing it means people will likely write their own
> anyways. For example, synchronous vs asynchronous, what protocol to
> use, authentication, client data, encryption, etc.
my point exactly
Re: GDC vs dmd speed
On Monday, 14 October 2013 at 19:24:27 UTC, Spacen Jasset wrote: gdc 4.6 (0.29.1-4.6.4-1ubuntu4) Which I assume might be v2.020? with flags: ["-O2"] That's a really old gdc. If you can, upgrade to ubuntu 13.10 and you'll get a more up-to-date version. Alternatively, build from source: http://gdcproject.org/wiki/Installation/GeneralIt'll take an age to run the compilation, but it's not hard to do.
Re: GDC vs dmd speed
On Monday, 14 October 2013 at 19:24:27 UTC, Spacen Jasset wrote:
Hello,
Whilst porting some C++ code I have discovered that the
compiled output from the gdc compiler seems to be 47% quicker
than the dmd compiler.
Here is a few more data points for microbenchmarks of simple
functions (Project Euler), which supports an observation
(disclaimer: my microbenchmark is not a guarantee of your code
performance, etc.) that the fastest code is produced by LDC, then
GDC and DMD is the slowest one.
Tested on Xubuntu 13.04 64-bit Core i5 3450S 2.8GHz.
Test 1:
// 454ns LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 830ns GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 1115ns DMD64 2.063.2: dmd -O -noboundscheck -inline -release
int e28_0(int N = 1002) {
int diagNumber = 1;
int sum= diagNumber;
for (int width = 2; width < N; width += 2)
for (int j = 0; j < 4; ++j) {
diagNumber += width;
sum+= diagNumber;
}
return sum;
}
Test 2:
// 118ms LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 125ms GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 161ms DMD64 2.063.2: dmd -O -noboundscheck -inline -release
bool isPalindrome(string s) {return equal(s, s.retro);}
int e4(int N = 1000) {
int nMax = 0;
foreach (uint i; 1..N)
foreach (uint j; i..N)
if (isPalindrome(to!string(i*j)) && i*j > nMax)
nMax = i*j;
return nMax;
}
Test 3:
// 585us LDC 0.11.0: ldmd2 -m64 -O -noboundscheck -inline
-release
// 667us GDC 4.8.1: gdc -m64 -march=native -fno-bounds-check
-frename-registers -frelease -O3
// 853us DMD64 2.063.2: dmd -O -noboundscheck -inline -release
int e67_0(string fileName = r"C:\Euler\data\e67.txt") {
// Read triangle numbers from file.
int[][] cell;
foreach (line; splitLines(cast(char[]) read(fileName))) {
int[] row;
foreach (token; std.array.splitter(line))
row ~= [to!int(token)];
cell ~= row;
}
// Compute maximum value partial paths ending at each cell.
foreach (y; 1..cell.length) {
cell[y][0] += cell[y-1][0];
foreach (x; 1..y)
cell[y][x] += max(cell[y-1][x-1], cell[y-1][x]);
cell[y][y] += cell[y-1][y-1];
}
// Return the maximum value terminal path.
return cell[$-1].reduce!max;
}
Here is the relative to LDC code speed averaged over these three
test (larger number is slower):
LDC 1.00
GDC 1.34
DMD 1.76
Re: Early review of std.logger
On 10/15/2013 04:06 AM, Eric Anderton wrote: > On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote: >> Lets unleash the forces of constructive destruction. > > So, not to be too heavy-handed with criticism on this library, but I > think this should come up to par with solutions like log4j, log4cpp, > or log4cxx, with respect to features and capabilities. Libraries like > these have enjoyed a lot of very serious use, and once you have > something like that in your project, it's hard to not use most of what > they have to offer. There's really not a lot of fluff in those > solutions. IMO these libraries are to heavy. Especially with phobos inclusion in mind. > > Here's what I think is missing: > - System log support (as others have mentioned). This would be syslog > or WEL, depending on environment. This is sort of the idea of the design, I can't anticipate your needs therefor I should not try. I should try to give you guidelines or a framework to work against. > > - Guarantees or options for working with log rotation (logrotate.d). > It's nice to either know that you must restart your daemon once logs > are rotated, or can configure logging to re-open handles automatically > or when it detects rotation has occurred. See previous point > > - Guarantees about threading and thread safety, with concessions to > help keep log event streams coherent from thread to thread. Log > formatting in particular could enjoy the ability to emit a thread id, > so logs can be analyzed without confusing which thread is responsible > for which chain of events. > Passing a thread id with a log message, ok! shared!? > Here's what I think would make this an amazing library: > - Nested Diagnostic Context (NDC) support. This isn't heavily used in > all projects, but it does a fantastic job of cutting down on the > tendency to put tons of redundant information into every call to > log(). In practice, this helps tremendously for debugging, as > engineers stop pulling punches as adding rich contextual data to log > lines becomes painless. See previous point > > - Log "category" support. Just some way to add an axis for filtering, > so you can configure logging to block all log messages from one > library, or just errors from another, at the same time. Under log4j, > this is simply the module where the log event originates from - other > libs let you use an arbitrary string. at one point the logger had names, but I thought on how to get the correct names to them. This lead to some config file and I don't want that. > > - Filtering log events on another axis. Loggers can already be > configured with a log level. But it would be nice to be able to set a > global log level to dial in how much information comes out of the > system across all logger instances. there already is a global log level > > That said, I do appreciate the compactness of this library. It > provides some very straightforward logging support and covers all the > basic and important use cases. But after using more feature-rich > solutions, I can't help but think of all the places that I would feel > inclined to go with a stronger solution, or extend this to do more of > the kinds of things I'm used to doing elsewhere. I think D has a > chance to make an implementation of something on par with log4j or > log4cxx, easy to do, without needing anywhere near as much code. > > - Eric
Re: Early review of std.logger
On Monday, 14 October 2013 at 12:48:14 UTC, Martin Drasar wrote: 1) MultiLogger class that takes references to other loggers and just forwards the call to the log function. +1 Also, we should support a few loggers whith same type. For example, I can use 2 file loggers: the 1-st only for debug messages and the 2-nd for all other messages. It can help for message sorting. Also, we should support a reserve loggers. For example, I can use a file logger as a default and a syslog as a reserve logger (it will be used if the file logger fails). It increases logger reliability. Also, it will be perfect to have logger failed notifications. For example, the file logger failed can indicate that we haven't got free disc space, a file system problems or hard disk problems. So, we should inform admin about this problems. We can do it via stderr (for local computer only), via syslog network logger or via e-mail logger.
Re: Early review of std.logger
Am 14.10.2013 20:24, schrieb Robert Schadek: On 10/14/2013 04:44 PM, Sönke Ludwig wrote: Am 14.10.2013 15:12, schrieb Robert Schadek: On 10/14/2013 02:39 PM, Sönke Ludwig wrote: - The static methods in LogManager should be made global and the class be removed. It's not for objects so it shouldn't be a class. LogManager also stores the global log level. Sure I can make another static global function storing this log level, but I would like to keep them together as they belong together IMO. The same could be said about the global "log" functions, which are tightly coupled to that state. I think this is already nicely grouped together by the logger module itself, since there is not much else in it. Basically, I just wouldn't consider this style to be particularly idiomatic D code, but of course that's just personal perception/preference (there is also some precedence using "struct" instead of "class" in Druntime). However, if it ends up like this in the final version, it should get a "@disable this();" to prevent misuse. It is for ment for phobos not druntime. Anyway structs would mean all templates and people will scream template bloat. And this would break the design, which I find to be a valid use of classes and polymorphisms. The StdIOLogger can have its default constructor called IMO. No no, I was talking about the JobManager, not the Logger classes. No templates involved. - For me this logger is completely worthless without any debug log levels. The last std.log entry had at least anonymous verbosity levels, but I'd prefer something like I did in vibe.d [1], where each level has a defined role. This should especially improve the situation when multiple libraries are involved. Logger.log(LogLevel.(d|D)ebug, "Your message"); That would be my idea. Having at least two (diagnostic output for the user and debug output for the developer), but better all four debug levels can be very useful, though. Maybe I miscommunicated what I want to show by that example. The (d|D) part is the rename to enum lower case. The debug log level is given through the LogLevel.Debug, which will be renamed to LogLevel.debug. I would call the developer the user of the logger. Maybe log messages can be communicated to the user of the applicaiton and the developer of the application through a MultiLogger class. But the statement of mine that you quoted was about debug levels (the case issue is clear)... Also right now there is no "(D|d)ebug" level, so I'm actually not sure about the statement that you want to make. But my example of having different levels for the application user and the developer is mostly important when the application user enables verbose log output to see where things go wrong. In that case things like system error codes and the like would make sense, but a repeated printout of some kind of internal buffer state would hardly help the user - it could, however, help the developer. Thanks for bringing this forward! To whom is this directed? To you for attempting to revive the logger topic.
Re: Early review of std.logger
Am 15.10.2013 09:08, schrieb Jacob Carlborg: On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. And I'd agree with them. At least inside of a library, care IMO should be taken to minimize overlap (of course functionally equivalent ones in different overload sets are fine, though). But in case of "logXXX" this seems to be very unlikely, much in contrast to "log" (std.math.log).
Re: draft proposal for ref counting in D
On 2013-10-15 05:11, Michel Fortin wrote: mprotect isn't available at all with the iOS SDK. So making this collector work on iOS (and the iOS Simulator) would require a different codegen. I haven't tried compiling anything and I don't know if I'm looking in the correct file but this file: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/sys/mman.h Does contain "mprotect". -- /Jacob Carlborg
Re: Early review of std.logger
On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. -- /Jacob Carlborg
Re: draft proposal for ref counting in D
On 14.10.2013 21:42, Michel Fortin wrote: Indeed. The current garbage collector makes it easy to have shared pointers to shared objects. But the GC can also interrupt real-time threads for an unpredictable duration, how do you cope with that in a real-time thread? The work I was talking about uses C++, not D, so there is no GC involved. The options I see for real-time threads in D is either a concurrent GC (which means read/write barriers for pointer accesses) or just excluding the real time thread from suspension by the GC. This forces the programmer to ensure that references in the real time thread are also found elsewhere. I'm not sure if this eliminates the benefits regarding locking, though. I know ARC isn't the ideal solution for all use cases. But neither is the GC, especially for real-time applications. So, which one would you recommend for a project having a real-time audio thread? ARC doesn't work for real time threads anyway, because you are not allowed to deallocate if it can cause locks. It can only work if you defer reference counting into another thread through some buffering. Realistically I would currently recommend the approach above: exclude the thread from suspension, and keep a reference to used object elsewhere. This is probably about as difficult as avoiding allocations/deallocations in C++, but harder to debug.
