I would like to check for moderation with Stata using the interaction # and two continuous variables:
version 10.1: xi: regress ................///
c.var1_m#c.var9_m c.var2_m#c.var9_m c.var3_m#c.var9_m ///
var9_m , vce(robust)
However, it seems that only the newest Stata versions support this command, as I get the following error message:
cvar1_m#c: operator invalid
Does anyone know a way to fix this command as such that it also works with Stata 10.1?
(For example to fix the i. command, I typed in version 10.1: xi: and then it also worked on my older version - does something similar exist for c.?)
What version of Stata are you using? Stata 10.1, it seems.
Factor variables were introduced in Stata 11. Regardless of what version you are using this is documented accessibly (e.g.) here.
The question that then arises is why are you using the prefix version 10.1?
If you are using version 10.1, that prefix is redundant; otherwise, it can at most set the clock back to the syntax of earlier versions. It should be clear that it cannot possibly set it forward to the syntax of later versions.
A more fundamental mix-up is that (a) syntax using xi: as aegis and (b) factor-variable notation are (a) old and (b) new versions of the same idea. They should not be mixed. It may be that this alone is the problem, but experts on either [not me] might wish also to see your complete syntax and/or a reproducible example.
In short, if you are using 10.1, or indeed some earlier version, your only option (other than upgrading your Stata) is to cast your problem in syntax acceptable to xi:.
Related
NET6 introduces file-scoped namespaces. If used, VS code struggles to render the correct syntax highlighting. Do yo see the same and if so, is there a workaround? I'm using a default theme.
Cheers
I've found C# syntax highlighting broken by file-scoped namespace #136886 and https://github.com/OmniSharp/omnisharp-vscode/issues/4884.
Fortunately, it's a known issue that it is going to be corrected in a future release of VS Code. In fact, it is already corrected in the 'insider' (a.k.a.beta) version.
Edit 2021-11-26:
For completeness sake, solution is in this Github comment:
chrmarti commented 15 days ago
This seems to be fixed in VS Code Insiders. Could you give that a try: https://code.visualstudio.com/insiders/
That is confirmed by other users in next comments pointing at release 1.63.0-insider as stated here:
deckerbd commented 15 days ago
I'm noticing highlighting differences as well when using file-scoped namespace and records.
VS Code (1.62.1):
VS Code Insider (Version: 1.63.0-insider (Universal) commit: c109637):
On the other hand, as suggested in some of the GitHub responses, it looks like enabling semantic highlighting does not produce the expected results because this feature must be fully supported by color theme used.
It does not work for everyone. For example, it is not the case with the two themes I've been lately using, Night Owl and Noctis Minimus.
These is how it looks in my case with 1.63.0-insider:
And the same file with incorrect highlight in 1.62.1 release:
My settings are:
"csharp.semanticHighlighting.enabled": true,
"editor.semanticHighlighting.enabled": "configuredByTheme",
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I am checking an existing perl script for vulnerabilities. Most perl-related vulnerabilities only apply to certain versions. Is there a way to determine which version was used to write the perl script? (I cannot ask the developer.) Thank you!
There can be some indications as to the minimum Perl version that a given script is targeting. For example:
When an explicit version requirement is declared, e.g. use v5.12.
When explicit features are used, e.g. use feature 'say'. See perldoc feature for the relationship between Perl versions and available features.
When particular syntax is used. For example:
the // defined-or operator makes it easy notice post-5.10 code.
push or pop with a scalar argument signify 5.14 to 5.24.
Regex syntax also tends to have occasional changes, like /d, /u, /a, /l modifiers in 5.14 or /n in 5.22.
You will have to read the perldelta documents for the list of relevant changes.
The Perl::MinimumVersion module can help with automating some of those checks.
However, the presence or absence of such features has nothing to do with the vulnerabilities of the given program. Instead:
Make sure that you are running the script with an up to date Perl interpreter. Do not keep running unsupported old versions.
Except for rare edge cases, new Perl versions are extremely backwards compatible and should work without any issue. But note that upgrading Perl involves reinstalling all modules (in particular, any XS modules must be recompiled).
Make sure you are also looking at the dependencies of the script. Are they also up to date? Whether new versions are similarly compatible will depend on the specific module.
I've seen that Perl allows you to put a use VERSION statement at the top of the file, e.g.
use v5.16.3;
which results in a compiler error if the current version of the interpreter is smaller.
Is it good practice to specify the version number?
According to comments, you should use VERSION; only if your scripts depend on some language features or bug fixes which cannot be found in minor versions. For example using say, which is added in Perl 5.10.
Also, you can use Syntax::Construct to state which non-feature constructs you want to use in your code.
I am teaching some matlab classes and we have some version-ing issues ... some students use versions as old as 2008b and some of the computers in the lab have versions as old as 2007a (or as new as 2012b). I want to create some pcode files which will run on all of these versions ... that way they can check their results without seeing the actual code that created them.
I know that Matlab 2013a (the version I use daily) can operate pcode files made from any previous version but the older versions can't run pcode made with my computer.
Is there any way to create backwards compatible pcode files? I know I can just find the oldest version and make a pcode on that computer and distribute it ... but that's really annoying. Especially because I don't have licences for versions that are as old as some of the students (my oldest is 2010a and some students/lab-computers are still stuck on 2008b)
Thanks,
Will
From the documentation:
The pcode algorithm was redesigned in MATLAB 7.5 (Release R2007b). You can run older P-files in any current version of MATLAB; however, upcoming releases will not run P-files created before version 7.5. Files generated in 7.5, or later versions, cannot run in MATLAB 7.4 or earlier.
(Use docsearch pcode to view, expand "More about, Tips").
Based on the lack of any related tips or help, I suspect that pcode cannot be transitioned either way between pre-2007a and post-2007b.
From my experience, I have never had problems using pcode between versions. I think that this algorithm change in release 7.5 is a relatively rare thing.
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...