Re: std.logger sharedLog usage
On Monday, 30 March 2015 at 04:05:12 UTC, lobo wrote: Thank you, lobo. next version will have equal default LogLevel for all Logger. https://github.com/D-Programming-Language/phobos/pull/3124
Re: std.logger sharedLog usage
On Sunday, 29 March 2015 at 01:36:24 UTC, lobo wrote:
Hi,
I'm trying to use std.experimental.logger and I'd like the
logf(), tracef() style functions to log to a file and stdout.
(note: I can use sharedLog.logf(), sharedLog.tracef(), but I
prefer just logf())
So I did this:
shared static this() {
auto ml = new MultiLogger();
ml.insertLogger(stdout, new FileLogger(std.stdio.stdout));
ml.insertLogger(applog, new FileLogger(applog.txt));
sharedLog = ml;
logf(This is a test); // Doesn't work
}
Which doesn't work, so I'm wondering if it's possible to do
what I want.
thanks,
lobo
just add the line stdThreadLocalLog.logLevel = LogLevel.info
before logf and it should work. The default LogLevel of the
MultiLogger and FileLogger is high than the default LogLevel of
stdThreadLocalLog. (I will fix that)
Re: Release D 2.067.0
On Wednesday, 25 March 2015 at 02:02:50 UTC, Paul O'Neil wrote: I have been eagerly awaiting this release for a while - especially for std.experimental.logger! let me know how you like it! I always need feedback on it
Re: Making byLine faster: we should be able to delegate this
On Monday, 23 March 2015 at 15:00:07 UTC, John Colvin wrote: What would be really great would be a performance test suite for phobos. I'm working on it https://github.com/D-Programming-Language/phobos/pull/2995
Re: How to generate a random string ...
On Monday, 16 March 2015 at 22:19:52 UTC, Gary Willoughby wrote: I guess it depends on the encoding? No the character itself are encoding independent. Some references: http://stackoverflow.com/questions/23853489/generate-a-random-unicode-string This will not work as the caller has to specify the code range. I want to specify the string length and the random use is not even uniform (see channel 9 link) http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful http://www.bonf.net/2009/01/14/generating-random-unicode-strings-in-c/ I'm not use how that is going to give me the 113,021 unicode defined characters let alone in a uniform way.
How to generate a random string ...
... from all Unicode characters in an idiomatic D way?
(std.interal.unicode_*)
```
T genUnicodeString(T)(size_t minChars, size_t maxChars)
if(isSomeString!T) {
...
}
```
Re: How to generate a random string ...
On Monday, 16 March 2015 at 18:48:29 UTC, bearophile wrote: Perhaps by rejection? I mean, generating a uint, test if it's a character and repeat until the result is true. hm, that must not even terminate.
Re: D 2.067.0-b3
On Wednesday, 4 March 2015 at 16:14:31 UTC, Mario Kröplin wrote: I just tried the beta with one of our applications, which receives and decodes tens of thousands of XML documents and makes heavy use of the garbage collector. Compared to D 2.066.1, there is a speed-up from 34.5 seconds to 26.5 seconds. Nice! this should be headline news.
Re: DConf 2015 discounted hotel rooms now available
On Monday, 2 March 2015 at 15:14:57 UTC, Andrew Edwards wrote: What is the unofficial hangout spot for this year? DConf15 takes place at a university, can't we hang on campus.
Re: H1 2015 - db access support in Phobos
IMO the java way is to uncreative. We have UDA, CTFE and string mixins anything short of perfect SQL generated at compile time without anything else than UDA annotation to my structs is an epic lose for D. I mean, who wants to write string statements when the lib can generate them for you. For every sql incarnation you can think of.
Re: H1 2015 - db access support in Phobos
nice! get it into phobos or vibe
Re: H1 2015 - db access support in Phobos
On Tuesday, 3 February 2015 at 10:33:25 UTC, Vadim Lopatin wrote:
ORM operations are not a simple single query/statement.
They often use several queries to load dependent objects.
make it an output range
Of course, some CTFE/UDAs may be used for generation of field
list, but it is not very helpful IMO.
IMO writing:
foreach(it; db.selectUser(...)) {
}
is epic. you have entered std.(range|algorithm) land.
Re: H1 2015 - db access support in Phobos
But for such high level DB library must be based on some lower level DB API (connector). Like JDBC for JPA or Hibernate in Java. really, does it? there is no need for an abstraction layer. you can have functions generate the correct source for mysql, sqlite, you name it. e.g. just generate the mysql statement at CT and pass the pointer to the sql c function. pass the parameter. done. Dream big. D may offer more convenient way for reading of field values ... not used), but it doesn't know column types anyway. I don't get your point
sort no @safe in BUILD=debug
something wired is going on. phobos HEAD fails to build in multiple places. sort seams to be non-safe in BUILD=debug. After I got it to build by marking some unittests as non-safe utf.d fails when running its unittests. help, please
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek
wrote:
thank you @!In order of appearance on github() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh,
Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce,
yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky,
SerialVelocity, drasha, klickverbot, MartinNowak,
jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
and of course mleise, sry I forgot you
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
thank you @!In order of appearance on github() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, Geod24,
andralex, braddr, AndrejMitrovic, MetaLang, p0nce, yglukhov,
elendel-, sigod, sybrandy, DmitryOlshansky, SerialVelocity,
drasha, klickverbot, MartinNowak, jacob-carlborg, 9il, quickfur,
deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
Re: std.experimental.logger formal review round 3
On Sunday, 25 January 2015 at 09:43:36 UTC, Jacob Carlborg wrote: On 2015-01-24 18:45, Robert burner Schadek wrote: I will fix the bug this weekend and rebase to upstream/master. The alias doc has seen some updates this week (please check the rebuild gh-pages, links are in the PR description) Is the generated documentation for package module available somewhere? This [1] is empty. [1] http://burner.github.io/phobos/phobos-prerelease/std_experimental_logger_package.html fixed
Re: std.experimental.logger formal review round 3
I will fix the bug this weekend and rebase to upstream/master. The alias doc has seen some updates this week (please check the rebuild gh-pages, links are in the PR description)
Re: dlang.org redesign n+1
shut up and take my money love it
Re: Why exceptions for error handling is so important
to not let ranges succumb to such a problem I wrote: https://github.com/D-Programming-Language/phobos/pull/2724
Re: Improving http://dlang.org/library/index.html
what about making it multi column like on http://en.cppreference.com/w/
Re: Improving http://dlang.org/library/index.html
lets combine both there is enough space, something like || name | desc || name | desc ||
Re: Alignment of dynamic arrays
not 16 bit, 16 byte. -Steve known how to read helps, of course you're right.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via Digitalmars-d-learn wrote: std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. even with CTFE regex still uses a state machine _mm256_cmpeq_epi8 will beat that even for multiple strings. Basically all lexer are handwritten, if regex where fast enough nobody would do the work.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via Digitalmars-d-learn wrote: if you *really* concerned with speed here, you'd better consider using regular expressions. as regular expression can be precompiled and then search for multiple words with only one pass over the source string. i believe that std.regex will use variation of Thomson algorithm for regular expressions when it is able to do so. IMO that is not sound advice. Creating the state machine and running will be more costly than using canFind or indexOf how basically only compare char by char. If speed is really need use strstr and look if it uses sse to compare multiple chars at a time. Anyway benchmark and then benchmark some more.
Re: NASA/JPL Rules for writing Critical Software
On Thursday, 8 January 2015 at 23:37:38 UTC, Walter Bright wrote:
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
from the document (Rule 5):
A typical use of an assertion would be as follows:
if (!c_assert(p = 0) == true) {
return ERROR;
}
that is just bad code. IMO I'm not sure if I would trust their
advice.
But the ESA coding manual properly has worse stuff in it, but
this is getting OT way to fast.
Re: Alignment of dynamic arrays
On Friday, 9 January 2015 at 11:19:47 UTC, bearophile wrote: If you have a 16-byte aligned array of doubles and you slice the first double away, what's the alignment of the result? the first double[0] is 16-byte aligned, double[1] would be 20-byte aligned as a double is 4 byte long. p.s. I'm properly wrong as my last two posts contained errors
Re: Alignment of dynamic arrays
On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote: Luc Bourhis: With auto a = new double[1000], is there any guarantee that a.ptr is aligned on a 16-byte boundary? Arrays are aligned on a 16-byte. But if you slice them, this alignment can be broken. IMO, If you slice a double array it is always aligned. Because doubles are 8 bytes long aka 64bit which would align them to every fourth 16bit boundary.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:21:04 UTC, ketmar via Digitalmars-d-learn wrote: heh. regexps *are* fast enough. it's hard to beat well-optimised generated thingy on a complex grammar. ;-) I don't see your point, anyway I think he got his help or at least some help.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
use canFind like such: bool a = canFind(strs,s) = 1; let the compiler figger out what the types of the parameter are.
Re: D idioms list
that a really nice idea, thanks. substring position, std.string.(last)indexOf(|Any|Neither) may be better btw. this should move to the dlang wiki. Any takers?
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 01:13:21 UTC, Andrei Alexandrescu wrote: On 1/6/15 4:26 PM, Robert burner Schadek wrote: std.string looks fine only the indexOfNeither and lastIndexOfNeither are missing Could you please fix -- thanks! -- Andrei I think I just did. Does the webpage show 2.066? If so indexOfNeither must not be part as it was merged after the release.
Re: Ready to make page-per-item ddocs the default?
std.string looks fine only the indexOfNeither and lastIndexOfNeither are missing
Re: std.experimental.logger formal review round 3
recent updates: * Martins CT log function disabling (thanks Martin) * new thread local indirection Logger between free standing log functions and program global Logger * more documentation * some @trusted have been remove (thanks Dicebot) * local imports please review
Re: Ranges and Exception handling PR 2724
On Saturday, 15 November 2014 at 01:43:07 UTC, Robert burner Schadek wrote: This PR https://github.com/D-Programming-Language/phobos/pull/2724 adds an generic way of handling Exception in Range processing. quickfur and Dicebot ask me to start a thread here so the concept could be discussed. We are currently searching for a name for an enum that is used to select which methods of the range to handle. Current ideas are found in the PR. please have a look and give comments.
Re: ini library in OSX
as you properly know, ini files don't support sections arrays. If you know all items at compile time, you could create structs for all of them, but that is properly not what you're looking for.
Re: ini library in OSX
On Saturday, 20 December 2014 at 08:09:06 UTC, Joel wrote: On Monday, 13 October 2014 at 16:06:42 UTC, Robert burner Schadek wrote: On Saturday, 11 October 2014 at 22:38:20 UTC, Joel wrote: On Thursday, 11 September 2014 at 10:49:48 UTC, Robert burner Schadek wrote: some self promo: http://code.dlang.org/packages/inifiled I would like an example? go to the link and scroll down a page How do you use it with current ini files ([label] key=name)? I think I don't follow? readINIFile(CONFIG_STRUCT, filename.ini); ?
Re: LogLevel [was std.experimental.logger formal review round 3]
On Monday, 8 December 2014 at 21:20:20 UTC, Andrei Alexandrescu wrote: On 12/4/14 8:37 PM, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ _loggerinfo.d and then describe the import constraint in the documentation. Perhaps that might improve error messages. I fear of things that could happen if a circular import via mixin fails. Andrei How long is a line of your terminal? On a more serious note: I proposed _loggerinfo.d to counteract that and this file could be the place to store all logger configuration anybody invents. This way we would have a canonical place for all configuration concerning the logger.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Friday, 5 December 2014 at 10:30:08 UTC, Dicebot wrote: On Thursday, 4 December 2014 at 14:32:27 UTC, Daniel Murphy wrote: FWIW I don't really like this - it feels like a hack. I'd rather just declare a private logger alias (or something like that) and use that in the library. Decision can be made at compile time, doesn't require reverse module imports, doesn't depend on global versions. eg alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); I agree with Daniel here. It feels like seeking for too much magic just because it is cool - while more simple and straightforward approach can do the job as well. Yes simpler is better, if it works. As discussed twice already, an approach like: alias libraryLogger = std.logger.FilteredLogger!(LogLevel.info); will not work. Currently I think the best solution is Martin's idea with my mod. The complexity of the task to accomplish does not simple go away. Unless you cut features which we can't do to keep the generality of the library. And that is the main goal after all.
Re: DIP69 - Implement scope for escape proof references
thank you for pushing on this. Lifetime last bullet point: , but lower than any variables in higher scopes. isn't that redundant to the first bullet point? Or am I missing something? Scope affects variables according to these rules: Could you enumerate the list instead of bullet points, I can't count. Base operation: That one I don't get. I would assume this is legal as the function is not @safe. e = c; // Error, lifetime(e's view) is infin; and is greater than lifetime(c)
Re: LogLevel [was std.experimental.logger formal review round 3]
That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ _loggerinfo.d and then describe the import constraint in the documentation.
Re: LogLevel [was std.experimental.logger formal review round 3]
As I have explained countless times, the configuration in source and through inheritance will always be more powerful and flexible than a config file. I'm not gone create any config file support, as there will be always one feature missing and there is just no way to anticipate all possible configuration requirements. So one shouldn't even try.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:02:23 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 December 2014 at 10:56:29 UTC, Robert burner Schadek wrote: As I have explained countless times, the configuration in source and through inheritance will always be more powerful and There is no contradiction. Configuration is level 1, implementation is level 2. Either I don't see your point or you didn't see mine.
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:49:53 UTC, Ola Fosheim Grøstad wrote: I think D lacks a generic project configuration mechanism. I generally want configurations to be located in one or at least a few files that are easy to modify and which can have tools written for them. So yes, this should not be written for logger alone. I think D lacks a good std.serialization module
Re: LogLevel [was std.experimental.logger formal review round 3]
On Thursday, 4 December 2014 at 11:12:02 UTC, Martin Nowak wrote: On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner Schadek wrote: That is much nicer, thank you for taking the time. Couldn't way just say that we don't import __MODULE__ but rather __MODULE__ ~ _loggerinfo.d and then describe the import constraint in the documentation. Importing a different module wouldn't reliably work, when file paths differ from module paths. The nice thing about importing __MODULE__ is that the compiler already knows it, because it's the caller. Also importing a different file by name feels a bit too much like magic ruby bindings. Well, the static if mixin stuff also a bit like magic. How do you suggest do we solve the dependency cycle? Anyway, the code you showed needs a default case where there is no LogLevel defined and no parent is left.
Re: std.experimental.logger formal review round 3
On Saturday, 29 November 2014 at 19:18:01 UTC, Martin Nowak wrote:
On 11/29/2014 05:25 PM, Robert burner Schadek wrote:
Yes, there is a lock free, thread local indirection now. That
can be
used to build a lock free, thread local logger.
p.s. You should have taken the phun
I commented on the relevant commit.
https://github.com/burner/phobos/commit/8a3aad5df5218bd995d4679f9b59a59909969b52#diff-59d32a64bcbd4492ff85f10091d73f5fR289
I missed that final.
Let me propose a light-weight alternative solution.
```d
abstract class Logger
{
Object.Monitor mutex;
this()
{
this.mutex = createMutex();
}
Object.Monitor createMutex()
{
import core.sync.mutex;
return new Mutex;
}
}
```
This allows people to override the mutex with whatever fits
their bill, e.g. one that supports fiber suspension. Especially
they can do this.
Object.Monitor createMutex()
{
static class NoLock : Object.Monitor
{
void lock() nothrow {}
void unlock() nothrow {}
}
return new NoLock;
}
I will add this and remove the final.
Thank you
Re: std.experimental.logger formal review round 3
On Saturday, 29 November 2014 at 14:15:12 UTC, Martin Nowak wrote: On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner Schadek wrote: You can always roll your own non locking Logger, but the default should be thread-safe. You can't, since you need to inherit from Logger, which already does the locking for you in a way that's not overridable. Also, I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization. Have you guys resolved this? If we cannot implement a non-locking logger than that's a blocking issue for the library. Yes, there is a lock free, thread local indirection now. That can be used to build a lock free, thread local logger. p.s. You should have taken the phun
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 23:41:51 UTC, Walter Bright wrote: On 11/25/2014 2:26 AM, Robert burner Schadek wrote: On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger? Yes. Not really, this is the first time I read the name SiCl4. Also google SiCl4 dlang only points to the reddit post.
Re: std.experimental.logger formal review round 3
On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright wrote: Anyone know anything about this? https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac You mean the second part, about him leaving D because of the discussion about the logger?
Re: std.experimental.logger formal review round 3
On Friday, 14 November 2014 at 23:06:22 UTC, Dicebot wrote: On Friday, 14 November 2014 at 22:20:17 UTC, Robert burner Schadek wrote: I will test something this weekend regarding the additional indirection. Thanks! I may try hacking some sample implementation too but pessimistic about ETA So, I added a layer of thread local indirection to the Logger. It now goes by default like: log|trace|... - threadLocalLogger - globalLogger The threadLocalLogger is just another Logger so it can be replaced with whatever you need may need. Or just keep it forwarding.
Re: Ranges and Exception handling PR 2724
Your idea designs an idiom on how to let ranges handle exceptions. My PR is about how to handle exceptions thrown by ranges. Both sort-of do the same thing but at different points. Your design idiom needs source access (needs to be programmed in). Mine can be bolted on later (an additional element in the range chain). Of course fixing an erroneous range might be tricky but than exception handling and recovering is not easy to being with. Back to your problem: If you do the foreach by hand, can you place the part that throws (popFront, front or empty) in an try catch block and still iterate to the next element afterwards?
Re: Ranges and Exception handling PR 2724
On Wednesday, 19 November 2014 at 05:49:55 UTC, H. S. Teoh via
Digitalmars-d w
From what I understand, this PR is proposing to add a range
wrapper that
catches exceptions thrown from range primitives and passes them
to a
user-specified handler. Seems to be a promising idea, but it's
probably
It is exactly that:
auto s = 12,1337z32,54,2,7,9,1z,6,8;
auto r = s.splitter(',')
.map!(a = to!int(a))
.handleBack!(ConvException, (e, r) = 0)
.array;
assert(equal(h, [12, 0, 54, 2, 7, 9, 0, 6, 8]));
Re: Ranges and Exception handling PR 2724
hm, the thing is there are ranges that will throw, making them nothrow is of course a very good idea, but some will still throw map(a = throw ...) This handleXXX ranges deal with them.
Re: std.experimental.logger formal review round 3
On Friday, 14 November 2014 at 21:43:53 UTC, David Nadlinger wrote: Except that they can't actually get rid of all the overhead involved, as the locking is hard-coded into the Logger base-class. Granted, acquiring an uncontended lock isn't terribly expensive, but it's still a noticeable overhead if you are just logging to a thread-local buffer otherwise. David You can always roll your own non locking Logger, but the default should be thread-safe.
Re: std.experimental.logger formal review round 3
On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner Schadek wrote: You can always roll your own non locking Logger, but the default should be thread-safe. You can't, since you need to inherit from Logger, which already does the locking for you in a way that's not overridable. Also, My bad, I mixed something up. I take it you are familiar with the fact that locks aren't the only technique for achieving cross-thread synchronization. Yes, but this way allows to add structured logging in an easy way.
Re: std.experimental.logger formal review round 3
I will test something this weekend regarding the additional indirection.
Ranges and Exception handling PR 2724
This PR https://github.com/D-Programming-Language/phobos/pull/2724 adds an generic way of handling Exception in Range processing. quickfur and Dicebot ask me to start a thread here so the concept could be discussed.
Re: std.experimental.logger formal review round 3
On Friday, 14 November 2014 at 23:40:21 UTC, David Nadlinger wrote: On Friday, 14 November 2014 at 22:18:41 UTC, Robert burner Schadek wrote: Yes, but this way allows to add structured logging in an easy way. What. The actual log call is split into multiple parts so that the user can overload logMsgPart and add, for instance, structured logging. In order to not have races with the default impl locking was added.
Re: std.experimental.logger formal review round 3
IMO this defeats the design goal off having the default case very easy and just working. Therefore, I think thread local global Logger and how to make them interact is something that should be left to the advanced user.
Re: std.experimental.logger formal review round 3
On Wednesday, 12 November 2014 at 15:05:29 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 12 November 2014 at 12:39:24 UTC, Robert burner Schadek wrote: Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory. Taking a lock when the logging call doesn't flush to disk sounds rather expensive. If you log to a FileLogger it will flush. It is just a costly thing to do. There is no way get the work done but doing it.
Re: std.experimental.logger formal review round 3
On Thursday, 13 November 2014 at 22:13:53 UTC, Marco Leise wrote: Am Wed, 12 Nov 2014 17:56:06 + schrieb Dicebot pub...@dicebot.lv: […] have means to explicitly capture lock on global one from local proxies for optimized bulk logging. That's certainly something that occurred to me when talking with Manu about logging. A locked bulk transfer could be added, maybe replacing the single element transfer function that exists already. Thread local loggers that accumulate logs and pass them on to a global logger seem to be a well known use case. One bad thing about that is that the global log is no longer sorted by time if you write to any file. That would make using the log much more difficult IMO.
Re: std.experimental.logger formal review round 3
On Wednesday, 12 November 2014 at 05:36:40 UTC, Jose wrote: On Tuesday, 11 November 2014 at 15:06:49 UTC, Dicebot wrote: https://github.com/Dicebot/phobos/tree/logger-safety One shared Logger: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1696 One global function that references that shared Logger: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L292 And more importantly a Mutex that is always acquired when writing: https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L1035 Does this mean that if I use this library on a machine that has 32 cores, 100s of threads and 1000s of fiber only one thread/fiber can write at a time no matter the concrete implementation of my logger? Am I missing something or isn't this a non-starter? Thanks, -Jose Only one thread can write to one Logger at a time, also known as synchronization. Anything else is properly wrong. But you can have as many Logger as you have memory.
Re: std.experimental.logger formal review round 3
On Sunday, 9 November 2014 at 21:42:09 UTC, Dicebot wrote: And back to the frontpage. Martin / Robert, have you managed to come to an agreement on conditional level thing? After your last reply we haven't done anything else. I would merge his idea, but there is pushback from your side. Anyway, this idea would not break the api. So I don't think it is a blocking change, IMO.
Re: std.experimental.logger formal review round 3
On Monday, 10 November 2014 at 17:03:31 UTC, Dicebot wrote: On Monday, 10 November 2014 at 11:46:34 UTC, Robert burner Schadek wrote: After your last reply we haven't done anything else. I would merge his idea, but there is pushback from your side. Anyway, this idea would not break the api. So I don't think it is a blocking change, IMO. kk, I'll try contacting him via e-mail if Martin does not return to this thread soon enough :) This proposal may not break API directly but it greatly affects how derivative libraries are supposed to be designed and distributed so I'd prefer to nail it down immediately. I get that There are also some more @safe changes need, I hope to provide another branch with those soon enough (~tomorrow) thank you
Re: std.experimental.logger formal review round 3
I will remove the trusted later this week
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 22:03:18 UTC, Martin Nowak wrote:
On 10/28/2014 07:22 PM, Martin Nowak wrote:
On Tuesday, 28 October 2014 at 12:02:16 UTC, Robert burner
Schadek wrote:
It is a design goal to disable certain LogLevel at CT of a
compile
unit (CU).
e.g. make all logs to trace function template do nothing
One idea to make this working is to use prefixed version
identifiers.
Obviously this is all boilerplate so it could be done in a
mixin
template in std.log.
2nd iteration of that idea.
cat main.d CODE
import std_logger;
LoggerCT!MyApp appLogger = new StdoutLogger(LogLevel.info);
LoggerCT!MyLib libLogger = new StdoutLogger(LogLevel.trace);
void main()
{
appLogger.log!(LogLevel.info)(app);
appLogger.log!(LogLevel.warning)(app);
libLogger.log!(LogLevel.info)(lib);
libLogger.log!(LogLevel.warning)(lib);
Logger rtLogger = appLogger;
rtLogger.log!(LogLevel.info)(rt);
rtLogger.log!(LogLevel.warning)(rt);
}
CODE
cat std_logger.d CODE
enum LogLevel { all, info, trace, warning, error, none }
template minLogLevel(string prefix)
{
mixin(
version (~prefix~LogAll)
enum minLogLevel = LogLevel.all;
else version (~prefix~LogInfo)
enum minLogLevel = LogLevel.info;
else version (~prefix~LogTrace)
enum minLogLevel = LogLevel.trace;
else version (~prefix~LogWarning)
enum minLogLevel = LogLevel.warning;
else version (~prefix~LogError)
enum minLogLevel = LogLevel.error;
else version (~prefix~LogNone)
enum minLogLevel = LogLevel.none;
else
enum minLogLevel = LogLevel.all;
);
}
interface Logger
{
@property LogLevel logLevel();
void write(LogLevel ll, string msg);
}
class StdoutLogger : Logger
{
this(LogLevel l) { _logLevel = l; }
LogLevel _logLevel;
@property LogLevel logLevel() { return _logLevel; }
void write(LogLevel ll, string msg) { import std.stdio;
writeln(ll, : , msg); }
}
/// used for library/app specific version prefixes
struct LoggerCT(string prefix)
{
this(Logger logger) { impl = logger; }
enum versionPrefix = prefix;
Logger impl;
alias impl this;
}
void log(LogLevel ll)(Logger logger, string msg)
{
if (ll = logger.logLevel) // runtime check
logger.write(ll, msg);
}
/// when using a logger with prefix
void log(LogLevel ll, L:LoggerCT!pfx, string pfx)(auto ref L
logger, string msg)
if (ll minLogLevel!pfx)
{
}
void log(LogLevel ll, L:LoggerCT!pfx, string pfx)(auto ref L
logger, string msg)
if (ll = minLogLevel!pfx)
{
if (ll = logger.logLevel) // additional runtime check,
because logger might require a higher log level
logger.write(ll, msg);
}
CODE
dmd std_logger -run main
dmd -version=MyAppLogWarning std_logger.d -run main
dmd -version=MyAppLogError -version=MyLibLogNone std_logger.d
-run main
That can actually be added to the current state of std.logger
without breaking any api. The string mixin, version string
matching isn't really pretty, but it gets the job done. Anyway
IMO your approach presented here and my approach can go hand in
hang. Yours should be propagated as the idiomatic way and if you
really need the crowbar, which you need sometimes, use
StdLoggerDisableX.
Re: std.experimental.logger formal review round 3
The reason for the crowbar sometimes you need to disable all calls to the Logger or any calls to a specific LogLevel in the compile unit, even for Logger not wrapped in LoggerCT.
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 01:37:48 UTC, Martin Nowak wrote: On 10/28/2014 12:58 AM, Robert burner Schadek wrote: Disabling a version at CT of the lib has no consequence to compile units that are not compiled with that version statement. Yes setting a version in my app has no effect on the library, that's the problem because I cannot disable logging in a library. So I'll always have to pay some runtime overhead even though I don't want to use logging. Actually, that is only true for LogLevel given to a log call at runtime. calls to info, trace etc. are guarded with static if. So you're not paying any runtime overhead when calling log functions with LogLevel build in their name.
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 01:42:12 UTC, Martin Nowak wrote: On 10/28/2014 01:01 AM, Robert burner Schadek wrote: is different from the code that has been in the PR for quite some time. And the code you show does exactly what you say and the current code does something different. No it behaves the same. isLoggingActive is a template in phobos doSome is a function in a lib that performs logging and instantiates isLoggingActive main is a function in the app that performs logging and instantiates isLoggingActive and also calls doSome Now which of those functions actually logs depends on the compilation settings of the library, the compilation settings of the app and the logger that's being used. The second two are wanted and disabling a LogLevel at CT of phobos should be banned anyway. But no the less, it is one more option the user has to manipulate the Logger.
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 05:44:48 UTC, Andrei Alexandrescu wrote: Being able to select maximum logging level statically at client application level is a deal maker/breaker for me. The mechanics aren't important but it's likely they will affect the API. So I think that needs to be resolved now, not in a future pull request. Andrei please elaborate. It is a must to be able to disable LogLevel when calling the compiler? Xor the opposite? passing -version=StdLoggerDisableTrace when compiling the user code will yield empty functions (thank you static if) for every call to any function or method having the word trace in its name, like for example trace(My log call); If you call something like log(computeMyLogLevelAtRuntime(), my log data) and that function returns LogLevel.trace and you haved passed -version=StdLoggerDisableTrace at CT of the user code you will have to pay for one if.
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 09:39:24 UTC, Martin Nowak wrote:
On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
Schadek wrote:
Actually, that is only true for LogLevel given to a log call
at runtime. calls to info, trace etc. are guarded with static
if.
So you're not paying any runtime overhead when calling log
functions with LogLevel build in their name.
If I cannot change the version identifiers that a library was
compiled with then the static if is always true. So you have to
perform the check at runtime. The only way around that is to
make
each library function that performs logging a template, be it by
passing a Logger with CT LogLevel or by turning functions into
template functions so that the version identifiers leak into the
library.
every log call is a template function or method already.
The latter is more fragile because the compiler might omit
instatiating a template or it might inline a function.
omitting the instantiation sound like undefined reference.
I don't see the problem with inlining. 1. there are no log
functions only log templates. 2. The version statement will
either leave empty template functions bodies, if(false) { ... }
template functions bodies, or template function bodies that
perform regular LogLevel checks on runtime LogLevel.
We're running in circles here. Lets find a new solution that
allows us to
* dmd -version=StdLoggerDisableLogLevel -- disable a LogLevel at
CT of user code
* that does not require a static Logger LogLevel
* does not leak version statements into phobos
* does not call log template functions where the LogLevel of the
version statement is part of the name, or at least yields empty
bodies for these template functions callls
Re: std.experimental.logger formal review round 3
On Tuesday, 28 October 2014 at 11:11:09 UTC, Martin Nowak wrote: Yep, let's try that. I think part of the misunderstanding is that I'm thinking of an app as user code plus a number of libraries all on top of phobos. Say I have an app using vibe.d and I want to enable logging in my app, but disable it in phobos. Was it even a design goal that logging can be enabled on a per library level? It is a design goal to disable certain LogLevel at CT of a compile unit (CU). e.g. make all logs to trace function template do nothing
Re: std.experimental.logger formal review round 3
On Sunday, 26 October 2014 at 23:45:56 UTC, Martin Nowak wrote: On 10/26/2014 11:29 PM, Robert burner Schadek wrote: And I forgot to add, no better solution presented itself in one year. Well I showed one solution, but reduce it to its essence. If you allow to define a Logger with a LogLevel know at compile time and you statically pass the LogLevel of your message to the logging function you can elide that call. For anything else you need a runtime check. http://dpaste.dzfl.pl/2538c3b5d287 And again I'm saying fixing the LogLevel at CT is not good enough. And the other part of the solution uses class just like std.logger. And the hierarchy you're building is also at CT, which is just not gone work, if you don't have ultimate control of all sources.
Re: std.experimental.logger formal review round 3
On Monday, 27 October 2014 at 07:03:11 UTC, Dicebot wrote: I don't consider it a major issue as I don't think std.logger should be used inside Phobos at all. Yes, using std.logger inside of phobos is a no-no
Re: std.experimental.logger formal review round 3
On Sunday, 26 October 2014 at 23:58:14 UTC, Martin Nowak wrote: On 10/27/2014 12:45 AM, Martin Nowak wrote: If you allow to define a Logger with a LogLevel know at compile time and you statically pass the LogLevel of your message to the logging function you can elide that call. For anything else you need a runtime check. You are trying to globally define a LogLevel through the version identifier but that collides with D's separate compilation. So you cannot enable logging in a library that was compiled with StdLoggerDisableLogging. And vice versa you cannot statically disable logging in a library compiled without StdLoggerDisableLogging. Now if you use StdLoggerDisableLogging in your program the effect on the library will depend on whether or not you're calling a templated function or if the compiler inlined certain library function into your program. It is a good think then that the *DisableLogging versions are only used inside a template that is used inside a templates. Though version statements attached to a phobos compilation should only have impact on the unittest of phobos. Secondly, why would phobos be shipped with certain LogLevel disabled.
Re: std.experimental.logger formal review round 3
On Sunday, 26 October 2014 at 22:57:51 UTC, Martin Nowak wrote:
On 10/26/2014 11:27 PM, Robert burner Schadek wrote:
it is not really a dependency as the one template that uses
the version
identifier uses them optionally.
It simply doesn't work, e.g. you could not statically disable
logging in phobos without recompiling phobos.
cat lib.d CODE
version (StdLoggerDisableLogging)
enum isLoggingActive = false;
else
enum isLoggingActive = true;
void doSome()
{
import std.stdio;
writeln(isLoggingActive: , isLoggingActive);
}
CODE
cat main.d CODE
import lib, std.stdio;
void main()
{
writeln(isLoggingActive: , isLoggingActive);
doSome();
}
CODE
dmd -version=StdLoggerDisableLogging -lib lib.d
dmd main lib.a
./main
If it where done this way, yes of course you're right. But it is
not, please take a look a the source first.
Re: std.experimental.logger formal review round 3
On Monday, 27 October 2014 at 12:03:33 UTC, Dicebot wrote: Ayway, let's come with an agreement/compromise with Martin and I'll start voting immediately after. Well, as far as I can see his argument was based on old code that has long been rewritten and he hasn't answered since I pointed that out.
Re: std.experimental.logger formal review round 3
On Monday, 27 October 2014 at 20:49:35 UTC, Dicebot wrote:
On Monday, 27 October 2014 at 20:42:10 UTC, Martin Nowak wrote:
Say I want to add tracing/logging to
[`parseJson`](http://dlang.org/library/std/json/parseJSON.html)
or
[`findRoot`](http://dlang.org/phobos/std_numeric.html#.findRoot)
This is exactly what is wrong :) Using std.logger inside Phobos
itself is a big no. Actually even finding yourself in position
where you may want to do it indicates some Phobos design issue.
Yes and No. His Logger can came from the user aka. outside of
phobos. That might just be valid. But the problem with the design
is that he needs to accept every possible Logger. And that either
means template of abstract class Logger.
The problem with a template is:
``` library code that is given in binary form
auto fun(Logger l) {
return parseJson(getData(), l);
}
```
their is no choice but to pass a class. Meaning you have to wrap
the struct Logger with a class proxy. And this will properly
develop into a common theme.
Allowing struct has one design problem IMO:
Either we force to callee to accept Logger as template or
we force the caller to wrap his Logger struct with Logger proxy
classes.
This is because an abstract class is the lowest common
denominator in this case.
Anyway, I'm pretty sure that Martin and I will never see eye to
eye in this discussion. IMO disabling a single Logger through its
LogLevel at compile (plus all the extra litter and possible
needed wrapping) is no better than creating NullLogger. He thinks
the opposite.
The problem for me now is, if I add a struct UFCS overload Martin
will be happy but somebody else will stream WAT The struct stuff
must go
So please everybody reading this, please give a comment about
this.
Re: std.experimental.logger formal review round 3
On Monday, 27 October 2014 at 22:27:12 UTC, Martin Nowak wrote: On 10/27/2014 09:28 AM, Robert burner Schadek wrote: If it where done this way, yes of course you're right. But it is not, please take a look a the source first. I'm looking at https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d and this is exactly how this works. take a look at https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L190 and https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d#L579 isLoggingActiveAt is instantiated at CT of the log function and the version statement inside the first link is evaluated at that moment. Disabling a version at CT of the lib has no consequence to compile units that are not compiled with that version statement. I tested it at https://github.com/burner/logger/blob/master/Makefile#L23 run make info
Re: std.experimental.logger formal review round 3
On Monday, 27 October 2014 at 22:20:04 UTC, Martin Nowak wrote:
On 10/27/2014 01:36 PM, Robert burner Schadek wrote:
Well, as far as I can see his argument was based on old code
that has
long been rewritten and he hasn't answered since I pointed
that out.
How do come to that insight?
because the code you show as an example:
cat lib.d CODE
version (StdLoggerDisableLogging)
enum isLoggingActive() = false;
else
enum isLoggingActive() = true;
void doSome()
{
import std.stdio;
writeln(loggingLib: , isLoggingActive!());
}
CODE
is different from the code that has been in the PR for quite some
time. And the code you show does exactly what you say and the
current code does something different.
Re: std.experimental.logger formal review round 3
On Sunday, 26 October 2014 at 22:27:55 UTC, Robert burner Schadek wrote: The dependency on external version identifiers in phobos is still a complete bummer it is not really a dependency as the one template that uses the version identifier uses them optionally. And I forgot to add, no better solution presented itself in one year.
Re: std.experimental.logger formal review round 3
On Sunday, 26 October 2014 at 22:12:20 UTC, Martin Nowak wrote: On 10/25/2014 06:43 PM, Dicebot wrote: Because of that I am going to start voting despite some arguments being still in process. I hope that won't cause any tension. The dependency on external version identifiers in phobos is still a complete bummer and there are still many implementation issues. One reason why this is taking so long is that there were many issues some of which still need to be addressed. it is not really a dependency as the one template that uses the version identifier uses them optionally. please name the issues that are not because of the gc.
Re: std.experimental.logger formal review round 3
On Friday, 24 October 2014 at 11:01:40 UTC, Martin Nowak wrote: On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek wrote: What's stopping an interface or class to implement a logging concept? Same as last time: Logger[], Logger without a LogLevel not real useful IMO, (new) no thread safety by default I don't understand your answer. Do you have a link to your last response. You can not tell if the Logger will log a message, because you can't know its LogLevel. It is not thread safe because the interface can't have an implementation. Therefore the default implementation is not thread safe.
Re: std.experimental.logger formal review round 3
On Friday, 24 October 2014 at 09:53:57 UTC, Dicebot wrote: Will start review round in ~2 days. I am very sorry for delay :( No problem the PR has been open since Aug. 2013, one or two weeks more or less don't really matter anymore ;)
Re: Really in need of help with std.container.array.d
On Wednesday, 15 October 2014 at 21:15:14 UTC, Nordlöw wrote: Comint exited abnormally with code 1 at Wed Oct 15 23:14:37 I'm stuck. Need help. I will give it a try
Re: std.experimental.logger formal review round 3
On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote: As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :) No need, I fixed the MultiLogger last weekend.
Re: std.experimental.logger formal review round 3
On Wednesday, 15 October 2014 at 10:12:56 UTC, Jakob Ovrum wrote: On Wednesday, 15 October 2014 at 09:25:07 UTC, Robert burner Schadek wrote: On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote: As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :) No need, I fixed the MultiLogger last weekend. Fixed by simply removing the attempt at logarithmic time operations, and still not conforming to the Phobos container interface... Yes, because other people already complained that nobody will every need a logarithmic time MulitLogger and I always thought that MultiLogger was to complex anyway. I could make the Logger[] array alias this and it would be comforming to Phobos container, but that doesn't really solve the issue does it.
Re: Parameterized unit testing and benchmarking of phobos
On Tuesday, 14 October 2014 at 06:54:42 UTC, Martin Nowak wrote: On 10/08/2014 11:37 PM, Robert burner Schadek wrote: Lately, I find myself wondering, if I should add parameterized unit tests to std.string, because the last few bugs I fixed where not caught by tests, as the test-data was not good enough. I know random data is not perfect either, but it would be good addition IMO. https://github.com/MartinNowak/qcheck Haven't used it for quite a while, file a bug report if anything doesn't work. well quite a nice and big library. You add the benchmark feature, get a merged into phobos and I will gladly use it to test std.string.
Re: Parameterized unit testing and benchmarking of phobos
On Tuesday, 14 October 2014 at 12:17:05 UTC, Martin Nowak wrote: On 10/14/2014 10:38 AM, Robert burner Schadek wrote: well quite a nice and big library. You add the benchmark feature, get a merged into phobos and I will gladly use it to test std.string. Not sure whether a random testing library belongs into phobos. After taking a look at the bug I found in std.string, I think that this is a good first step.
Re: Really in need of help with std.container.array.d
On Tuesday, 14 October 2014 at 12:51:29 UTC, Nordlöw wrote:
Could you please give me a code example? I'm not skilled enough
in D to follow this description.
struct Range(T) {
Array!S array;
T opIndex(size_t i) {
return cast(T)array[i];
}
}
struct Array(T) {
Range!(const(T)) opSlice() const {
return Range!(const(T))(cast(Array!T)array, 0, length);
}
Range!(T) opSlice() const {
return Range!(T)(cast(Array!T)array, 0, length);
}
}
Re: Really in need of help with std.container.array.d
hm, the problems seams to be that inout Array is not becoming const Array and friends. A blunt force solution would be to create a range as Range!(ReturnType!Array...)(cast(Array!T)this, low, high); and then do the correct casts in Range. The ReturnType would be the ReturnType of opIndex of the Range type and the Array would be stored as plain array without any qualifier. other than that I'm not sure how to go about this.
Re: ini library in OSX
On Saturday, 11 October 2014 at 22:38:20 UTC, Joel wrote: On Thursday, 11 September 2014 at 10:49:48 UTC, Robert burner Schadek wrote: some self promo: http://code.dlang.org/packages/inifiled I would like an example? go to the link and scroll down a page
Re: std.experimental.logger formal review round 3
On Sunday, 12 October 2014 at 09:07:37 UTC, Jacob Carlborg wrote: On 2014-10-11 15:34, Robert burner Schadek wrote: - Why do loggers have to be classes? As answered multiply times before, to build log hierarchies. What's stopping an interface or class to implement a logging concept? Same as last time: Logger[], Logger without a LogLevel not real useful IMO, (new) no thread safety by default
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 23:37:42 UTC, Marco Leise wrote: I had the same feeling as Jakob about an `Appender` already in the base class and would have expected a bare bones abstract class + a batteries included version using `Appender`. (A bit like Java's …Listener and …Adapter classes.) That seems more clean to me in a representational fashion. Technically we can just ignore the extra field... It also seems legit to reduce pressure on the GC, by resetting the `Appender` instead of nulling it. What if a Logger down the chain keeps the string around and you overwrite it?
Re: Parameterized unit testing and benchmarking of phobos
On Friday, 10 October 2014 at 14:20:39 UTC, Jacob Carlborg wrote: On 10/10/14 10:09, Robert burner Schadek wrote: This will work for me private project, but I want this in std.string. Why wouldn't this working std.string? because, this would require changing the phobos unittester, doing it non intrusive inside the unittest is way more likely to succeed. add is more flexible IMO.
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 10:48:00 UTC, Jacob Carlborg wrote: On 2014-10-11 05:41, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) I think it's unacceptable that the documentation of defaultLogFunction and trace, info and so on is merged. Same thing with memLogFunctions. Do these even need to be exposed? this has been used make user defined LogLevel log functions, like trace1(...), trace2(...)
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 04:31:17 UTC, Jakob Ovrum wrote: On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) Attributes need to be applied thoroughly. Even if most uses will be through the base class `Logger`, it's still useful to have stronger guarantees through a derived class reference. This is particularly important because it's an important design decision to choose which attributes to apply to `Logger`'s methods. @trusted is used everywhere instead of properly using @safe and minimized @trusted. I think this is the third time I point this out... The multiloggers are a complete mess. There's both `ArrayLogger` and `MultiLogger`, and while `ArrayLogger` has simple O(n) operations, `MultiLogger` is a disaster: insertion iterates all elements twice and sorts the entire collection on every call, and removal iterates all elements once, then does binary search twice. Once using `SortedRange`'s search, and once using its own binary search algorithm. It also contains debug code that writes to stdout. Neither type adheres to the Phobos container concept, instead the underlying array is exposed as a public, undocumented field. `string` is used instead of `const(char)[]` for search and removal operations. The latest std.container.Array broke the code anyway, so it is due for a rewrite anyway. The implementation of `Logger` has several performance problems. `Logger` provides default behaviour that allocates GC memory multiple times for even the simplest log messages through the `Appender`. I don't think this behaviour should be encouraged by putting it in the root logger class, and besides, it can be made much more intelligent than just using a new appender for each message. Well, to have ultra simple thread-safe sub classing (which is an important part of the design), this was the price. This being said. Doing it nogc yourself if you know the output is very easy as shown in FileLogger. Another issue is that the way it's written currently, `writeLogPart` is called a lot more often than necessary, without any opportunity for optimization within `formattedWrite`, thus `FileLogger` is doomed to write to the underlying file character-by-character in easily reproducible circumstances (e.g. log a range of characters); this issue probably doesn't affect the API though. Again, by design. To allow user created structured logging, this is necessary. `Logger` has a bunch of public and documented `*Impl` functions... see my other post Some other line comments I posted a while ago have not been addressed. I will recheck github
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 13:16:18 UTC, Martin Nowak wrote: On 09/28/2014 02:24 PM, Dicebot wrote: Important changes since last review: - new approach for compile-time log level filtering What's new here? It still relies on version identifiers to do so. As I said in some earlier review, I think it's a bad idea for a library to rely on version identifiers that are defined in client code. I will only work for templated code and makes it much harder for build tools. In a way it's the equivalent of #define LOG_LEVEL 2 #include logger.h All that code is contained in 30 line template, That is by far the best working option anybody could come up with I even proposed an alternative that uses type tags instead. http://dpaste.dzfl.pl/95fb6a4e086d And I showed that it did not work. - Documentation is out of sync. gh-page is yes, give me 15min - ArrayLogger seems to do about the same as MultiLogger have you read my reply to Jacob - Why do loggers have to be classes? As answered multiply times before, to build log hierarchies.
Re: std.experimental.logger formal review round 3
On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote: I don't see critical objections so far and this will move to voting stage this weekend. Please hurry up if you want to say something bad :) MultiLogger got a new simpler impl.
Re: Parameterized unit testing and benchmarking of phobos
On Friday, 10 October 2014 at 06:39:25 UTC, Jacob Carlborg wrote: I think you should use a UDA's instead. The a unit test framework can, hopefully, handle this automatically. This will work for me private project, but I want this in std.string.
