I have a request for version support. Currently the debug or version specification can be an identifier or a number. The number for debug seems fairly clear but I can't think why one would use a simple number for version control. It seems like it would be pretty common to want both a custom identifier and a level number. For example in my case right now I have some simple logging support for MinWin debugging and it's getting to the point where I want different logging levels. Up to now my logging API has been

 version (LOG) log.writefln("about to call foo with r=%d",r);
 foo(r);.

Now what I'd like to be able to write is something like

 version (LOG=3) log.writefln("about to call foo with r=%d",r);
 foo(r);.

and have the same semantics as the version/debug level. One problem is how
to write the specification. Without a level the specification is
 version = LOG;

Possible syntax for supporting both id and level is something like
 version = LOG : 3;

Whatever is done it should also be available from the command-line.

-Ben

Ben Hinkle wrote:

> I have a request for version support. Currently the debug or version specification can be an identifier or a number. The number for debug seems fairly clear but I can't think why one would use a simple number for version control. It seems like it would be pretty common to want both a custom identifier and a level number. For example in my case right now I have some simple logging support for MinWin debugging and it's getting to the point where I want different logging levels. 

I agree that having a number attached to a version would be useful,
but if you only want debugging and logging then do check out Log4J:
http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classLogger.html
It comes in the mango.log module, ported from the original Java Log4J:
http://logging.apache.org/log4j/docs/documentation.html


Here is the workaround I use,
http://www.digitalmars.com/d/archives/digitalmars/D/11946.html

this in C:
> #define VERSION 2
>
> #if (VERSION > 2)
> // do stuff
> #endif

becomes in D:
> version = VERSION_1;
> version = VERSION_2;
>
> version (VERSION_2) {
> // do stuff
> }

It gets boring around 10 or so...


version (VERSION > 2) would be just as useful as the version (!VERSION)
that has already been suggested and implemented as #ifndef alternative.
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2522

Guess we'll just have to wait for Walter's opinion.
--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:ctnfu6$2usk$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>> I have a request for version support. Currently the debug or version specification can be an identifier or a number. The number for debug seems fairly clear but I can't think why one would use a simple number for version control. It seems like it would be pretty common to want both a custom identifier and a level number. For example in my case right now I have some simple logging support for MinWin debugging and it's getting to the point where I want different logging levels.
>
> I agree that having a number attached to a version would be useful,
> but if you only want debugging and logging then do check out Log4J:
> http://svn.dsource.org/svn/projects/mango/trunk/doc/html/classLogger.html
> It comes in the mango.log module, ported from the original Java Log4J:
> http://logging.apache.org/log4j/docs/documentation.html

I took a look at that but it was too much for my needs. Since it uses
mango.io it probably in total is more code than my entire code base so far.
Here's my logging module:
module minwin.logging;
import std.stream;
//version=StdOutLog;
version (LOG) {
  Stream log;
  version (StdOutLog) {
    static this() {
      log = stdout;
    }
  } else {
    static this() {
      log = new BufferedFile("log.txt",FileMode.OutNew);
    }
  }
}
It works great but my log is getting a tad dense.

>
> Here is the workaround I use, http://www.digitalmars.com/d/archives/digitalmars/D/11946.html
>
> this in C:
>> #define VERSION 2
>>
>> #if (VERSION > 2)
>> // do stuff
>> #endif
>
> becomes in D:
>> version = VERSION_1;
>> version = VERSION_2;
>>
>> version (VERSION_2) {
>> // do stuff
>> }
>
> It gets boring around 10 or so...
>
>
> version (VERSION > 2) would be just as useful as the version (!VERSION) that has already been suggested and implemented as #ifndef alternative. http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2522
>
> Guess we'll just have to wait for Walter's opinion. --anders

Maybe I'll invest the time and make a small Stream subclass that checks a
level at runtime. Something like
class Log : Stream {
  ...
  int level;
  void lvlwritef(int level,...) {
    if (level <= this.level) {...}
  }
}

