On 10/17/2013 04:13 AM, Eric Anderton wrote:
On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu wrote:
Eric, could you please enumerate a short list of features of log4j
that you think would be really missed if absent?
Certainly. Here's my top 3, with some background to explain
On 10/16/2013 01:34 AM, Jeremy Powers wrote:
On Tue, Oct 15, 2013 at 8:17 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org
wrote:
One note - log4j, log4cxx, and log4cpp are not part of the
respective languages' standards. That doesn't mean
as needed w/o code calling log() caring or changing.
On Wed, Oct 16, 2013 at 12:30 AM, Robert Schadek realbur...@gmx.de
mailto:realbur...@gmx.de wrote:
no hierarchical logs, KISS just create a logger with different
destination. new FileLogger(myDevLog); $ tail -f myDevLog
Without
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,
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
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.
On 10/15/2013 09:40 AM, Sönke Ludwig wrote:
Am 14.10.2013 20:24, schrieb Robert Schadek:
On 10/14/2013 04:44 PM, Sönke Ludwig wrote:
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
On 10/15/2013 09:44 AM, ilya-stromberg wrote:
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
On 10/15/2013 10:49 AM, ponce wrote:
What are the philosophy behind errors vs fatal errors vs critical errors?
When should we use each of these?
fatal = the application is going down, I'm just letting you know
critical = the application is maybe going down, I'm not sure yet, but
this is a
On 10/15/2013 02:54 PM, Sönke Ludwig wrote:
What I meant is just that in Druntime there is something like this:
struct LogManager {
static void somefunc();
}
instead of
class LogManager {
static void someFunc();
}
In any case, such a struct/class should also have a member @disable
On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
Am 15.10.2013 10:41, schrieb Robert Schadek:
On 10/15/2013 02:44 AM, Kapps wrote:
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
On 10/15/2013 03:31 PM, ilya-stromberg wrote:
On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
On 10/15/2013 04:06 AM, Eric Anderton wrote:
On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
Here's what I think is missing:
- System log support (as others have
On 10/15/2013 03:54 PM, Dicebot wrote:
On Tuesday, 15 October 2013 at 13:31:40 UTC, ilya-stromberg wrote:
...
I think such stuff should go as an extra module in same package with
various useful out-of-the box logger implementations at the very best.
Probably even dub package built on top of
On 10/15/2013 03:57 PM, Dicebot wrote:
On Tuesday, 15 October 2013 at 13:52:17 UTC, Robert Schadek wrote:
I think this is good, as it gives you a way to quite libraries down. The
idea behind the free standing log function is to provide an ultra easy
way to log. It is not meant to be used
On 10/15/2013 04:12 PM, Sönke Ludwig wrote:
Believe it or not, for some reason I suspected as much.
Yes, but the point is that when looking only at func1, you might
expect that all messages are logged as debug messages, but the last
one will be logged as a warning instead. func2 may be
On 10/15/2013 04:17 PM, ilya-stromberg wrote:
On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
But if it's available people _will_ use it in complex contexts. Also
if the writer of a 28 loc library uses it and the library is used
by a large piece of software, that will also be
On 10/15/2013 04:23 PM, ilya-stromberg wrote:
On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
Logging is the most unpure functionality I can think of. It is side
effect heaven.
Yes, but we should minimise possible side effects.
Of course, but having global state aka
On 10/15/2013 05:20 PM, Johannes Pfau wrote:
I think one increasingly important point for std.log is 'structured
logging'.
Structured logging is basically not simply logging textual messages, but
also logging additional KEY/VALUE pairs of data. The idea is that logs
should not only be
On 10/14/2013 12:28 PM, Abdulhaq wrote:
Also, does SMOKE do anything for you in terms of signals and slots,
and QVariants?
Signal and Slots are sort of replaced by normal methods and a
different connect function in Qt5, which is awesome, because you will
get compile time errors instead of
On 10/14/2013 02:39 PM, Sönke Ludwig wrote:
Am 14.10.2013 13:39, schrieb Dicebot:
As `std.logger` is still marked as work in progress this thread is
less formal that typical pre-voting review. Goal is to provide as much
input about desirable `std.logger` functionality and current state and
On 10/14/2013 02:42 PM, Vladimir Panteleev wrote:
Would be nice if either FileLogger, or a proxy logger available to
users, would add timestamps. Timestamps are very useful for log files,
as they allow to correlate logged events with other events on the
system (e.g. other applications' log
On 10/14/2013 02:32 PM, Martin Drasar wrote:
Having skimmed through the docs I noticed that there are three features
missing that I use and would like to see in standard logger. First is
the ability to write to several loggers at once, the second is optional
formatting of log output and the
On 10/14/2013 02:51 PM, Andrea Fontana wrote:
Just for comparison, on Android you can write something like:
FileLogger.w(...) instead of FileLogger.log(LogLevel.Warning...)
(and there's a wtf loglevel for temporary debugging)
hm, I don't really like it. To me it sounds like, I'm don't care
On 10/14/2013 03:31 PM, Martin Drasar wrote:
On 14.10.2013 15:18, Robert Schadek wrote:
On 10/14/2013 02:32 PM, Martin Drasar wrote:
1) MultiLogger class that takes references to other loggers and just
forwards the call to the log function.
will be done, see the reply to Sönke's post.
Cool
On 10/14/2013 05:27 PM, ilya-stromberg wrote:
Add e-mail logger (useful for critical errors) for example via
`std.net.curl.SMTP`.
And than at a email format config parser that fulfills everyones wishes,
would bet the idea of the design. And I though people where trying to
remove curl.
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
On 10/14/2013 08:29 PM, ilya-stromberg wrote:
I said: for example via `std.net.curl.SMTP`. If you don't want to
use curl, you shouldn't. But yes, I think that e-mail logger can be
useful. For example Linux use it (and bash can send errors via e-mail).
About email format config parser that
On 10/14/2013 08:55 PM, Sean Kelly wrote:
It's weird that LogManager.defaultLogger exists as a read-only
property, and if I want to change it I have to use the global static
log variable.
this will be properly be fixed in the next incarnation (tonight, no
promises)
I think this was mentioned
On 10/14/2013 09:59 PM, ponce wrote:
Thanks for taking care of that.
My logger class logs warning in yellow and errors in red ;),
colors are awesome I now, but hard to do across all shells and even
worse when you want to pipe the messages in a file afterwards. So I
suggest you implement your own
On 10/14/2013 11:01 PM, Sean Kelly wrote:
On Monday, 14 October 2013 at 20:49:19 UTC, Robert Schadek wrote:
I disagree on having a simple email layer among the default logger,
because I feel that having this special logger in would water the
design of the logging module. Maybe you are happy
On 10/14/2013 07:01 PM, Jeremy Powers wrote:
Some comments from the peanut gallery:
* Mentioned already: configurable log output. Configure
style/contents of log output based on output location. More options
for included info (thread id, etc). Allow custom info to be inserted
based on
On 10/14/2013 11:10 PM, Guillaume Chatelet wrote:
It is useful but it's also a pain to configure. I used logback (
http://logback.qos.ch/ ) which is a bit nicer but still... We should
definitely step away from XML's configuration mess.
Did somebody say XML, I first cast a stone. ;-) But
On 10/10/2013 09:33 AM, Jonathan M Davis wrote:
I honestly don't think we can solve it a different way without completely
redesigning shared. shared is specifically designed such that you have to
either cast it way to do anything with it or write all of your code to
explicitly work with
On 10/10/2013 03:45 AM, Walter Bright wrote:
Rainer Schuetze wrote:
You have to put the lock around the pair of AddRef and Release, but if
the compiler already splits this into two function calls, this cannot
be done in the implementation.
I would imagine the counter to be manipulated with
On 10/09/2013 04:22 AM, Andrei Alexandrescu wrote:
* Get Robert Schadek's precise GC in. Walter and I have become 101%
convinced a precise GC is the one way to go about GC.
I would like to claim that work, but the Rainer Schütze wrote that. I
know, both german, same initials.
On 10/04/2013 12:02 PM, John Colvin wrote:
Adding new (or replacement) phobos modules without wider testing is
not a scalable approach for D.
New modules go from unofficial to official in a single step and are
therefore inadequately battle-tested before becoming part of the
somewhat ossified
On 10/04/2013 09:07 AM, Dicebot wrote:
P.S. I have tried contacting you in context of std.logger, is mail
address mentioned on github valid one? If not, please ping me via
public.dicebot.lv
Yes it is, strange. Try the one I use here.
On 10/04/2013 04:36 AM, David Nadlinger wrote:
Maybe you can elaborate a bit on how the problem occurs in that
context? As I said, I've found that usually it is possible to come up
with a design at least as pretty (or even prettier) but doesn't rely
on stringof trickery if one just stares at
I have some found some irregular behavior when using mixins with
template and modules. If a aggregation is defined in the same module it
is found. If the aggregation is defined in another module it fails. And
I wonder if this is be design. For comparison see the code below.
// file: moduleA.d
On 10/03/2013 08:10 PM, David Nadlinger wrote:
On Thursday, 3 October 2013 at 17:52:13 UTC, Robert Schadek wrote:
dmd moduleA.d moduleB.d -ofmix -unittest
moduleA.d(4): Error: undefined identifier Foo
moduleB.d(10): Error: template instance A.func!(Foo) error instantiating
Yes
On 09/23/2013 07:16 PM, Andrei Alexandrescu wrote:
On 9/23/13 10:01 AM, deadalnix wrote:
Finally, we got to decide how these basics block are used to form typed
allocators, and interact with language constructs.
Sure. Again: I describe the Otto cycle and you discuss how to paint
the road.
On 09/23/2013 09:11 PM, Andrei Alexandrescu wrote:
On 9/23/13 11:55 AM, Robert Schadek wrote:
On 09/23/2013 07:16 PM, Andrei Alexandrescu wrote:
On 9/23/13 10:01 AM, deadalnix wrote:
Finally, we got to decide how these basics block are used to form
typed
allocators, and interact
On 09/12/2013 12:09 AM, Manfred Nowak wrote:
Walter Bright wrote:
Since the very beginning.
One example is determining if something is a declaration or an
expression.
I see now, that you wrote about parsing---not about lexing.
Btw. I wrote an LALR(1)-parser for an early version of D.
On 09/12/2013 04:21 AM, Martin Nowak wrote:
On 09/12/2013 03:39 AM, Walter Bright wrote:
On 9/11/2013 6:30 PM, deadalnix wrote:
Indeed. What solution do you have in mind ?
The solution dmd uses is to put in an intermediary layer that saves the
lookahead tokens in a linked list.
Linked list
On 09/12/2013 11:03 PM, Dmitry Olshansky wrote:
Maybe some fixed size stack vector with 64 elements or so and some
linked list for the unusual case would help ..
And an extra branch to detect which one is currently the case? No,
thanks ;)
I would think that branching and using the vector is
On 09/10/2013 03:45 PM, Dicebot wrote:
done and done (the design of my logger is based on what I distilled from
the old discussion)
Thanks! You will be next after Brian then (pardon me for wanting
std.d.lexer so much :P)
No problem, it might be good though to get so bashing beforehand to
On 09/10/2013 01:43 PM, Dicebot wrote:
You should add it to http://wiki.dlang.org/Review_Queue then, there is
also a link to an old review thread of `std.log` by Jose Armando
Garcia which may be of interest to you as people are likely to ask
similar questions :)
done and done (the design of my
On 09/09/2013 04:21 PM, Dicebot wrote:
While Jacob is working on improving std.serialization, there is some
time to do more reviews. Review manager role does not seem to be very
stressing, so I can step up as one for any of the projects currently
in queue as soon as their authors express the
Most awesome
On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
If I had to vote though, I'd vote against this, because I think that
it's a bad paradigm, and I don't want to deal with it.
+1
On 08/22/2013 05:06 PM, Johannes Pfau wrote:
I'm getting wired auto-tester erros
setting up remote topull - https://github.com/burner/phobos.git
fetching contents of https://github.com/burner/phobos.git
From https://github.com/burner/phobos
* [new branch] 10472 - topull/10472
* [new
On 09/01/2013 08:43 PM, Andrej Mitrovic wrote:
On 9/1/13, Manu turkey...@gmail.com wrote:
None of the others could be bothered creating yet-another-webpage-account to
log bugs
they encountered. I suggested they do so a few times. I was promptly ignored.
It's just that manually logging in to
On 09/02/2013 11:55 AM, deadalnix wrote:
I don't think that githubing everything is a wise move.
ok, why do you think that?
On 08/29/2013 09:51 AM, Johannes Pfau wrote:
I most points here also apply to std.xml:
http://wiki.dlang.org/Wish_list/std.json Those are not strict
requirements though, I just summarized what I remembered from old
discussions.
I think, this even extends to access to all semi- and
On 08/29/2013 11:09 AM, Jacob Carlborg wrote:
So you want serialization :). Which we currently are reviewing.
Unfortunately there might be too many changes needed to get it in
Phobos this time.
well, sort of, but also with partial serialization (think sql update),
more transparent interface
On 08/23/2013 11:49 PM, Andrei Alexandrescu wrote:
On 8/23/13 1:10 PM, Robert Schadek wrote:
On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
(Just hanging this to a random comment in this thread.) I think
there's some pretty good work on logging by myself and another poster
(Jose
On 08/24/2013 08:01 PM, Jonathan M Davis wrote:
On Saturday, August 24, 2013 16:49:24 SomeDude wrote:
OTOH, they are used in just about every logging API ever devised.
Everybody knows what they mean. I just don't see the need to
reinvent these words and make them longer by adding log. I
On 08/23/2013 02:07 AM, Piotr Szturmaj wrote:
W dniu 22.08.2013 16:00, Robert Schadek pisze:
Docu:
http://burner.github.io/phobos/phobos-prerelease/std_logger.html
What about specifying log level at runtime, e.g.:
// set by the user at runtime
LogLevel userLogLevelForX;
log
On 08/23/2013 07:15 AM, Artem Tarasov wrote:
http://burner.github.io/phobos/phobos-prerelease/std_logger.html
6 params to logMessage and writeMsgToLog is way too many.
First four of them should be merged into a single struct representing
the location.
I would argue that merging them into a
On 08/23/2013 10:30 AM, Piotr Szturmaj wrote:
?
Any other Logger:
auto myCoolLogger = new Logger();
myCoolLogger.logLevel = LogLevel.Critical;
For the default Logger:
log.logLevel = LogLevel.Info;
I see, but isn't separate class instance for every log level a bit too
much? Setting
On 08/23/2013 12:00 PM, growler wrote:
Is there any plan to support remote logging? This would be great for
embedded stuff we're playing with.
G.
Not buildin, but the logger is designed to be easily extended. So if
needed, roll your own.
On 08/23/2013 01:10 PM, Piotr Szturmaj wrote:
so if I have a LogLevel variable I want to use:
LogLevel myLogLevel;
I need to write this:
# alternative 1 (possibly wrapped in a function)
switch (myLogLevel)
{
case LogLevel.Info: log.Info(...); break;
case LogLevel.Warning:
On 08/23/2013 02:56 PM, Piotr Szturmaj wrote:
W dniu 23.08.2013 14:16, Robert Schadek pisze:
On 08/23/2013 01:10 PM, Piotr Szturmaj wrote:
so if I have a LogLevel variable I want to use:
LogLevel myLogLevel;
I need to write this:
# alternative 1 (possibly wrapped in a function)
switch
On 08/23/2013 06:28 PM, Gary Willoughby wrote:
On Thursday, 22 August 2013 at 14:13:29 UTC, Robert Schadek wrote:
lots..
Just to weight in and give my four penneth. It needs to be made a
little more flexible in the formats it produces (syslog?) and the
input it takes. e.g. i've just finished
On 08/23/2013 07:21 PM, Gary Willoughby wrote:
I don't think you can bloat a simple logger too much with templates.
It's a pretty simple framework.
every log call with more than a string will be a template. My first
private logger version was like this.
After reading the last logger thread and
On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
(Just hanging this to a random comment in this thread.) I think
there's some pretty good work on logging by myself and another poster
(Jose?) that has since gone abandoned. It included some nice approach
to conditional logging and had both
On 08/23/2013 10:34 PM, Jacob Carlborg wrote:
On 2013-08-23 18:48, Robert Schadek wrote:
I do as well, but this will lead to template bloat, as many people will
tell you, and log(device id: %s.format(device.id)); is
not so bad.
Won't it be just as much template bloat using format?
well yes
On 08/23/2013 10:08 PM, Jonathan M Davis wrote:
On Friday, August 23, 2013 21:47:44 Johannes Pfau wrote:
Make the templated function a stub which redirects to a function which
uses normal function arguments and rely on inlining?
Inlining will have no effect on __FILE__ and __LINE__, and it
I'm still missing a logging facility in D and as the last attempt seam
to have stopped I want to throw
in my version. After reading through the std.log thread I made my
conclusions and created my own
logger. People seamed to be unhappy with the naming and the way of
configuration.
Additionally
On 08/22/2013 05:06 PM, Johannes Pfau wrote:
It would be nice to finally have logging in phobos.
Two small nit-picks:
The API doesn't follow the phobos naming conventions: functions (error,
fatal, ...) need to start with a lowercase letter. Same for enum
members. See
On 08/22/2013 05:32 PM, Craig Dillabaugh wrote:
On Thursday, 22 August 2013 at 15:17:16 UTC, Robert Schadek wrote:
On 08/22/2013 05:06 PM, Johannes Pfau wrote:
It would be nice to finally have logging in phobos.
Two small nit-picks:
The API doesn't follow the phobos naming conventions
On 08/22/2013 05:38 PM, Robert Schadek wrote:
logMessage is meant to do the actual logging. And IMO it is to much to long.
But keep the ideas coming there must be a sweet spot somewhere.
sry, logMessage is meant to figure out if the LogLevel of the message
makes it worthy to be printed
On 08/22/2013 05:51 PM, Craig Dillabaugh wrote:
Do you really find the three extra characters a big problem.
Log() vs. logLog() //OK, that is kind of ugly.
Info() vs logInfo()
Warning() vs logWarning()
Error() vs logError()
Its only three extra characters and they are all in the sweet
On 08/22/2013 05:59 PM, Jacob Carlborg wrote:
My suggestion is you define a single function log. This returns an
instance of the current/default logger. The logger, be it a struct or
class, have one method for each logging level. The default logging
level would use opCall, resulting in this
On 08/22/2013 06:01 PM, develop32 wrote:
Why logging functions accept only a string? I would expect it to
behave as std.stdio with its variadic parameters.
It would be more straightforward to write logging code:
log(Moving , data, to , destination);
Where 'data' and 'destination' are any
On 08/22/2013 06:17 PM, Jacob Carlborg wrote:
On 2013-08-22 18:02, Robert Schadek wrote:
With my suggestion you can use the with-statement as well if you are
performing a lot of logging:
with (log)
{
error(bar);
info(foo);
}
yes, I believe you're right, but I have not coded
On 08/22/2013 07:48 PM, Johannes Pfau wrote:
The problem is that format allocates using the GC. Functions like
writefln can be much more efficient so if the backend is a FileLogger it
could take advantage of that. But IIRC it's not simple to implement
this 'forwarding' with classes /
On 08/22/2013 08:17 PM, Johannes Pfau wrote:
Am Thu, 22 Aug 2013 20:04:16 +0200
schrieb Robert Schadek realbur...@gmx.de:
On 08/22/2013 07:48 PM, Johannes Pfau wrote:
The problem is that format allocates using the GC. Functions like
writefln can be much more efficient so if the backend
On 07/08/2013 09:04 PM, Flamaros wrote:
http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/
Is D and DMD aware of those kind of issues with atomic?
OT: How does he change slides? I can't see a clicker nor a sign for
somebody off camera?? Anyway, awesome
On 06/26/2013 12:50 AM, Adam D. Ruppe wrote:
On Tuesday, 25 June 2013 at 22:22:09 UTC, cybervadim wrote:
(introducing a new keyword allocator)
It would be easier to just pass an allocator object that provides the
necessary methods and don't use new at all. (I kinda wish new wasn't
in the
Imagine we have two delegates:
void* delegate(size_t); // this one allocs
void delegate(void*);// this one frees
you pass both to a function that constructs you object. The first is
used for allocation the
memory, the second gets attached to the TypeInfo and is used by the gc
to
On 06/26/2013 10:06 PM, Marco Leise wrote:
Does it mean 16 extra bytes for every allocation ?
yes, or wrap it, and you have 4 or 8 bytes, but yes you would to have
save it somewhere
+1
Has anyone uploaded their pictures yet? I'm really looking forward to
see them.
On 04/26/2013 07:02 AM, Walter Bright wrote:
A bool is an integer with the range 0..1
This is True for the type but for the actual code it looks different.
There 0 == false. and everything else is true.
import std.stdio;
void main() {
if(10) {
writefln(%d is also true, 10);
}
}
On 03/18/2013 11:17 PM, Martin Nowak wrote:
On 01/20/2013 01:31 PM, Robert BuRnEr Schadek wrote:
On 01/17/2013 01:45 PM, dennis luehring wrote:
maybe Robert Schadek is available to speak about his Distributed
Multithreading Caching D Compiler
http://www.svs.informatik.uni-oldenburg.de
Hi,
I have a Deque implementation that I really like. I would like to get
some comments on it.
http://dpaste.1azy.net/4bf119e7 dpaste does not run the unittests
successfully. I don't
know why. I tested on a x32 as well as x64 machine and it works on both.
Best Regards
Robert
On 01/29/2013 08:55 PM, bearophile wrote:
Robert Schadek:
I have a Deque implementation that I really like. I would like to get
some comments on it.
http://dpaste.1azy.net/4bf119e7 dpaste does not run the
What's the structure of the data it keeps?
I'd like a deque implemented as a growable
On 01/29/2013 09:16 PM, Timon Gehr wrote:
On 01/29/2013 08:55 PM, bearophile wrote:
Robert Schadek:
I have a Deque implementation that I really like. I would like to get
some comments on it.
http://dpaste.1azy.net/4bf119e7 dpaste does not run the
What's the structure of the data it keeps
On 01/29/2013 09:34 PM, Walter Bright wrote:
On 1/29/2013 11:44 AM, Robert Schadek wrote:
I have a Deque implementation that I really like. I would like to get
some
comments on it.
One thing that jumped out at me was the declaration of Iterator. D
convention is to use ranges, not iterators
On 01/29/2013 09:20 PM, monarch_dodra wrote:
On Tuesday, 29 January 2013 at 19:44:23 UTC, Robert Schadek wrote:
Hi,
I have a Deque implementation that I really like. I would like to get
some comments on it.
http://dpaste.1azy.net/4bf119e7 dpaste does not run the unittests
successfully. I don't
On 01/24/2013 10:56 PM, Adam Wilson wrote:
On Thu, 24 Jan 2013 13:54:09 -0800, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/24/13 4:08 PM, Adam Wilson wrote:
On Thu, 24 Jan 2013 12:58:41 -0800, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/24/13 3:45 PM,
101 - 191 of 191 matches
Mail list logo
