go to post Anna Golitsyna · Oct 8, 2021 Marc, a slight variation on your idea, tested whether targetRtn exists or not. Thanks again! zn "A"s currRtn=(##class(%Routine).%OpenId(rtnName))s stream=currRtn.Read()zn "B"s targetRtn=(##class(%Routine).%OpenId(rtnName))s sc=targetRtn.Write(stream)d targetRtn.Save()
go to post Anna Golitsyna · Oct 8, 2021 That would make the routine from namespace A immediately available in namespace B as is. The goal is to have routines in two namespaces different until the time comes for the programmer to make them the same via an RCOPY analog. It is also a "per routine" job used for synchronizing.
go to post Anna Golitsyna · Sep 21, 2021 One more question if I may: I try to exclude global subnodes but so far unsuccessfully. Is it possible?This correctly exports the corresponding node only: s items("SOMEGLOBAL(""ABC"",""XYZ"",""USERFORM_ATEST"").GBL") = ""Now if I try to exclude this node from the SOMEGLOBAL like this, s items("SOMEGLOBAL.GBL",'"SOMEGLOBAL(""ABC"",""XYZ"",""USERFORM_ATEST"").GBL") = "", it does not exclude it. There is a barely visible single negating quote in the beginning of the second item.
go to post Anna Golitsyna · Aug 6, 2021 OK, found what the problem was so your answer is, of course, correct.
go to post Anna Golitsyna · Aug 6, 2021 Robert, thanks a lot! This is what I saw today too in these nodes but not something I saw a few days ago. So I am still perplexed to some extent. I'll try various scenarios later, probably next week and will get back here if anything would be different.
go to post Anna Golitsyna · Jul 26, 2021 Can one export a specific node as XML via $system.OBJ.Export or otherwise?
go to post Anna Golitsyna · Jul 21, 2021 You are right about GSIZE. The other, slower functionality I had in mind is below: set statement=##class(%SQL.Statement).%New()set status=statement.%PrepareClassQuery("%SYS.GlobalQuery","Size")
go to post Anna Golitsyna · Jul 19, 2021 C as in this: C - InterSystems Programming Tools Index - Caché & Ensemble 2018.1.5 ? I understood about the main idea of a rarely used language, yes. I was just additionally interested in the accessing DB speed since ObjectScript seems to offer a noticeable overhead.
go to post Anna Golitsyna · Jul 19, 2021 Very interesting. If reading ObjectScript is ancient what can one say about pure, unadulterated MUMPS ? That was rhetorical, of course. I wonder how speed would fare with Python. GSIZE is way faster than the analogous ObjectScript functionality, at least for Cache 2017 that I use.
go to post Anna Golitsyna · Jun 11, 2021 I hit largely the same $System.OBJ.%Save <ZSG> error, in a code you cannot see, of course. After reading this thread I realized that the only unusual thing I did is to give my programmatically created project a numeric name. Apparently, there is a check inside %Save: if numeric it must be an object ID and not name… The error was gone as soon as I added a letter in the beginning of the name. I am also on Cache 2017
go to post Anna Golitsyna · May 13, 2021 If a specific class member causes this, yes, that might work indeed. I need to try it.
go to post Anna Golitsyna · May 13, 2021 That was one of the first ideas that I checked before posting here. Yes, it is large comparing to most other package classes but two much larger classes from the same package have been imported alright.
go to post Anna Golitsyna · May 12, 2021 Dmitry, thanks for the advice. The first function is not available in this Cache version and it will actually export, not just convert code to an array. The Atelier one calls the $preprocess command in question inside its stack and Atelier is not available in this Cache version either. The last function would be perfect but it also calls the $preprocess command in question and this is exactly where the call for this specific class dies, inside $preprocess.
go to post Anna Golitsyna · Apr 1, 2021 One late addition: I just lost this debugging functionality again, looks like because my code was going into a different namespace via zn "nsp". If I put the first breakpoint AFTER this zn, the cursor does not go to it and the yellow box does not appear. However, if I put my first breakpoint AT zn, the yellow box appears at it and stays with me after the breakpoint as well. Can't say it's a feature but then what??
go to post Anna Golitsyna · Feb 9, 2021 Losing debugging capabilities, Scenario #2.A fellow programmer also lost her debugging capabilities some time ago though for different reasons and with different symptoms. I am not dead sure what happened in her case but it looks like some unfortunate combination of User Roles and Service Settings as defined in Management Portal. We discussed it today and she tried a few things. Changing the studio login user helped as well as changing localhost in Cache Server Manager to an actual IP address. Using Remote System Access from the cube was beneficial as well.
go to post Anna Golitsyna · Feb 9, 2021 Alright, this particular saga suddenly came to the end revealing the bug, my own one. But it is sort of educational so some details. I am implementing source control like features on and off while inheriting one of the features from a previous programmer. The latter feature which I preserved was about adding a timestamp with the compilation time to the changed routine in the overwritten source control method, OnAfterCompile. OnAfterCompile was adding this timestamp, resaving the routine directly in one of the internal routine globals, and it did NOT recompile the file again. That effectively still had the file internally marked as saved and compiled, no little cross in the Studio's routine tab, BUT that threw the .OBJ file mapping to the routine source code enough so the debug yellow box would refuse to appear and the cursor would not move from the first line. Many self eye-rolling emojis here...How did I discover it? I need to modify this custom source control class and it was annoying to do so while the source control was on so I turned it off, moved functionality to my test routine, and observed with incredulity the long lost yellow debug box again....P.S. On the plus side, I learned a lot about inner Cache workings due to this largely self-inflicted wound and I am happy it is over.