Another way to solve my problem is to compile with logging in only certain modules instead of setting a makefile flag that compiles all my with the same setting. That would reduce the clutter. I'll probably go with that one and just rework my makefiles a little.

-Ben

In article <ctnvuc$csk$1@digitaldaemon.com>, Ben Hinkle says...
>I took a look at that but it was too much for my needs. Since it uses mango.io it probably in total is more code than my entire code base so far.
> - Ben

You didn't know that Mango.log has a standalone version? One that uses Phobos? It's delivered in a seperate zipfile from the download page, Ben. Alternatively, you can simply compile it sans the "-version=Mango" compiler flag.

The benefit of using Mango.log becomes apparent through these aspects:

1) it interfaces with Chainsaw, such that one may remotely monitor a running application over TCP/IP

2) it exposes a dynamic HTML administration console for configuring the logging characteristics of a running application -- you don't have to halt/restart the app.

3) it's Wholly compliant with Log4J, which is broadly accepted in the Java community. There's a lot of value in that.

4) Mango.log makes a concerted effort to avoid GC overhead.

Of course, you are welcome to reinvent.


More troublesome is your vague implication that Mango.io is somehow huge/bloated/unecessary -- this is completely untrue, Ben. You've made your point on a number of occasions regarding your personal preference for a procedural approach rather than OO -- fine. Contrary to your implication, Mango.io is concise, reasonably decoupled, symmetrical, highly configurable and, frankly, exposes a welcome alternative to the Phobos IO package.

I have noticed recently that when anyone notes anything positive regarding Mango, you tend to post something steering people in a different direction. There's nothing wrong with ensuring that folks know what the alternatives are, but it does become a bit tiresome after a while. Don't you think there's enough room for multiple approaches, Ben? I've tried to support your efforts as much as one can, so perhaps you might consider doing the same for others. After all, it's for the benefit of the D community.

Regards, etc.

- Kris

"Kris" <Kris_member@pathlink.com> wrote in message news:ctolas$147b$1@digitaldaemon.com...
> In article <ctnvuc$csk$1@digitaldaemon.com>, Ben Hinkle says...
>>I took a look at that but it was too much for my needs. Since it uses mango.io it probably in total is more code than my entire code base so far.
>> - Ben
>
> You didn't know that Mango.log has a standalone version? One that uses
> Phobos?
> It's delivered in a seperate zipfile from the download page, Ben.
> Alternatively,
> you can simply compile it sans the "-version=Mango" compiler flag.

Ah. I didn't see the version=Mango parts. I downloaded the log zipfile and opened a few files.

> The benefit of using Mango.log becomes apparent through these aspects:
>
> 1) it interfaces with Chainsaw, such that one may remotely monitor a
> running
> application over TCP/IP
>
> 2) it exposes a dynamic HTML administration console for configuring the
> logging
> characteristics of a running application -- you don't have to halt/restart
> the
> app.
>
> 3) it's Wholly compliant with Log4J, which is broadly accepted in the Java community. There's a lot of value in that.
>
> 4) Mango.log makes a concerted effort to avoid GC overhead.
>
> Of course, you are welcome to reinvent.

I plan on switching to mango.log if I start reinventing.

> More troublesome is your vague implication that Mango.io is somehow
> huge/bloated/unecessary -- this is completely untrue, Ben. You've made
> your
> point on a number of occasions regarding your personal preference for a
> procedural approach rather than OO -- fine. Contrary to your implication,
> Mango.io is concise, reasonably decoupled, symmetrical, highly
> configurable and,
> frankly, exposes a welcome alternative to the Phobos IO package.

You know after I posted that I wondered if that sentance would tick off some people. But I really just meant that my problem is really really tiny and anything that involves more than one or maybe two modules it is waaaay too big a hammer for my problem. I don't see myself using 90% of mango.log. Maybe I shouldn't call it "logging" and instead just call it "debugging diagnostics" or something. I just need to spit stuff to a text file. One could argue that eventually I'll need many things from mango.log and when that happens I'll start using it. I'm just not there yet. Knowing that there is a std.stream version of mango.log help lower the barrier for using it for me so that will help alot.

