This is awesome!!
Clarifying question - re: "special tables that only support row-based sampling", would this be tables with custom/non-default storage definitions?
- Log in to post comments
This is awesome!!
Clarifying question - re: "special tables that only support row-based sampling", would this be tables with custom/non-default storage definitions?
Yeah... kind of annoying.
I'd recommend looking at what (other than valid JSON) is in result.HttpResponse.Data. Also worth looking at result.HttpResponse.StatusCode - is it 400 or 404?
It looks like there might be an issue with the service you're trying to use - at https://apisidra.ibge.gov.br/ , pasting in "/t/1612/n2/all/v/all/p/last/c81/2702/f/u" as "Parâmetros/valores da API:" then clicking "Consultar" I get an alert saying "A solicitação de conexão com pools sofreu timeout".
I also see this from ObjectScript with Server set to apisidra.ibge.gov.br instead of api.sidra.ibge.gov.br
Right - at this point I'd say set Server to apisidra.ibge.gov.br instead of api.sidra.ibge.gov.br and see if that fixes it.
@Stefan Cronje I've sent you a message. The discussion at https://github.com/intersystems/TestCoverage/issues/10
is relevant but I think your root cause may be different.
Basic troubleshooting steps / things to think about:
* Is the line-by-line monitor running? (do ^%SYS.MONLBL and see what it says)
* Do you have .int code for the classes for which you're measuring coverage? (compile with the "k" flag to keep this around)
* Did you say what classes/routines you wanted to measure coverage of? (see instructions at https://github.com/intersystems/TestCoverage)
Given that two people have run into this now I think there's something that should be changed to help avoid the situation. Perhaps forcing the line-by-line monitor/PERFMON to stop (if it's running) prior to starting it for a test coverage run and/or identifying possible causes of the issue.
It's also possible that %objlasterror is leaking without that error being the root cause of any issues. I'd start by looking at how you're saying which units of code to measure coverage for - e.g., via coverage.list or an explicit list passed in to the CoverageClasses/CoverageRoutines parameter as described at https://github.com/intersystems/TestCoverage
Per message from @Stefan Cronje the issue was a missing coverage.list. I've filed https://github.com/intersystems/TestCoverage/issues/11 to cover an enhancement to fail early and descriptively in this case rather than just doing nothing.
I'm not aware of any JSON schema capability.
%Dictionary has two sets of classes: *Definition and Compiled*. If you want to see inherited members you need to look at Compiled* (e.g., CompiledClass / CompiledProperty). If you want to know from which class, there's an "Origin" property.
I'd run a query against %Dictionary.CompiledProperty where parent = (the classname)
Just had time to do a more detailed writeup here: https://community.intersystems.com/post/listing-all-properties-class-an…
I've updated my original post with a bit of performance analysis as well (couldn't resist) - I'm curious if anyone has ideas for getting an embedded SQL approach even closer to raw global refs. :)
@Stephen Canzano good call - I've updated the post accordingly.
This is the way.
What I'm trying to do is manage the process spawned with $zf(-100) from ObjectScript. In short, if the ObjectScript process is killed or <INTERRUPT>ed (which you can't do while in a ZF state), I want to kill the spawned process as well.
More specifically, I have a main ObjectScript process that's monitoring an Angular build. It spawns another ObjectScript process that used to just call $zf(-100) synchronously to run a build script. This other process would then notify the parent via $System.Event when it's done. Normally this build script will run for a finite period of time, but I'm looking to run an Angular build with the --watch flag and terminate it when the user Ctrl+C's in Terminal.
I think it's probably going to just come down to using a pipe/command pipe/etc. instead of $zf(-100).
I was hoping to avoid something like that. It seems like I run into other issues with what I'm trying to do though around killing the spawned process anyway. I think $zf(-100) just won't do the trick.
##class(%SYS.ProcessQuery).GetOSUsername()
Problem in my case is that it's a non-IRIS process, so interactions from IRIS are limited.
These would be set via the Configuration Registry, though it seems they aren't discussed in the docs for it. See: https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXREG_ch_configuration_registry
Here's a sample that loads interoperability system defaults from an XML file:
Class Sample.CCREventHandler Extends %Studio.SourceControl.CCREventHandler
{
/// This method is called during the loading of an ItemSet, after the contents of the ItemSet have been loaded into the namespace,
/// and after the ImplementCCR routine has been run
Method ItemSetAfterLoadToNS() As %Status
{
set key = ""
for {
set item = ..ItemSetItemList.GetNext(.key)
quit:(key="")
if (key [ "backup/ens/defaults.xml") {
$$$ThrowOnError(##class(Ens.Config.DefaultSettings).%Import(^Sources_"backup/ens/defaults.xml"))
quit
}
}
Quit ##super()
}
/// This method is called by the CCR Refresh logic, after the items have been refreshed into the namespace. It is intended for any additional configuration work which
/// may be necessary (e.g. initialization of reference tables, building of 3rd party sources, etc)
Method RefreshFinalize() As %Status
{
$$$ThrowOnError(##class(Ens.Config.DefaultSettings).%Import(^Sources_"backup/ens/defaults.xml"))
Quit ##super()
}
}Things I mentioned in the kickoff webinar:
%SQL.AbstractFind/%Library.FunctionalIndex implementations:
Semantic version index:
https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/Ge…
https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/Ge…
https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/Re…
Spatial index: https://github.com/intersystems-ru/spatialindex
Image color index: https://openexchange.intersystems.com/package/iris-image-index-demo
Inspiration for a project:
Implement a hierarchical index that operates on a table with a self-referential field (e.g., an employee table with a manager field) to return (via a %SQL.AbstractFind implementation) all records above (directly/indirectly), below (directly/indirectly), or in the same tree (or graph - need to consider circular references) as a given record.
Some things that would help diagnose the issue:
write $zv
Modify TestCoverage.Manager to output the following as soon as possible after the error occurs:
write $zu(56,2)
It would also help to know what arguments are being passed to %Monitor.System.LineByLine:Start.
Also would be good to know what's in userParams
On further review, you get a <FUNCTION> error from trying to start the line-by-line monitor when no routines are selected, and the work around is to change namespace to %SYS, do ^PERFMON, and stop the monitor.
USER>zw ##class(%Monitor.System.LineByLine).Start("","",$job)
"0 "_$lb($lb(5002,"<FUNCTION>zStart+45^%Monitor.System.LineByLine.1",,,,,,,,$lb(,"USER",$lb("$^zStart+45^%Monitor.System.LineByLine.1 +1","X^@ +1"))))/* ERROR #5002: ObjectScript error: <FUNCTION>zStart+45^%Monitor.System.LineByLine.1 */In terms of using the test coverage tool, you should either put a file named coverage.list in your unit test root or pass the list of classes/routines in userParam as described at https://github.com/intersystems/TestCoverage .
https://github.com/intersystems/TestCoverage/issues/11 covers the bad behavior you've seen and would prevent it going forward. (Subsequent attempts to start the line-by-line monitor will end up hitting error #6060 as described in https://github.com/intersystems/TestCoverage/issues/10 .)
Bad behavior of %Monitor.System.LineByLine reported internally as DP-412988
@Michael Davidovich yes we do! It's useful and just in a steady state (although I have a PR in process around some of the recent confusing behavior that's been reported in the community).
I've published TestCoverage 2.1.3 on the Open Exchange / zpm - in the situations leading to this, you'll get a more descriptive error message now and the system won't be left in a bad state.
@Michael Davidovich I was out Friday, so still catching up on all this - glad you were able to figure out coverage.list. That's generally a better way to go for automation than setting a list of classes.
re: the plugin, yes, that's it! There's a GitHub issue that's probably the same here: https://github.com/timleavitt/covcomplplot-plugin/issues/1 - it's back on my radar given what you're seeing.
@Alex Kogan is this just a matter of = vs. ==? (The worst thing when switching between ObjectScript and JS...)