I was wondering how I would fix this error in the Logos.pl file, this is what I'm getting:
WillPhone:/var/mobile/sbtest1 root# make package install
/var/mobile/sbtest1/theos/makefiles/targets/Darwin-arm/iphone.mk:43: Targeting iOS 4.0 and higher is not supported with iphone-gcc. Forcing clang.
Making all for tweak sbtest1...
Preprocessing Tweak.xm...
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Constants from lexical variables potentially modified elsewhere are deprecated at /private/var/theos/bin/lib/aliased.pm line 42.
Can't call method "isNew" on an undefined value at /var/mobile/sbtest1/theos/bin/logos.pl line 382.
make[2]: *** [obj/Tweak.xm.a114fd55.o] Error 255
make[1]: *** [internal-library-all_] Error 2
make: *** [sbtest1.all.tweak.variables] Error 2'˚`
Thanks! - Will B
You can go to Theos Github to submit this issue.
Here are some other projects with this issue.I hope it will help you.
https://github.com/preaction/Statocles/issues/190
https://github.com/Crowdtilt/Business-BalancedPayments/issues/53
Related
I know the meaning of below CMake statement:
cmake_minimum_required(VERSION 3.10)
I am just wondering what the VERSION part is syntactically?
Is it a unquoted argument? If it is an argument, there must be some other argument choices.
But according to here, it seems VERSION is the only choice for the cmake_minimum_required() command.
If so, why do we even need to specify this argument explicitly??
And according to here, this command sets the variable CMAKE_MINIMUM_REQUIRED_VERSION. Is there some kind of string concatenation here? So I can use set_minimum_required(XXX <some_value>) to sent an arbitrary variable with the name CMAKE_MINIMUM_REQUIRED_XXX to <some_value>?
ADD 1
I just tried with below statement in the CMakeLists.txt:
cmake_minimum_required(XXX 123)
And cmake complains that:
CMake Error at CMakeLists.txt:2 (cmake_minimum_required):
cmake_minimum_required called with unknown argument "XXX".
So it seems to be an argument.
But according to here for the project() command, a similar VERSION string is designated as an option. Seems a bit inconsistent.
ADD 2
I just tried with below statement in the CMakeLists.txt:
cmake_minimum_required(3.10)
And cmake complains that:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
cmake_minimum_required called with unknown argument "3.10".
So it seems CMake relies on the VERSION part to properly interpret the "3.10" argument. So I guess the VERSION is also an option here.
And since there's another possible option FATAL_ERROR, it is necessary to have a VERSION option.
So to summarize my current understanding:
The essential paradigm of CMake language is:
CMake commands just manipulate variables based on arguments and options.
Some variables are required to be manipulated and some are optional.
For required ones, their values are specified through arguments. (kind of like positional argument)
For optional ones, their values are specified through argument following corresponding options. (kind of like named argument)
ADD 3
From here, for the VERSION in cmake_minimum_required():
The VERSION is a special keyword for this function. And the value of
the version follows the keyword.
So here it is called keyword instead of option ...
Add 4
Some feelings about CMake...
What is the "VERSION" in "cmake_minimum_required(VERSION 3.10)”
I am just wondering what the VERSION part is syntactically?
A string. VERSION. Nothing special.
Is it a unquoted argument?
Yes.
why do we even need to specify this argument explicitly??
To preserve forward compatibility. The idea is that maybe in the feature there will be cmake_minimum_required(DATE 2021-11-03) or similar, for example.
Is there some kind of string concatenation here?
No. It is set explicitly.
So I can use set_minimum_required(XXX <some_value>) to sent an arbitrary variable with the name CMAKE_MINIMUM_REQUIRED_XXX to <some_value>?
No.
Some variables are required to be manipulated and some are optional.
CMake argument parsing is really crude and simple. It's basically in shell pseudocode if $1 == "VERSION" then check_version($2) else error. How you call those strings is really up to your interpretation that depends on the context, in the context of cmake_minimum_required, sure VERSION is a "keyword". Or a "special required argument". Or similar.
All function arguments are strings, and functions compare them to other strings and execute logic upon that. There are no other variable types. Lists are strings, list elements are separated by ; character in a string.
And the implementation of cmake_minimum_required is here: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmCMakeMinimumRequired.cxx#L29 . Funny, it looks like the parsing is in a loop, so doing cmake_minimum_required(VERSION VERSION VERSION VERSION 3.11) works as fine.
I think the input to a CMake command can be classified as 3 types:
keyword argument (also called option)
positional argument
variable arguments (like ... in C)
For 1, Like the VERSION in cmake_minimum_required, whose value follows it immediately. It is called keyword or option.
For 2, Such argument has a formal name and is referenced through that name within the command body.
For 3, the argument can be referenced with ARGV, ARGN, ARGVC.
I also see marker argument somewhere. But I forget where. Horrible syntax...
ADD 1
OK I found the marker argument. It's in the book Mastering CMake by the CMake team:
...while the CMake official document says it's an option:
Search the paths specified by the PATHS option or in the short-hand
version of the command. These are typically hard-coded guesses.
What a chaotic wording...
I just inherited a Create React App based project and noticed something peculiar. When I run npx eslint src/ there are no issues. No output, nothing. Even introducing some errors seemed to make no difference! On the other hand, when doing npm start I can see lots of ESLint output in the console:
Compiled with warnings.
./src/Components/Exercises/Edit.tsx
Line 100:9: 'generateSubtypesList' is assigned a value but never used #typescript-eslint/no-unused-vars
./src/Components/Workouts/Table.tsx
Line 1280:45: Expected '===' and instead saw '==' eqeqeq
Line 1281:43: Expected '===' and instead saw '==' eqeqeq
./src/Components/Workouts/Edit.tsx
Line 12:3: 'TextField' is defined but never used #typescript-eslint/no-unused-vars
Line 381:6: React Hook React.useEffect has a missing dependency: 'delSuperSetList'. Either include it or remove the dependency array react-hooks/exhaustive-deps
./src/Components/Sessions/Edit.tsx
Line 130:6: React Hook React.useEffect has a missing dependency: 'delSuperSetList'. Either include it or remove the dependency array react-hooks/exhaustive-deps
./src/Components/Workouts/Add.tsx
Line 13:3: 'TextField' is defined but never used #typescript-eslint/no-unused-vars
Line 176:6: React Hook React.useCallback has a missing dependency: 'delSuperSetList'. Either include it or remove the dependency array react-hooks/exhaustive-deps
./src/Components/Workouts/ExerciseSetsList.tsx
Line 145:34: Expected '===' and instead saw '==' eqeqeq
Line 150:30: Expected '===' and instead saw '==' eqeqeq
Line 150:58: Expected '===' and instead saw '==' eqeqeq
./src/Components/Settings/Availability.tsx
Line 177:23: Expected '===' and instead saw '==' eqeqeq
...
What is happening here and how can I make ESLint output these warnings on the command line?
Manually adding ESLint v7 makes things work as expected?
So the strange thing I found is that if I do npm install eslint so that version 7 gets installed, everything works as expected:
$ node ./node_modules/react-scripts/node_modules/eslint/bin/eslint.js --version
v6.8.0
$ node ./node_modules/react-scripts/node_modules/eslint/bin/eslint.js src/
$ # nothing was found
$ node ./node_modules/eslint/bin/eslint.js --version
v7.32.0
$ node ./node_modules/eslint/bin/eslint.js src
/Users/my-user/dev/myproj-trainer-web/src/Components/Clients/Details.tsx
41:10 warning 'isPropertyDeclaration' is defined but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Exercises/Add.tsx
72:9 warning 'generateCategoryList' is assigned a value but never used #typescript-eslint/no-unused-vars
168:9 warning 'validateInput' is assigned a value but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Exercises/Details.tsx
8:10 warning 'ExerciseTypes' is defined but never used #typescript-eslint/no-unused-vars
9:8 warning 'CloseIcon' is defined but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Exercises/Edit.tsx
95:9 warning 'generateSubtypesList' is assigned a value but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Exercises/Listings.tsx
333:56 warning 'is_user_exercise' is assigned a value but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Menus/SubMenu.tsx
1:8 warning 'React' is defined but never used #typescript-eslint/no-unused-vars
2:10 warning 'NavLink' is defined but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Schedules/Details.tsx
3:10 warning 'format' is defined but never used #typescript-eslint/no-unused-vars
14:3 warning 'Info' is defined but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Sessions/Cancel.tsx
63:9 warning 'generateTimeToSession' is assigned a value but never used #typescript-eslint/no-unused-vars
/Users/my-user/dev/myproj-trainer-web/src/Components/Sessions/Details.tsx
504:18 warning Expected '===' and instead saw '==' eqeqeq
I don't really understand why version 6.8 keeps silent on the CLI, but not when interfacing with the CRA build?
Suddenly I'm getting an error in _types.h on the line with typedef. How can I track this down?
#ifdef __GNUC__
typedef __signed char __int8_t;
#else /* !__GNUC__ */
This is pretty much always caused by a syntax error just prior to whatever included the file with the actual error.
So, have a look in the file that (indirectly) included _types.h. You likely have an unbalanced (.
Usually these cryptic errors in system header files result from your having other code (perhaps in another header file which was #import'ed earlier) that is missing a closing parenthesis. Often whenever you get strange compile errors, you have to look at the lines of code that the compiler encountered before the reported line and see if that earlier code was properly terminated.
I'm trying to compile some c code with g++ (yes, on purpose). I'm getting errors like (for example):
error: invalid conversion from 'void*' to 'unsigned char*' [-fpermissive]
adding -fpermissive to the compilation options gets me:
error: invalid conversion from 'void*' to 'unsigned char*' [-Werror=permissive]
which seems to be a error because of -Werror, however adding -Wno-error=permissive -Wno-permissive results in:
error: -Werror=permissive: no option -Wpermissive
error: unrecognized command line option "-Wno-permissive" [-Werror]
How do I disable warnings (globaly) for conversions from void* to other pointer types?
You cannot "disable warnings for conversions from void* to other pointer types" because this is not a warning - it is a syntax error.
What's happening here is that you are using -fpermissive which downgrades some errors - including this one - to warnings, and therefore allows you to compile some non-conforming code (obviously many types of syntax errors, such as missing braces, cannot be downgraded to warnings since the compiler cannot know how to fix them to turn them into understandable code).
Then, you are also using -Werror which upgrades all warnings to errors, including the "warnings" that -fpermissive has turned your error into.
-Wno-error is used only to negate -Werror, i.e. it causes -Werror to treat all warnings as errors except the warnings specified with -Wno-error, which remain as warnings. As the -W flag suggests, both these flags work with warnings, so they can't do anything with this particular issue, since what you have here is an error. There is no "warning" for this kind of invalid conversion that you can switch off and on with -Werror because it's not a real warning - it's an error that -fpermissive is merely causing to be treated as a warning.
You can compile your non-comforming code, in this case, by using -fpermissive and not using -Werror. This will still give you a warning, but like all warnings, it won't prevent successful compilation. If you are deliberately trying to compile non-conforming code, then using -Werror makes no sense, because you know your code contains errors and will therefore result in warnings, even with -fpermissive, so specifying -Werror is equivalent to saying "please do not compile my non-conforming code, even though I've just asked you to."
The furthest you can go to get g++ to suppress warnings is to use -fsyntax-only which will check for syntax errors and nothing else, but since what you have here is a syntax error, that won't help you, and the best you can do is have that turned into a warning by -fpermissive.
How do I disable warnings (globaly) for conversions from void* to
other pointer types?
Well it might require direct interaction with compiler's code. This is probably not what you want. You want to fix your code. First, these are not warnings but errors. You need to cast void* as you can not convert a void* to anything without casting it first (it is possible in C however which is less type safe as C++ is).
For example you would need to do
void* buffer = operator new(100);
unsigned char* etherhead = static_cast<unsigned char*>(buffer);
^
cast
If you want a dynamically allocated buffer of 100 unsigned char then you are better off doing this
unsigned char* p = new unsigned char[100];
and avoiding the cast.
void pointers
In summary, is it possible to access via use association a preprocessor directive defined in a Fortran module?
Context
I use preprocessor statements to define subroutines to print warning and error messages. For example, I use the following module/subroutine, in the file errors.f, to print warning messages
module errors
use, intrinsic :: iso_fortran_env, only : error_unit=>stderr
implicit none
contains
!> Print formatted warning message.
subroutine warn_print( file, line, mesg )
implicit none
character(len=*), intent(in) :: file
integer, intent(in) :: line
character(len=*), intent(in) :: mesg
write(stderr,'(a,a,a,i4,a,a)') "WARNING::", file, ":", line, ": ", mesg
end subroutine warn_print
end module errors
and, in a separate file errors.h, I use the above module and define a preprocessor macro
use errors
#define warn( text )warn_print(__FILE__,__LINE__,text)
I then #include the file errors.h in whichever file/module I wish to use the warning print routine which allows me to simply write
call warn("Some warning message")
and the compiler will automatically include the file and line number at which the warning message was called.
Question
The use of #include 'errors.h' is rather idiosyncratic in Fortran code and it hides the use of the errors module. Ideally I would prefer to define the above preprocessor in the errors module itself. However, then when using that module, this preprocessor directive is not available to the program/module which uses this module.
Is there a way to make a preprocessor directive accessible via use association?
The only other way I can think of doing it is to just have the errors module and define the preprocessor directive in my call to the compiler (using, for example, the -D flag with ifort). Any suggestions for any alternative way of achieving the above would be greatly appreciated.
No, it is simply not possible, since the preprocessing and the compilation stages are completely separate one from each other and the C preprocessor does not know anything about the Fortran USE statement.
I use to #include 'config.h' (from autoconf) in most of my .F90 sources, without problems.
This may not be what you are looking for, but if you are using ifort, you can use traceback functionality to achieve something similar (a bit more powerful, but also more ugly), e.g.
program tracetest
call sub(5)
write(*,*) '=== DONE ==='
end program tracetest
subroutine sub(n)
use ifcore
integer :: n
character(len=60) :: str
write(str,*) '=== TROUBLE DETECTED: n =',n ! code -1 means "do not abort"
call tracebackqq(str,-1)
end subroutine sub
Then, compile with -traceback to see the source file, line, and stack trace. The stack trace and line may be obscured because of inlining; to avoid that, you can specify -traceback -O0 to get smth like this:
=== TROUBLE DETECTED: n = 5
Image PC Routine Line Source
a.out 0000000000473D0D Unknown Unknown Unknown
a.out 0000000000472815 Unknown Unknown Unknown
a.out 0000000000423260 Unknown Unknown Unknown
a.out 0000000000404BD6 Unknown Unknown Unknown
a.out 0000000000402C14 sub_ 12 tracetest.f90
a.out 0000000000402B18 MAIN__ 2 tracetest.f90
a.out 0000000000402ADC Unknown Unknown Unknown
libc.so.6 000000323201EC5D Unknown Unknown Unknown
a.out 00000000004029D9 Unknown Unknown Unknown
=== DONE ===
Alternatively, if want to keep the optimizations, and also want to see the correct line (12), you can compile with (for example) -fast -traceback -debug all,inline_debug_info. Something similar may be available in other compilers, but I am not sure.