> I have noticed recently that when anyone notes anything positive regarding
> Mango, you tend to post something steering people in a different
> direction.
> There's nothing wrong with ensuring that folks know what the alternatives
> are,
> but it does become a bit tiresome after a while. Don't you think there's
> enough
> room for multiple approaches, Ben? I've tried to support your efforts as
> much as
> one can, so perhaps you might consider doing the same for others. After
> all,
> it's for the benefit of the D community.

I've posted once or twice pointing people towards Mango - for the ICU stuff in particular I think is a great help. There were a few posts about Mango that ignored std.stream and so I would post about std.stream. I can't think of too many examples where I've "bashed" mango or "hyped" alternatives or whatever. I try to keep to just letting people know about features in phobos. If I have stepped out of those goals then I appologize.

Fair enough. Thanks for clarifying :-)

- Kris


In article <ctonlj$16mo$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:ctolas$147b$1@digitaldaemon.com...
>> In article <ctnvuc$csk$1@digitaldaemon.com>, Ben Hinkle says...
>>>I took a look at that but it was too much for my needs. Since it uses mango.io it probably in total is more code than my entire code base so far.
>>> - Ben
>>
>> You didn't know that Mango.log has a standalone version? One that uses
>> Phobos?
>> It's delivered in a seperate zipfile from the download page, Ben.
>> Alternatively,
>> you can simply compile it sans the "-version=Mango" compiler flag.
>
>Ah. I didn't see the version=Mango parts. I downloaded the log zipfile and opened a few files.
>
>> The benefit of using Mango.log becomes apparent through these aspects:
>>
>> 1) it interfaces with Chainsaw, such that one may remotely monitor a
>> running
>> application over TCP/IP
>>
>> 2) it exposes a dynamic HTML administration console for configuring the
>> logging
>> characteristics of a running application -- you don't have to halt/restart
>> the
>> app.
>>
>> 3) it's Wholly compliant with Log4J, which is broadly accepted in the Java community. There's a lot of value in that.
>>
>> 4) Mango.log makes a concerted effort to avoid GC overhead.
>>
>> Of course, you are welcome to reinvent.
>
>I plan on switching to mango.log if I start reinventing.
>
>> More troublesome is your vague implication that Mango.io is somehow
>> huge/bloated/unecessary -- this is completely untrue, Ben. You've made
>> your
>> point on a number of occasions regarding your personal preference for a
>> procedural approach rather than OO -- fine. Contrary to your implication,
>> Mango.io is concise, reasonably decoupled, symmetrical, highly
>> configurable and,
>> frankly, exposes a welcome alternative to the Phobos IO package.
>
>You know after I posted that I wondered if that sentance would tick off some people. But I really just meant that my problem is really really tiny and anything that involves more than one or maybe two modules it is waaaay too big a hammer for my problem. I don't see myself using 90% of mango.log. Maybe I shouldn't call it "logging" and instead just call it "debugging diagnostics" or something. I just need to spit stuff to a text file. One could argue that eventually I'll need many things from mango.log and when that happens I'll start using it. I'm just not there yet. Knowing that there is a std.stream version of mango.log help lower the barrier for using it for me so that will help alot.
>
>> I have noticed recently that when anyone notes anything positive regarding
>> Mango, you tend to post something steering people in a different
>> direction.
>> There's nothing wrong with ensuring that folks know what the alternatives
>> are,
>> but it does become a bit tiresome after a while. Don't you think there's
>> enough
>> room for multiple approaches, Ben? I've tried to support your efforts as
>> much as
>> one can, so perhaps you might consider doing the same for others. After
>> all,
>> it's for the benefit of the D community.
>
>I've posted once or twice pointing people towards Mango - for the ICU stuff in particular I think is a great help. There were a few posts about Mango that ignored std.stream and so I would post about std.stream. I can't think of too many examples where I've "bashed" mango or "hyped" alternatives or whatever. I try to keep to just letting people know about features in phobos. If I have stepped out of those goals then I appologize.
>
>