#Debugging

Hi everyone,

I've encountered this annoying issue so many times before, if any one also encounter this issue, please share here if you have any solution.

So, I've been working on a web service project using HealthShare 2015. Sometimes I have to set a debug target to a csp file to debug it. If I pause the debug process about 3 minutes above or so (to examine an object, variable, etc..) the studio will hang.

If I open a terminal and type the following commands, sc is an error:

set validator = "sc = ##class(%Library.Numeric).IsValid(""BLAH"")"
set @validator
write sc

At the end, when I write sc I get:

0 L'BLAH9
             DOCXT010,#e^zIsValid+1^%Library.Numeric.1^1e^^^1

However, if I call the following class method using the arguments "%Library.Numeric" and "BLAH", sc is undefined

I am running a ZBREAK trace on a legacy FDBMS application that uses arrays but rather than displaying the array value contents, I am seeing logs similar to the following.

Trace: ZBREAK SET LINE=Array Val at BIOPWR+6^BIOPWR

My ZBREAK trace settings are as follows:

Hi, folks!

I need to get the source code of a class installed on a remote server. I have no Studio or Atelier access to it but I can manage REST and Web terminal access.

What is the easiest way for me to make it?

Hi all,

For custormer support reasons we would like to know if its possible to activate some kind of flag or see/redirect wich is the code (lines) being executed when some misterious problems appear.

Is there any way to view the stack of execution code on a deployed code environment? Is there any other equivalent way to track the execution stack for a certain period of time?

Best regards

Issue

I've been looking at the idea of developing a Time Travel Debugger utility.

It would take a debug target and have a few options such as stack depth and disclude system code.

The debugger would either be started from an external tool, or triggered from a line of code inserted into a method that I want to record.

The debugger would execute the code from start to end and record the full stack on each step to the configured depth.

InterSystems technologies are renowned for their high performing databases, which support the systems and operations of many organisations. However a key ingredient to this success is the quality and maintainability of their code.

The quality of code can impact everything from speed and ease of fixing bugs and making enhancements, to the overall performance of your organization and your ability to get ahead in the marketplace.

By ensuring your code is maintainable, you can reduce approximately 75% of the systems life cycle costs*. This is why, at George James Software, the solutions we build are always straightforward and written in high quality code - because we know that this solid foundation can positively impact the rest of your organization.

With a maintainable system you're able to reduce your overall maintenance as any issues that occur are significantly faster to identify and fix. This means you're free to allocate that time and budget to enhancements, enabling you to get the most value out of your applications and ultimately better support your organization.

Keep an eye out for our next few posts about what a maintainable system looks like and the tools that can help you keep your code maintainable, in order to help you to reduce those maintenance costs.

Every developer has made the mistake of accidentally leaving temporary debug code in place when they meant to remove it after debugging is complete. The great thing about writing in ObjectScript is that there is a way to make temporary code be truly temporary and automatically self-destruct! This can also be done in such a way that the code has no change of making it into your source control stream, which can be helpful as well.

We have a large number of processes and operations being applied to outbound HL7 messages from our PAS.

If I select a message, and open its visual trace, I see the service, as well as all processes, and operations.

My debugging is often about a new operation, and I don't need to see all the other operations that are in functioning as desired.

While I love using VSCode for IRIS development work, one of the persistent frustrations with it has been the inability to display an object hierarch in the variables window while debugging. Only the object's reference identifier is displayed. Cache Studio's handling of the same issue is a little clunky, but it does at least have the option to display something as an object.

For now, I make do with a combination of the watch window and the command line in the debugging console -- but this feels just a step away from log.debug()/console.log() level debugging sometimes.

You might have encountered this and not known how to prevent it, or perhaps not even noticed it...

Introduction

In the next few weeks, my coworkers are planning to start using VSCode to code with InterSystems' products. Among the many advantages of that, I would emphasize being able to connect with other technologies, such as GitHub, with ease. Besides, VSCode also offers an extensive extensions store, where you can find many free add-ons that make coding faster and more efficient. Last but not least, to conquer the heart of every developer, it is open source.

So, I was doing a debug test on a routine, and tried to open a file (yes, it does exist) as so:

s file=##class(%File).%Open($$$airfile,"R")