The hard-coded offset does not come from a variable. A lack of comments in the code makes it very difficult to understand and debug.

No wonder...  Maybe you could use Studio or Atelier debugger to verify their values. Unless you need that log file of course.

Maybe you could also use break instead, just before the routine ends. And zwrite the context variables manually within the terminal.
I still don't know exactly what you want to achieve neither what are your limitations, I only know that you want to see the content from LINE, so I might be speaking something unnecessary.

No, there isn't.
What he meant is that Caché supports binding for other languages. But there isn't a native COS implementation for PGP.
The easiest way of achieving what you want is to use gpg using $zf (CallOut). Where you can emit a comand directly to the host OS.
Remember that by default Windows haven't a gpg command. But there's a version for it as well.

You can also use method ##class(%Net.Remote.Utility).RunCommandViaZF(cmd,,.output,,) for brevity. Where cmd should be your gpg command.

Not sure if I understood what you meant, but I'll try to answer:
When using class methods you cannot reference your THIS instance. Have you every used Java, C# or whatever programming language that supports object oriented-programming paradigms? If so then class methods are the same as static methods.
Common (non-static) methods have the advantage of providing you the instance context. Which means that all properties are accessible inside this kind of method, even the private ones.

Class Sample.Person Extends %Persistent
{

Property Name As %String;

ClassMethod GetPersonName(instance As Sample.Person)
{
   return instance.Name // This works fine, GetPersonName is receiving an external Sample.Person.
}

// 'My' is used to empathize that this method refers to it's own instance name.
Method GetMyName() As %String 
{
   return ..Name // This also works fine.  Notice that this method doesn't receives the instance, it's because you can only call it from a instance already.
}

ClassMethod GetMyInstanceName() As %String
{
  return ...Name // This won't work. Since there's no context (instance). The compiler will even warn about it.
}
}

%Next does receives a %Status as output. It's not exactly what you suggested, but close enough.
while result.%Next(.sc) {

$$$ThrowOnError(sc)

}

Since booleans can be only true or false, you usually don't need to know about anything else, so let the caller handle what it should do.
 

ClassMethod AssertClassExists(ClassName As %String) As %Status
{
   if '..ClassExists(ClassName) return $$$ERRROR($$$ClassDoesNotExist, ClassName)
   return $$$OK
}

ClassMethod ClassExists(ClassName as %String) as %Boolean {

return ##class(%Dictionary.CompiledClass).%ExistsId(ClassName)

}

a homemade tool

Wow, that's unexpected. Care to share some details about that tool?

I see, we have been using an in-house tool with features similar to yours as well, at that time files were still being exported as XML instead of UDL. But now we're moving our development to local and enforcing project usage using this tool.

We also had our share of pain with editing live production code and I have to say, it's not the greatest feeling.

Yes, like... %DynamicObject and %DynamicArray.
I still don't quite get why to use %objlasterror instead of returning the error.
Method %ToJSON(outstrm As %Stream.Object) As %String
{
if $D(outstrm) {
if $isobject(outstrm) {
if '(outstrm.%IsA("%Stream.Object")) {
throw ##class(%Exception.General).%New("%ToJSON - argument passed is not an instance of %Stream.Object")
}
try {
set ans = $zu(210,27,outstrm)
} catch {
do  $$$APPERROR1($$$LASTERROR)  <- This appends the error to %objlasterror and that's it.
}

Sadly I haven't the code with me anymore. because it was a a feature implemented on another branch, that's why I posted a Gist instead. I used it to preserve the important implementation parts since I deleted the branch. Check my post again to understand better regarding the placeholders.
Port.SourceControl.Extension.VCS is quite simple actually, %OnNew initialize two temp files path that serve as output and error feedback, inheriting classes use those files as parameters along with >.

Wouldn't it require all methods to implement the device logic? I guess that's why he asked for device redirection.

It doesn't, at least not directly. I used it for boosting the comparison speed by using git diff.

The idea as a whole was:
diff - whenever the user selected the "Import" from the Source Control menu, it would run git diff instead, if git was installed and the current project is versioned (has .git).
add - automatically add modified and new files to the staging area whenever the item is saved on Studio.
I ended up dropping those ideas because I noticed I was wasting resources as it need to be less exploitable and it also went against my objective of creating something agnostic to version control systems.
If you want to see the result, here's the project in question.

Interesting, can you expand this subject a bit or point the documentation? I'm also interested about how to capture user input using the Studio's output.

No, it's a proof-of-concept, my purpose was to discover a way to express the minimal features needed to develop in a functional fashion.
You can use it with real projects and it will work as it should, the only real issue might be regarding the performance in a long term, since this library uses %ConstructClone to keep the monoids pure.

I would like to. But I need some clue about how to isolate monoids from the global scope, this would push the development a lot further. I mean... it would be wonderful if subroutines could be passed as parameters, you know. But this is out of my reach yet.
For now what I could do is to add more methods to handle different type of datas.

Hello Maks, surely you can. We just need to rename it to something easier to remeber,  then set up README, CODE_OF_CONDUCT and LICENSE files.
This project was actually a response for another thread that you opened a while ago. So what motivated me on doing it was the community feedback (you as well) regarding your other thread.
https://community.intersystems.com/post/declarative-development-cach%C3…

JavaScript is evolving day by day and really, really fast. Check what ECMAScript 6 and even 7 to see what it's becoming.
COS could evolve faster as well if there was some kind of COS API for parsing and rewriting the language itself. Something that could transpile features unknown to the current COS language. Just like BabelJS does.
However COS is proprietary, and just like Linux and Windows, open-source projects  evolve faster due to the community involvement. I don't mean to make it fully open, but provide the community a way to interact with it by providing with new features proposals.