www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - version statements and levels

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
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
Jan 31 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 01 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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
Feb 01 2005
parent reply Kris <Kris_member pathlink.com> writes:
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
Feb 01 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Feb 01 2005
parent Kris <Kris_member pathlink.com> writes:
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.
Feb 01 2005