New post
AllAccepted answers
Ben Spead · Jan 18, 2019

I can only comment on the original functionality in %Studio.SourceControl.ISC - if you're extending it you will need to do some debugging to see exactly why you are seeing the behavior that you are.

In the original %Studio.SourceControl.ISC class, when working in Connected mode (ie, Caché can issue p4 commands in real time to the Perforce server), the p4 command should take care of changing the file back to ReadOnly, which is what triggers GetStatus() to see it is uneditable and therefore not checked out.  It may be that your GetStatus() isn't correctly interpretting  the Reaonly state of the file, or if you are on UNIX, it may be that Caché doesn't see it properly as Readonly (this can happen if you are running your instance as Root).    Note - I think there may be a bug where after checking the %Studio.SourceControl.Change table isn't updated appropriately, but the primary indicator of checked  out/ checked in should be that Readonly bit on the file.

Hopefully this is enough to get you moving on this, and if not then I suggest you call Support to have them take a look with you and debug.  If there are any other questions I can answer in this forum I am happy to try.

Best of luck!

Ben Spead · Jan 17, 2019

Adrian - are you writing your own Perforce hooks or use the sample Perforce hooks that ship with Caché? (%Studio.SourceControl.ISC.cls).

In %Studio.SourceControl.ISC.cls it checks to see if the file in the local workspace is Readonly or ReadWrite.  If Readonly it assumes it is not checked out and prompts the user to check out.  If ReadWrite it will see if it is a multi-developer or single-developer instance.  if single developer it can just edit it.  If multi-developer it will check in %Studio.SourceControl.Change to see if the current user is the one who checked it out - if so they can edit, if not they can a message of who is editing it in the Output window and the item is treated as ReadOnly to them.

Ben Spead · Jan 11, 2019

Alex - I think it isn't a smart idea to call into a specific line number of a routine since the contents will change.  Instead you should call the line labels/functions called within the routine by outside of the routine and pass all appropriate variables, etc that way.

Trying to call a specific line number will certainly lead to faster than desired 'bit rot' in your unit test library.

Ben Spead · Jan 3, 2019

Welcome to the the InterSystems Developer Community!!

1) ObjectScript is a (very, very large) superset of the M language (previously known as MUMPS)

2) InterSystems IRIS uses much of the core technology that was in Caché, but it is a break from the past in many ways and allows next-gen development tools, architectures, etc.  InterSystems IRIS is an upgrade path which current Caché based applications should seriously consider.  Zen is a legacy web development technology which runs on top of Caché (it ships with Caché and InterSystems IRIS)

3) The answer to this depends on whether you are taking straight globals, or persistent objects.  Any data persisted via InterSystems Object or Relational structures can automatically be accessed via SQL.  If you are just writing straight globals (e.g. set ^Patient(123)=foobar) then you can't query unless you set up an SQLStorage mapping to your globals

4) You can map your existing global structures to object definitions for OO/SQL access using SQLStorage (https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...).  It looks like there isn't a lot in the docs on that so you should contact Support for more details on how to set it up to match your existing data to definitions which you can hit with traditional SQL.

Hope that helps!

Ben Spead · Jan 2, 2019

Excellent article Michelle!  Very well done :)

I absolutely concur that if a shared dev instance is going to be used along with client-side hooks then locking is a *must*!  However, some may find that exclusive ownership on a single Shared dev instance is too restrictive, but find themselves still needing a Shared dev instance in the mix for certain reasons.   

An alternative would be a Mixed mode of working with a Shared Dev and one or more Private Dev environment.  We have found that this mode works really well for us in the case for large teams on active projects - locking across the board we've found to be too restrictive in how it blocks work.  We have found this on a couple of our most active applications where we need shared development instance for a number of reasons.  In order to make this work, you will need to move to using  Server-Side Source Control hooks on the Shared dev instance, and then developers that don't require work on the shared dev instance can have a private instance which uses either Server-Side or Client-Side source control hooks (in our case we use server-side in Private dev instances to make it easier to support).   This will work because the Server-Side Hooks on Shared should manage concurrency of any developers connected to that instance (they can't check out a file someone is already working on), while not locking the file in source control which would prevent other developers from touching it on their Private Dev instances.  

Just throwing this out there as another option for those who find that they are tripping over exclusive locking, and are not comfortable running with unlocked files on the Shared Dev instance.

Also, a big thumbs up for including the suggestions of Jenkins - we have started using it this year to automate build/unit/code coverage testing on every check-in and are seeing some great results!

Ben Spead · Nov 21, 2018

Make sure that you review all of the shortcuts outlined in the documentation (there are a LOT of useful ones there):

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Also, check out one of my favorite things to do with Studio which isn't as widely known as it should be:

https://community.intersystems.com/post/studio-tip-running-cos-commands-...

Hope that helps :)

Ben

Ben Spead · Nov 10, 2018

You can use $version(1) to see if it is Windows (returns '2') or UNIX (returns '3').  If you want to get really fancy you can include %occOptions.inc and then use the $$$isUNIX and $$$isWINDOWS calls (which just check to see if $version(1) is 2 or 3).

Personally, I like using ##class(%Studio.SourceControl.ISC).RunCmd() as it wraps the capture of the output for parsing.

You can tie $version together the other answers into something that is platform independent (warning, I haven't tested this, but I believe the pieces work):

If ($version(1)=2) {

   //Is Windows

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("Ver",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

} elseif ($version(1)=3) {

   //Is UNIX

   set sc=##class(%Studio.SourceControl.ISC).RunCmd("uname -a",.out,0)

   set OS = out(1)

   // exercise of parsing exact desired version piece from the string is an exercise left to the reader

}
Hope that helps you Paul!
Ben Spead · Nov 2, 2018

Mack-  the %occLibrary calls are not documented for use by applications.

As  your very interesting questions has proven the  ease with which this is solved by:

$$CSVtoList^%occLibrary(csv)

I suggest you contact the WRC to request an enhancement to have this wrapped in a supported (and documented!) API that may be more future-proof than this internal and undocumented call.

Ben Spead · Oct 17, 2018

Daniel,

You are absolutely correct that using Client-Side source control hooks (ie the Eclipse Git hooks with Atelier) in a Shared development instance is a recipe for disaster and frustration.  You options are moving to Private development environments (each developer gets their own Namespace, or instance, or VM or container), or move to Server-side source control hooks.

I did an in depth session on this at Global Summit 2017 which should be of interest to you.  You can watch the recording and get the slides here:

https://learning.intersystems.com/course/view.php?id=713

HTH,

Ben

Ben Spead · Sep 18, 2018

Akio,

First - welcome to the InterSystems Developer Community and to exploring InterSystems database technologies!

I see that you changed your original post and content and changed it to ask about the cube (original post was "question I want to use the database in the evaluation version").  I think it might be easier for you if I try to answer your first question ;)

My suggestion is that if you are new with InterSystems technologies that you start with InterSystems IRIS rather than Caché.  There are some great cloud-based trials for exploring and learning about InterSystems IRIS and you don't have to install anything locally in order to play with it.  

Please check out: https://www.intersystems.com/learn-play/

If you would prefer to play with Caché locally, then I am sure someone can answer your question about the cube (I am not on a Mac so I can't advise on that point).

All the best!

Ben

Ben Spead · Aug 15, 2018

Eduard - I think Arcady was asking from a purely data-processing perspective.  I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing?  I think it's a good question and I would also like to hear what people think :)