I am not too sure of what is wrong i believe the functions are causing an issue but cannot see why
self.upButton.clicked.connect(self.up())
def up(self):
global newStr
if inpUser=='':
self.imagesEtc()
else:
for i in inpUser:
if i in alphabet:
numPos=alphabet.index(i)
numPos+=1
numPos%=26
newStr+=alphabet[numPos]
Ive been trying to figure out the issue but cannot. I have posted the code that flags up above
Related
I recently came across AMIEGO. When I try to run the example problems (provided in the example directory) I get the following error.
-------------------------------------------------------------------------------
Exit Flag: True
Elapsed Time: 0.04829263687133789
======================ContinuousOptimization-End=======================================
+------------------------------------------------------------------------------+
| pyOptSparse Error: Received an unknown option: 'Major optimality tolerance' |
+------------------------------------------------------------------------------+
Traceback (most recent call last):
File "/home/sky/anaconda3/lib/python3.8/site-packages/openmdao/utils/concurrent.py", line 65, in concurrent_eval_lb
retval = func(*args)
File "/home/sky/anaconda3/lib/python3.8/site-packages/amiego/kriging.py", line 239, in _calculate_thetas
opt_x, opt_f, success, msg = snopt_opt(_calcll, x0, low, high, title='kriging',
File "/home/sky/anaconda3/lib/python3.8/site-packages/amiego/optimize_function.py", line 76, in snopt_opt
opt.setOption(name, value)
File "/home/sky/anaconda3/lib/python3.8/site-packages/pyoptsparse/pyOpt_optimizer.py", line 829, in setOption
raise Error("Received an unknown option: %s" % repr(name))
pyoptsparse.pyOpt_error.Error
I tested pyoptsparse optimization driver with the sellar problem and it worked as expected. So I think I'm missing something in AMIEGO. And fyi I didn't modify anything in the example, so I am running it with SLSQP(from pyoptsparse driver) for the continuous part(I dont have SNOPT). Any pointers on how to fix this or where to start looking will be helpful.
I've pushed up a couple of fixes to the repository so that you can run it without SNOPT. The basic Branin problem in the examples works and gets to the expected answer now. I can't promise that SLSQP is the best choice for more complicated problems as we usually favor SNOPT over SLSQP in our work. This is still very experimental code, so the documentation is weak and there are still a lot of control knobs and flags that are buried as subcomponent attributes (including ideas that we tried that didn't pan out). But we appreciate users who are willing to try AMIEGO and help us improve it.
I have a simple Chapel program to test the NetCDF module:
use NetCDF;
use NetCDF.C_NetCDF;
var f: int = ncopen("ppt2020_08_20.nc", NC_WRITE);
var status: int = nc_close(f);
and when I compile with:
chpl -I/usr/include -L/usr/lib/x86_64-linux-gnu -lnetcdf hello.chpl
it produces a list of errors about SysCTypes:
$CHPL_HOME/modules/packages/NetCDF.chpl:57: error: 'c_int' undeclared (first use this function)
$CHPL_HOME/modules/packages/NetCDF.chpl:77: error: 'c_char' undeclared (first use this function)
...
Would anyone see what my error is? I tried adding use SysCTypes; to my program, but that didn't seem to have an effect.
Sorry for the delayed response and for this bad behavior. This is a bug that's crept into the NetCDF module which seems not to have been caught by Chapel's nightly testing. To work around it, edit $CHPL_HOME/modules/packages/NetCDF.chpl, adding the line:
public use SysCTypes, SysBasic;
within the declaration of the C_NetCDF module (around line 50 in my copy of the sources). If you would consider filing this bug as an issue on the Chapel GitHub issue tracker, that would be great as well, though we'll try to get this fixed in the next release in any case.
With that change, your program almost compiles for me, except that nc_close() takes a c_int argument rather than a Chapel int. You could either lean on Chapel's type inference to cause this to happen:
var f = ncopen("ppt2020_08_20.nc", NC_WRITE);
or explicitly declare f to be of type c_int:
var f: c_int = ncopen("ppt2020_08_20.nc", NC_WRITE);
And then as one final note, I believe you should be able to drop the -lnetcdf from your chpl command-line as using the NetCDF module should cause this requirement to automatically be added.
Thanks for bringing this bug to our attention!
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
First issue: I am trying to import stdlib.h in order to use functions like malloc() and rand(). I am working in threadtest.cc , folder threads. This is the error I get after
#include <stdlib.h>
In file included from ../threads/threadtest.cc:18:0:
/usr/include/stdlib.h:146:33: error: declaration of ‘double atof(const char*) throw ()’ has a different exception specifier
In file included from ../threads/utility.h:57:0,
from ../threads/system.h:12,
from ../threads/threadtest.cc:13:
../machine/sysdep.h:62:8: error: from previous declaration ‘double atof(const char*)’
In file included from ../threads/threadtest.cc:18:0:
/usr/include/stdlib.h:149:33: error: declaration of ‘int atoi(const char*) throw ()’ has a different exception specifier
In file included from ../threads/utility.h:57:0,
from ../threads/system.h:12,
from ../threads/threadtest.cc:13:
../machine/sysdep.h:61:5: error: from previous declaration ‘int atoi(const char*)’
In file included from ../threads/threadtest.cc:18:0:
/usr/include/stdlib.h:771:60: error: declaration of ‘int abs(int) throw ()’ has a different exception specifier
In file included from ../threads/utility.h:57:0,
from ../threads/system.h:12,
from ../threads/threadtest.cc:13:
../machine/sysdep.h:63:5: error: from previous declaration ‘int abs(int)’
../threads/threadtest.cc: In function ‘void shout(int)’:
../threads/threadtest.cc:83:25: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
What can be a reason for this?
Second issue: I am trying to give a forked new thread a name.
Thread * t = new Thread ("my id");
t->Fork(shout, S);
And testing it in function shout:
printf ("%s", currentThread->getName());
This example works fine.
However, if I want to give the thread a "dynamic" id, I use:
sprintf(id, "%d", i);
Thread * t = new Thread (id);
With the same printf for currentThread->getName() it gets me junk:
x�ӿ����_ ���
I have used example from the Nachos documentation as well as tried different ways to transmit a dynamic id using string functions, but nothing worked, only junk.
Thank you for any answers.
I had the same problem in my Nachos homework.
My roommate said maybe it's a incompatibility problem, and suggested that I delete "stdlib.h".
It worked!
I have the weird problem that when I include anything from the QtNetwork module into my Qt Desktop application, I get a bunch of errors, before anything of the included is even used.
For example, if I include QtNetwork/QHostAddress, I get the following errors:
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qabstractsocket.h:66: error: template with C linkage
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qabstractsocket.h:253: error: declaration of C function 'QDebug operator<<(QDebug, QAbstractSocket::SocketState)' conflicts with
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qabstractsocket.h:252: error: previous declaration 'QDebug operator<<(QDebug, QAbstractSocket::SocketError)' here
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qhostaddress.h:141: error: declaration of C function 'QDebug operator<<(QDebug, const QHostAddress&)' conflicts with
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qabstractsocket.h:253: error: previous declaration 'QDebug operator<<(QDebug, QAbstractSocket::SocketState)' here
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qhostaddress.h:148: error: declaration of C function 'QDataStream& operator<<(QDataStream&, const QHostAddress&)' conflicts with
..\..\QtSDK\Desktop\Qt\4.8.1\mingw\include/QtNetwork/qhostaddress.h:141: error: previous declaration 'QDebug operator<<(QDebug, const QHostAddress&)' here
Of course, I added the line
Qt += network
to my .pro file, so this can't be the issue. Another module (opengl) could be included without problems.
I already ensured that nothing is wrong with my Qt installation itself by creating a dummy project which did nothing but including QtNetwork. It worked just fine.
So, there must be something wrong with my project, but as the error messages only occur in this special case I have no idea what information to provide for you.
All I can say is that the program was pure C-Code before and it is now being changed to C++ with Qt, so there is still a mix in it. But this does not seem to be a problem as long as QtNetwork is not included.
Any ideas on how to solve this or on what information is relevant for this problem?
I finally figured out my problem. The solution is quite easy:
I included QTNetwork into a header file, which in turn was included into some other .cpp-file by my team member, but he wrongly placed the include-statement in an extern "C" block, so that in the end QTNetwork was included as an extern "C" even though it is C++.
So, two lessons learned:
Don't rely on the correctness of your team mates' code.
If an include leads to errors, follow up the whole include chain to track down the problem.