I am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael
Related
I have finally come across something that no one else seemed to have come across (at least from what I can tell). I trying to build an F# type provider using TypeProviders.SDK.
As soon as I build the solution I get the error: "FS0810, Property 'CultureName' cannot be set, \LemonadeProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs" on line 2090 and again at 3162 in the design time project of the solution.
I do not think this is useful but the Test project also fails as it can not find the LemonadeProvider.Runtime.dll. I am assuming this will get created when the Runtime project will build successfully.
PS: As of right now I am just tring to build the provided template, I have not changed the code or added anything to it. Hence I have not attached any code, but please feel free to ask for it.
The corresponding issue is https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/353
Known workarounds
Change minimum target to net461. Replace all instances of net45 with net461, except for in netfx.props, where you can just delete the lines referencing net45* frameworks (I suspect the removal of those lines isn't strictly speaking necessary).
I did this workaround but am now facing these kinds of errors: (like 2000 of them)
C:\Users\user\source\repos\HelloWorldProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs(34,7): error FS0074: The type referenced through 'System.Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'. [C:\Users\user\source\repos\HelloWorldProvider\src\HelloWorldProvider.DesignTime\HelloWorldProvider.DesignTime.fsproj]
I found out that the issue lied with the ProvidedTypes.fs and ProvidedTypes.fsi files created by the SDK.
The issue was solved for me when I replaced the files with the ones found in 'SDK-dsyme-patch-7' which provided compatibility for different .Net environments which was missing from the original SDK. There might be other differences but this is the one I found and it fixed the problem for me.
The files can be found under '/src/' in the dsyme patch.
The code I am referring to is as follows and has been added twice to the ProvidedTypes.fs:
#if NETSTANDARD
asmName.CultureName <- System.Globalization.CultureInfo.InvariantCulture.Name
#else
asmName.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
#endif
asmName
I am not aware if there is a new SDK that has solved the problem. But at the time when the question was asked, this is what worked for me.
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
I've set up VES and am modifying the Kiwiviewer app in XCode 4.3.2. Kiwi builds and runs fine, so I'm now trying to set up Sudzc within my app (it works fine standalone). I've followed the tutorial here but at the point after modifying the headers, where his app builds and runs, mine instead comes up with a succession of errors. At first, it gives >150 errors all along the lines of:
Lexical or Preprocessor Issue
Invalid token at start of a preprocessor expression
Mostly pointing at the line
#include "xmlversion.h"
in a file tree.h, which is a part of vtkmodular/Utilities/vtklibxml2/include/libxml/tree.h.
Changing the " " to < > (which was suggested for a similar problem) instead gives another Lexical or Preprocessor Issue, this time that 'xmlversion.h' file not found - seemingly all in the file tree.h. The file's in my Project Navigator (and cmd-clicking on #include "xmlversion.h" does indeed load the file, so it understands it that way).
Presumably then the problem is with vtk having its own version of libxml2? If this is the case - what can I do about this? All of the errors I've looked at seem to originate from within soap handler classes, and eventually get through to "include < libxml/tree.h>" - which is then in the vtk directory shown above. I'm not really sure where to go from here - is it wrong to include the library that's added in the instructions? Can/should I modify the header paths? If this isn't the tree.h the rest of the code is looking for, where is it - a quick system search didn't find it?
Or am I completely off the mark?
Thanks in advance!
I got an answer from the VES Mailing List, link here. It ended up being as simple as removing the VTK version of libxml2, which it seems VES doesn't use. Hope this might be of use to someone!
Okey, this is not a core programming question; it is more of a question regarding cgns (CFD general notational system) API.
I've exported a grid/mesh file from ANSYS Fluent (which was first created in Gambit 2.46), and I wrote a very simple Fortran program to open and close it (doing nothing else). To check the file is not corrupt I plotted it in Tecplot.
So, when I compiled using gfortran with the mentioned cgns and ran the program I got this error (as part of cg_error_exit_f())
ADF_Database_Open:File does not exist or is not a HDF5 file
Here is the program
program cavity
include "/usr/include/cgnslib_f.h"
call cg_open_f("Cavity.cgns",CG_MODE_READ,index_file,ier)
!check for error if so exit
if (ier .ne. CG_OK) then
call cg_error_exit_f()
end if
write(*,*)"I kind of opened the file?"
call cg_close_f(index_file,ier)
stop
end program cavity
I'm able to write both structured and unstructured grids in cgns format, without any problem.
I suspect the cgns library I'm using(version 2.5.5 packaged in Fedora 15 and Scientific linux 6.1) is built to support only HDF5, while the exported grid file is written in ADF format.
Any ideas to circumvent this or perhaps adding ADF? Which by the way is not packaged in both the distributions. Any other grid generator which is compatible with cgns version 2.5.5?
I hope I was clear. Any further info required, I would provide.
There is so much that could've gone wrong in here, and I'm afraid you didn't exactly narrow the problem down.
You said you exported a file from Fluent (what kind of a file is it? Be sure!). cg_error_exit_f() gave you an error listed. I'm assuming you have the source of the mentioned routines? In the program you include a cgnslib_f.h file - what's in it? I'm assumming the program compiled without errors of any kind, making this a file format question, not a fortran question.
Again, verify what kind of file Fluent produced.
When I ran into this situation, I discovered the following tools:
hdf2adf
adf2hdf
They are in the cgns-convert package on Ubuntu and are probably available for your distribution as well.
Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.