I followed the tutorial on http://silversprite.codeplex.com/ and got rid of a few issues that were expected (the colors etc). But there is 1 compile error left:
Error 2 The type 'Microsoft.Xna.Framework.Graphics.VertexDeclaration' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\Microsoft.Xna.Framework.Graphics.dll' and 'C:\Users\Brandon\Desktop\SilverSprite.dll' C:\Users\Brandon\Desktop\Projects\Other projects\Game Jam prac\Silverlight3dApp1\Silverlight3dApp1\Silverlight3dApp\VertexPositionColorNormal.cs 31
I've been searching for over an hour and can't find a solution.
The error means exactly what it says: There is a type, VertexDeclaration, that is being defined by both Silverlight and by SilverSprite. When your project tries to resolve which one to use - it can't decide.
SilverSprite is, and has always been, kind of buggy. This appears to be a bug in SilverSprite. It's coming from this file, which contains a declaration of VertexDeclaration which is nothing like the actual API.
Fortunately you don't have to implement it yourself - because Silverlight provides it. I suggest you download the SilverSprite source and include it as a project in your solution, and reference that instead of the DLL (ie: build SilverSprite from source yourself). Then you can easily modify it and simply delete the bogus type definition - your code will then automatically use the real one.
If you come across any other bugs, I suggest you look at ExEn. I made it last time I tried to use SilverSprite (although this was before Silverlight 5) - and I fixed many, many bugs. You might find it useful to salvage code from.
Related
I've been using VSCode for C language professionally almost everyday for +1 year. Right now, I hit with something that is really affecting my productivity.
When I open a big project, the features "Go to definition, Go to declaration, Peek..." etc don't work. I don't know how to describe how 'big' the project is. There are source files with +26k lines and it can take up to 45 min to compile. When I work with a more reasonably sized project, I have no issues, so until now I assumed this was a limitation of the program due to the size of my project and resigned myself. Now, I'm really bothered at this point and would like to find a solution.
What strikes me is that searching in the whole project (Ctrl + Shift + F) is blazing fast and works brilliantly, so VS seems to be capable of 'handling' this big project.
C/C++ extension from Microsoft last version v0.28.3
VSCode last version 1.46.1
Windows 10
Do you think there is a solution for this? Have you used VSCode with massive projects?
Edit: by 'don't work' I mean, it tries to perform the action but stays 'thinking' indefinitely.
Most propably it is not "Not working" but just "pretty slow". This is a known problem for C/C++ projects using the C/C++ extension for Visual studio code. The Indexer for intellisense needs some time (especially if you are not limiting it via limitSymbolsToIncludedHeaders or something like that). You could try reducing the amount of parsed files by using explizit browse paths in your c_cpp_properties.json like
"browse": {
"path": [
"/usr/include/",
"/usr/local/include/",
"${workspaceRoot}/../include",
"${workspaceRoot}/dir1",
"${workspaceRoot}/dir2",
"${workspaceRoot}/dir3/src/c++",
"${workspaceRoot}/dir5",
"${workspaceRoot}/dir6/src",
"${workspaceRoot}/dir7/src",
"${workspaceRoot}/dir4"
],
and excluding for example IDE/SDK files where you do not need autocompletion/Go To Symbol/Go to definition.
For more explanation see: https://github.com/microsoft/vscode-cpptools/issues/1695
When running tools such as formatters and linting tools with "auto-correction" options, it can be that the input and output for a Rule are the same file; for example:
"//*.hs" %> \out ->
cmd_ "ormolu" "-m" "inplace" out
-- OR
batch 10 ("//*.hs" %>)
( \out -> do
cmd_ "ormolu" "-m" "inplace" out
pure out
)
(cmd_ "hlint")
This seems to work "correctly" (the rule is re-run if the source file is needed and has changed), but we're unsure if this is a happy coincidence or shake working as designed - especially when we start thinking about cached results from shakeShare or in the future Cloud Shake. Is this the best way to handle this type of rule, or is there something better?
There is no principled way to generate a rule that replaces a source file in Shake. Given a source code formatter, anything else isn't very usfeul. Shake makes the assumption that inputs don't change while the compilation is ongoing. It's likely that passing --lint will lead to a lint error and that it would be incompatible with Cloud Shake. The official advice would be to make such changes in a separate non-Shake pass before you call shake.
However, if it works for you, and is useful, I wouldn't overly worry. The pattern has tests in Shake, it's something plenty of people do. You can turn off Cloud caching on a per file basis with historyDisable.
I have a huge project, whole written in C language and I have a single make file that is used to compile it. The project C files contains lots of capitalize problems in it's header files, meaning there are tones of header files that were miss-spelled in lots of C files.
The problem is I need to migrate this project to compile on Linux machine and since Linux is case sensitive I got tones of errors.
Is there an elegant way which I can run make file in Linux and tell him to ignore case sensitive?
Any other solution will be welcome as well.
Thanks a lot.
Motti.
You'll have to fix everything by hand and rename every file or fix every place with #include. Even if you have a huge project (comparable with linux kernel), it should be possible to do this during a hour or two. Automation may be possible, but manual way should be better - because script won't be able to guess which name is right - filename, or the name used in #include.
Besides, this situation is a fault of original project developer. If he/she wasn't sloppy and named every header in every #include correctly, this wouldn't happen. Technically, this is a code problem similar to syntax error. The only right way to deal with it is to fix it.
I think it takes not too long to write a small script, which goes thru the directories first, then replaces C headers. Explained:
Scan the headers' folder and collect filenames.
Make a lowercase list of them. You have now original and locased pairs.
Scan the C source files and find each line contains "#include"
Lowercase it.
Find the lowercase filename in the list collected and lowercased from headers.
Replace the source line with the one collected from headers.
You should put the modified files into a separate folder structure, avoid overwriting the whole source with some buggy stuff. Don't forget to create target folders during the source tree scan.
I recommend a script language for that task, I prefer PHP, but just it's the only server-side script language which I know. Yep, it will run for a while, but only once.
(I bet that you will have other difficulties with that project, this problem is not a typical indicator of high quality work.)
Well I can only tell you that you need to change the case of those header files. I don't know that there is any way you can make it automatic but still you can use cscope to do it in a easier way.
http://www.linux-tutorial.info/modules.php?name=ManPage&sec=1&manpage=cscope
You can mount the files on a case-insensitive file system. FAT comes to mind. ntfs-3g does not appear to support this.
I use the find all and replace all functionality of Source Insight when i have to do complete replacement. But your problem seems quite big, but you can try the option to replace every header file name in all occurences of source files using the
"Find All" + "Replace" functionality. You can use notepad++ too for doing the same.
A long time ago there was a great tool under MPW (Macintosh Programmer's Workshop) called Canon. It was used to canonize text files, i.e. make all symbols found in a given refernce list have have the same usage of upper/lower case. This tool would be ideal for a task like this - I wonder if anything similar exists under Linux ?
When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).
I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv