How to keep your own debug lines without checking them in?

When working on some code, I add extra debug logging of some kind to make it easier for me to trace the state and values that I care about for this particular fix.

But if I would check this in into the source code repository, my colleagues would get angry on me for polluting the Log output and polluting the code.

So how do I locally keep these lines of code that are important to me, without checking them in?

Clarification: Many answers related to the log output, and that you with log levels can filter that out. And I agree with that.

But. I also mentioned the problem of polluting the actual code. If someone puts a log statement between every other line of code, to print the value of all variables all the time. It really makes the code hard to read. So I would really like to avoid that as well. Basically by not checking in the logging code at all. So the question is: how to keep your own special purpose log lines. So you can use them for your debug builds, without cluttering up the checked in code.

From stackoverflow Andreas

• What source control system are you using? Git allows you to keep local branches. If worse comes to worst, you could just create your own 'Andreas' branch in the repository, though branch management could become pretty painful.

  From swilliams

• But if I would check this in into the source code repository, my colleagues would get angry on me for polluting the Log output and polluting the code.

  I'm hoping that your Log framework has a concept of log levels, so that your debugging could easily be turned off. Personally I can't see why people would get angry at more debug logging - because they can just turn it off!

  From matt b

• Why not wrap them in preprocessor directives (assuming the construct exists in the language of your choice)?

  #if DEBUG
      logger.debug("stuff I care about");
  #endif
  

  Also, you can use a log level like trace, or debug, which should not be turned on in production.

  if(logger.isTraceEnabled()) {
      logger.log("My expensive logging operation");
  }
  

  This way, if something in that area does crop up one day, you can turn logging at that level back on and actually get some (hopefully) helpful feedback.

  ---

  Note that both of these solutions would still allow the logging statements to be checked in, but I don't see a good reason not to have them checked in. I am providing solutions to keep them out of production logs.
  DOK : I believe that keeps the code out of the compiled code, but it will still be in the code that is checked into the source control repository.

  Chris Marasti-Georg : It would be in the code that is checked into the repository, but it would keep the log directives completely out of production releases.
  From Chris Marasti-Georg

• Similar to

  #if DEBUG #endif....
  

  But that will still mean that anyone running with the 'Debug' configuration will hit those lines.

  If you really want them skipped then use a log level that no one else uses, or....

  Create a different run configuration called MYDEBUGCONFIG and then put your debug code in between blocks like this:

  #if MYDEBUGCONFIG 
  ...your debugging code
  #endif;
  

  From

• If this was really an ongoing problem, I think I'd assume that the central repository is the master version, and I'd end up using patch files to contain the differences between the official version (the last one that I worked on) and my version with the debugging code. Then, when I needed to reinstate my debug, I'd check out the official version, apply my patch (with the patch command), fix the problem, and before check in, remove the patch with patch -R (for a reversed patch).

  However, there should be no need for this. You should be able to agree on a methodology that preserves the information in the official code line, with mechanisms to control the amount of debugging that is produced. And it should be possible regardless of whether your language has conditional compilation in the sense that C or C++ does, with the C pre-processor.

  From Jonathan Leffler

• IMHO, you should avoid the #if solution. That is the C/C++ way of doing conditional debugging routines. Instead attribute all of logging/debugging functions with the ConditionalAttribute. The constructor of the attribute takes in a string. This method will only be called if the particular pre-processor definition of the same name as the attribute string is defined. This has the exact same runtime implications as the #if/#endif solution but it looks a heck of a lot better in code.

  From JaredPar

• If you really are doing something like:

  puts a log statement between every other line of code, to print the value of all variables all the time. It really makes the code hard to read.

  that's the problem. Consider using a test framework, instead, and write the debug code there.

  On the other hand, if you are writing just a few debug lines, then you can manage to avoid those by hands (e.g. removing the relevant lines with the editor before the commit and undoing the change after it's done) - but of course it have to be very infrequent!

  From Davide

• I know i'm going to get negative votes for this...
  But if I were you, i'd just build my own tool.

  It'll take you a weekend, yes, but you'll keep your coding style, and your repository clean, and everyone will be happy.

  Not sure what source control you use. With mine, you can easily get a list of the things that are "pending to be checked in". And you can trigger a commit, all through an API.

  If I had that same need, i'd make a program to commit, instead of using the built-in command in the Source Control GUI. Your program would go through the list of pending things, take all the files you added/changed, make a copy of them, remove all log lines, commit, and then replace them back with your version.

  Depending on what your log lines look like, you may have to add a special comment at the end of them for your program to recognize them.

  Again, shouldn't take too much work, and it's not much of a pain to use later.
  I don't expect you'll find something that does this for you already done (and for your source control), it's pretty specific, I think.

  Troy Howard : If it's SVN this would pretty darn easy to do... Make a little perl script that removed any items wrapped with comments like // remove-before-checkin-begin to // remove-before-checkin-end (probably want to choose something shorter, and make a snippett for it in VS).
  From Daniel Magliola

• If the only objetive of the debugging code you are having problems with is to trace the values of some varibles I think that what you really need is a debugger. With a debugger you can watch the state of any variable in any moment.

  If you cannot use a debugger, then you can add some code to print the values in some debug output. But this code should be only a few lines whose objective has to be to make easier the fix you are doing. Once it's commited to trunk it's fixed and then you shouldn't need more those debug lines, so you must delete them. Not delete all the debug code, good debug code is very useful, delete only your "personal" tracing debug code.

  If the fix is so long that you want to save your progress commiting to the repository, then what you need is a branch, in this branch you can add so much debugging code as you want, but anyway you should remove it when merging in trunk.

  From Jaime Soriano

• This next suggestion is madness do not do it but you could...

  Surround your personal logging code with comments such as

  // ##LOG-START##
  logger.print("OOh A log statment");
  // ##END-LOG##
  

  And before you commit your code run a shell script that strips out your logs.

  I really wouldn't reccomend this as it's a rubbish idea, but that never stops anyone.

  Alternative you could also not add a comment at the end of every log line and have a script remove them...

  logger.print("My Innane log message"); //##LOG
  

  Personally I think that using a proper logging framework with a debug logging level etc should be good enough. And remove any superfluous logs before you submit your code.

  From Omar Kooheji

Setting Folder permissions on Vista.

I am trying to set the permissions of a folder and all of it's children on a vista computer. The code I have so far is this.

 public static void SetPermissions(string dir)
        {
            DirectoryInfo info = new DirectoryInfo(dir);
            DirectorySecurity ds = info.GetAccessControl();            
            ds.AddAccessRule(new FileSystemAccessRule(@"BUILTIN\Users", 
                             FileSystemRights.FullControl, 
                             InheritanceFlags.ContainerInherit,
                             PropagationFlags.None, 
                             AccessControlType.Allow));

            info.SetAccessControl(ds);            
        }

However it's not working as I would expect it to.
Even if I run the code as administrator it will not set the permissions.

The folder I am working with is located in C:\ProgramData\<my folder> and I can manually change the rights on it just fine.

Any one want to point me in the right direction.

From stackoverflow Erin

• This may be a dumb question, but have you tried performing the same action manually (e.g. using Explorer)? Vista has some directories that not even users in the Administrators group can modify without taking additional steps. I think there are two steps you need to take first.

  First, use Explorer to make the same modification you're trying to do in your code. If it fails, troubleshoot that.

  Second, test your code on a directory you created under your own user folder. You shouldn't need admin privs to do that; the logged-in account should be able to change ACL on folders under e.g. c:\Users\yourname\documents.

  I'd also step through the code in the debugger and look at the "ds" object just before your call to SetAccessControl. That might show you something unexpected to set you on the right path.

  Erin : Yes I can create change the folder access rights manually.
  From Coderer

• So the answer is two fold. First off a sub folder was being created before the permissions were set on the folder and I needed to or in one more flag on the permissions to make it so both folders and files inherited the permissions.

  public static void SetPermissions(string dir)
          {
              DirectoryInfo info = new DirectoryInfo(dir);
              DirectorySecurity ds = info.GetAccessControl();            
              ds.AddAccessRule(new FileSystemAccessRule(@"BUILTIN\Users", 
                               FileSystemRights.FullControl,
                               InheritanceFlags.ObjectInherit |
                               InheritanceFlags.ContainerInherit,
                               PropagationFlags.None,
                               AccessControlType.Allow));
              info.SetAccessControl(ds);            
          }
  

  After that every thing appears to be working.

  From Erin

How do you format the body of a JMS text message?

Does everyone just use XML in the message? Are there any good alternatives to XML? If you do use XML, do you define an XML Schema so clients know how to send messages to your service?

From stackoverflow Josh Brown

• We use XML, but I think the important thing is to tailor the solution to the problem. The reason we use XML is that we are basically sending an object across in the message. There's no reason it can't be plain text, if applicable for the message you are sending, using headers to send along properties if appropriate.

  ---

  We haven't defined an XSD or DTD for our XML messages, but we do have a formal document describing their composition so that other teams can use our feeds without bugging us.
  From Chris Marasti-Georg

• XML, CSV, HTML, a simple word or sentence, ... Any of these are valid depending on the context in which the message is used and created. Just keep it simple and send what is needed in that context.

  It is very flexible and can be adapted to the problem space.

  From Robin

• XML is probably the most popular along with JSON a close second - but as others have said in this thread - XML, CSV, JSON or even HTML are fine.

  XSDs are overrated really - their only real value is if you want your clients/customers to code generate marshalling code (e.g. using JAXB) or if you want to let folks use XSDs in their editors / IDE to get smart completion

  Josh Brown : I like XSDs for use in IDEs - for both smart completion and validation.
  From James Strachan

How to split a huge zip file into multiple volumes?

When I create a zip Archive via java.util.zip.*, is there a way to split the resulting archive in multiple volumes? Let's say my overall archive has a filesize of 24 MB and I want to split it into 3 files on a limit of 10 MB per file. Is there a zip API which has this feature? Or any other nice ways to achieve this?

Thanks Thollsten

From stackoverflow Thollsten

• Check: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=38&t=004618

  I am not aware of any public API that will help you do that. (Although if you do not want to do it programatically, there are utilities like WinSplitter that will do it)

  I have not tried it but, every ZipEntry while using ZippedInput/OutputStream has a compressed size. You may get a rough estimate of the size of the zipped file while creating it. If you need 2MB of zipped files, then you can stop writing to a file after the cumulative size of entries become 1.9MB, taking .1MB for Manifest file and other zip file specific elements. So, in a nutshell, you can write a wrapper over the ZippedInputStream as follows:

  import java.util.zip.ZipOutputStream;
  import java.util.zip.ZipEntry;
  import java.io.FileOutputStream;
  import java.io.File;
  import java.io.FileNotFoundException;
  import java.io.IOException;
  
  public class ChunkedZippedOutputStream {
  
      private ZipOutputStream zipOutputStream;
  
      private String path;
      private String name;
  
      private long currentSize;
      private int currentChunkIndex;
      private final long MAX_FILE_SIZE = 16000000; // Whatever size you want
      private final String PART_POSTFIX = ".part.";
      private final String FILE_EXTENSION = ".zip";
  
      public ChunkedZippedOutputStream(String path, String name) throws FileNotFoundException {
          this.path = path;
          this.name = name;
          constructNewStream();
      }
  
      public void addEntry(ZipEntry entry) throws IOException {
          long entrySize = entry.getCompressedSize();
          if((currentSize + entrySize) > MAX_FILE_SIZE) {
              closeStream();
              constructNewStream();
          } else {
              currentSize += entrySize;
              zipOutputStream.putNextEntry(entry);
          }
      }
  
      private void closeStream() throws IOException {
          zipOutputStream.close();
      }
  
      private void constructNewStream() throws FileNotFoundException {
          zipOutputStream = new ZipOutputStream(new FileOutputStream(new File(path, constructCurrentPartName())));
          currentChunkIndex++;
          currentSize = 0;
      }
  
      private String constructCurrentPartName() {
          // This will give names is the form of <file_name>.part.0.zip, <file_name>.part.1.zip, etc.
          StringBuilder partNameBuilder = new StringBuilder(name);
          partNameBuilder.append(PART_POSTFIX);
          partNameBuilder.append(currentChunkIndex);
          partNameBuilder.append(FILE_EXTENSION);
          return partNameBuilder.toString();
      }
  }
  

  The above program is just a hint of the approach and not a final solution by any means.

  From sakana

• Not exactly what you want, but if you can not do this in zip volumes, you may consider simply divide the file (in java) as described here.

  From VonC

• If the goal is to have the output be compatible with pkzip and winzip, I'm not aware of any open source libraries that do this. We had a similar requirement for one of our apps, and I wound up writing our own implementation (compatible with the zip standard). If I recall, the hardest thing for us was that we had to generate the individual files on the fly (the way that most zip utilities work is they create the big zip file, then go back and split it later - that's a lot easier to implement. Took about a day to write and 2 days to debug.

  The zip standard explains what the file format has to look like. If you aren't afraid of rolling up your sleeves a bit, this is definitely doable. You do have to implement a zip file generator yourself, but you can use Java's Deflator class to generate the segment streams for the compressed data. You'll have to generate the file and section headers yourself, but they are just bytes - nothing too hard once you dive in.

  Here's the zip specification - section K has the info you are looking for specifically, but you'll need to read A, B, C and F as well. If you are dealing with really big files (We were), you'll have to get into the Zip64 stuff as well - but for 24 MB, you are fine.

  If you want to dive in and try it - if you run into questions, post back and I'll see if I can provide some pointers.

  vy32 : I'm having problems with multi-volume zip files. Specifically when a single file component is split between more than disk file. In file.zx01 I have the file header and the first part of the compressed data, then in file.zx02 I have the rest of the compressed data. But I'm not able to reassemble the files for some reason, and I'm not sure why. Do you have any experience here?
  From Kevin Day

ExternalInterface Performance: Looking for Some Best-Practices/Tips

Hi there:

I'm using Flex 3 in the UI of a Windows app (Flash player as an embedded ActiveX control), and passing data between them with ExternalInterface (primarily into the Flex app, as opposed to out). I'm finding, though, that the performance is pretty awful, particularly with larger (i.e., custom) objects; the more EI calls we make, and the larger the custom objects as pass in, the harder things seem to drop off performance-wise.

I'm assuming there's a good deal of overhead in serializing these objects, so I'm wondering, are there any best practices out there for using ExternalInterface in this particular way? There doesn't seem to be much out there in terms of documentation on this subject yet.

Is it better, say, to pass a large block of XML into the player control as a string, and parse it with Flex, than to pass it as a custom object, as a rule? How should Flex apps requiring a relatively tight integration with their host apps best use ExternalInterface without sacrificing performance? Is EI performance an issue Adobe is addressing? Any implementation differences between players 9 and 10? What kinds of things should we avoid to get the most out of this feature?

Thanks in advance!

Chris

From stackoverflow Christian Nunciato

• Just to share the answer with anyone who might be interested, the unofficial answer from Adobe (confirmed by a few Adobe engineers at last month's MAX conference) is that marshaling, say, over 30KB or so of data over ExternalInterface is going to cause performance degradation. Little bits of data, no problem -- but larger chunks, regardless of type, etc., will slow things down considerably.

  Apparently it's a known issue, and Flash 10 doesn't seem to offer much in the way of improvements, unfortunately. So in the meantime, a workable solution is to use ExternalInterface for the little things, but to leave the heavier lifting to URLLoader and the XML or JSON parsers. Hope that helps -- if anyone runs into this one and needs more detailed guidance, feel free to contact me directly.

  From Christian Nunciato

• Brad Neuberg seems to have put a lot of effort to figure this one out. He has published a workaround at

  http://codinginparadise.org/weblog/2006/02/how-to-speed-up-flash-8s.html

  From $pageUsers[$post.author].name

How can I add multiple should_receive expectations on an object using RSpec?

In my Rails controller, I'm creating multiple instances of the same model class. I want to add some RSpec expectations so I can test that it is creating the correct number with the correct parameters. So, here's what I have in my spec:

Bandmate.should_receive(:create).with(:band_id => @band.id, :user_id => @user.id, :position_id => 1, :is_leader => true)
Bandmate.should_receive(:create).with(:band_id => @band.id, :user_id => "2222", :position_id => 2)
Bandmate.should_receive(:create).with(:band_id => @band.id, :user_id => "3333", :position_id => 3)
Bandmate.should_receive(:create).with(:band_id => @band.id, :user_id => "4444", :position_id => 4)

This is causing problems because it seems that the Bandmate class can only have 1 "should_receive" expectation set on it. So, when I run the example, I get the following error:

Spec::Mocks::MockExpectationError in 'BandsController should create all the bandmates when created'
Mock 'Class' expected :create with ({:band_id=>1014, :user_id=>999, :position_id=>1, :is_leader=>true}) but received it with ({:band_id=>1014, :user_id=>"2222", :position_id=>"2"})

Those are the correct parameters for the second call to create, but RSpec is testing against the wrong parameters.

Does anyone know how I can set up my should_receive expectations to allow multiple different calls?

From stackoverflow Micah

• Multiple expectations are not a problem at all. What you're running into are ordering problems, given your specific args on unordered expectations. Check this page for details on ordering expectations.

  The short story is that you should add .ordered to the end of each of your expectations.

  Micah : Huh, it's working now even without .ordered I guess I had a mistake in my code and blamed it on RSpec. Thanks for the tip!
  From James Baker

VB.NET Importing Classes

Edit: This was accidentally posted twice. Original: http://stackoverflow.com/questions/243900/vb-net-importing-classes

I've seen some code where a Class is imported, instead of a namespace, making all the static members/methods of that class available. Is this a feature of VB? Or do other languages do this as well?

TestClass.vb

public class TestClass
    public shared function Somefunc() as Boolean
     return true
    end function
end class

MainClass.vb

imports TestClass

public class MainClass
    public sub Main()
     Somefunc()
    end sub
end class

These files are in the App_Code directory. Just curious, because I've never thought of doing this before, nor have I read about it anywhere.

From stackoverflow Kevin

• By using the "HideModuleNameAttribute" you can call methods without identifying thier parent.

  Example:

  Public Class TestClassCaller
      Public Sub New()
          SomeMethod()
      End Sub
  
  End Class
  
  <HideModuleName()> _
      Public Module TestClass
      Public Sub SomeMethod()
  
      End Sub
  End Module
  

  From Tom Anderson

• Imports only creates a reference to the class, it does not create an instance of it to use.

  The reason you see the function in your new class is that it's a shared function, which doesn't need the parent to have a created instance to use.

  Cheers!

  From thismat