i've been really frustrated with Panda3d so far with the importation of models. Panda3d will only import a model once and will never update ever again (even after changing the name of the .egg file)
I first imported a model (let's call it version 1), into VS2010 panda3d. Then i revised the model in 3dsMax and exported it into egg again (version 2). However, no matter how many times i import, panda3d will stubbornly use version 1. Renaming the .egg doesn't help either. Im suspecting that panda3d caching system is caching my previous model and there's something important linking all the versions together, defaulting the panda3d engine to go back to version 1.
The main question is, how do i solve this problem of panda3d not taking in the latest model? Thank you.
I think you will get answers to your questions about Panda3D more quickly if you ask them over on the Panda3D forums.
But to answer your specific question, Panda does indeed incorporate a model cache, which by default reads a particular filename once (during a session) but does not read the disk again during the same session, even if the file changes (but you can explicitly ask it to read the disk again if you need this). Panda also has a persistent disk cache, which by default caches the loading of a model between sessions as well, though in this case it does always check the timestamp of the file before blindly returning the previous model, and if the file is updated, it will always re-read it and return the new version instead.
In neither case will it return a cached version if you completely rename the file, so something else must be going on in that case.
The precise way you disable caching depends on the particular calls you are using to load the model. You reference VS2010, so I infer that you are writing in C++ (but using VS2010 instead of VS2008 isn't officially supported, so you might have other problems as well unless you have far out of your way to use VS2010 correctly).
To avoid the cache for a particular model, try passing a LoaderOptions object with the LF_no_cache bits set in the flags to ModelPool::load_model() (or whichever interface you are using to load models).
Related
I am creating a PythonAnalyzer using the following code:
var interpreterFactory = InterpreterFactoryCreator.CreateAnalysisInterpreterFactory(
PythonLanguageVersion.V36.ToVersion());
var analyzer = PythonAnalyzer.Create(interpreterFactory);
Later on I also create and analyze a simple python module, that looks like this:
name = input('What is your name?\n')
print('Hi, %s.' % name)
Then I do module.Analysis.GetValuesByIndex("name", 4).
At this moment I expected the "value" to be 'str', because that's what Visual Studio shows when I open the same file in it. However, I get 'object' instead. So it seems that the PythonAnalyzer when constructed as mentioned above lacks some important information about where to look for standard library and/or its types.
Unfortunately, the documentation on PythonAnalyzer is lacking, so I was hoping the community could help understand how to configure it properly.
Congratulations on getting so far :)
What you're hitting here is the fact that CreateAnalysisInterpreterFactory is really intended for "pure" cases, where you have access to all the code that you're trying to analyze and nothing needs to be looked up. It is mostly used for the unit tests, or as a fallback when no copies of Python are installed. Depending on precisely which version of PTVS you are using, the bare information you're getting is either coming from DefaultDB\v3\python.pyi or CompletionDB\__builtin__.idb, both of which are somewhat lacking (by design).
Assuming you have a copy of Python installed, I would suggest creating an instance of InterpreterConfiguration with all of its details, and passing that to CreateInterpreterFactory (without "Analysis").
If you're on the latest sources (strongly recommended), this may run the interpreter in the background to collect information from it (you can control caching of this info with the DatabasePath and UseExistingCache members of InterpreterFactoryCreationOptions). If you are using the older version still, you'll need to trigger a completion DB regeneration or have one that you've created through VS.
And a final caveat: this part of PTVS is currently under some pretty heavy development at time of writing, so you'll either want to keep updating the version you're working against or stick with a slightly older one. Also feel free to post questions like this on the GitHub site, as while this is technically public API, it's barely documented at all and so the best help will come from the dev team.
I have an old MSDOS software realized in magic 5.6 with an btrieve 5.10a database, that should be modernized(completely redone using a modern DB).
For this I would love to just get the table structures and some understanding in the structure of the magic program.
But unfortunately I was not able to find any documentation on magic nor was I able to get the structure with column names from the tables(.btr but no ddf files).
Any idea on how to get a step further?
Not enough rep to comment, so I'm forced to post this as an answer.
If you can't get hold of any info regarding the data structure you might try:
A. Download and install a try-out version of a more recent Pervasive version and see if that enables you to read the data. In (still more or less current) server versions like V11 there is a DDF Builder utility, which does what the name implies. However, this is no automatic process, but relies on your ability to link the data shown in the application to the hex values on disk.
B. Try to find a BUTIL.EXE version that works with 5.x Btrieve files, run BUTIL -RECOVER and see what that gets you. You might get to parse the data with scripting tools this way - I've done it in the past on 6.x files, but nothing as old as you are dealing with.
The main issue here is whether you'll be able to find compatible tools for a version that old. But then again, maybe 6.x tools might just work.
I knew that modifying core-data previous version breaks the light-weight migration.
But I have inverse relationship warnings on old versions of data model.
I tried removing old versions that are used before launching first version of our app. I followed this SO question, "How to delete an old/unused Data Model Version in xCode 4"
It removes warning(Of course it should)
But I cannot run our app anymore
I think I should keep every versions even though it is not related to light-weight migration
I saw this SO question, "How to disable no inverse relationship warning for CoreData in Xcode 4.2?". And I tried setting the MOMC_NO_INVERSE_RELATIONSHIP_WARNINGS to YES.
It doesn't removes warning
And I don't want my future mistake, missing inverse setting, also be ignored.
I think this option is not for my case
I don't want to see compiler warning for old version of data model(.xcdatamodel).
Because these models are not used so that warnings are not significant.
But I want to see future inverse relationship warning on newer version of data model.
What option can I take?
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
I am not even sure how to ask this question. I am absolutely willing to research this myself, but I don't even know what exactly my options are.
I'm fairly new to programming in general, and I'm the sole developer on an ASP.NET MVC3 web application. We're about to upgrade to a new version which has a lot of addition to the data model. There are a couple new entities and some of the old entities have new properties/columns.
We've finished beta testing and now we're going to try to get everyone moved over to the new version running parallel to the current version, that way if there are show-stopping problems, users can easily switch back to the old version. The problem is that we can't hook both up to the same db because of the data model differences.
Can I make the old version use the new version's schema or something? I'm not really sure what my options are. I'm not asking you to write this for me; I'm just looking for some direction. Thanks!
You should be able to disable the metadata checks and then use two versions against the DB assuming the models use a schema that is compatible between both.
http://revweblog.wordpress.com/2011/05/16/ef-4-1-code-first-disable-checking-for-edmmetadata-table/
Another option is to use entity framework 4.3 code first migrations and actually use an upgrade script that it will generate for you. If it fails you can roll back the script to a prior version and use your prior code base. This would imply you upgrade to 4.3 first before doing anything else though although you could still disable metadata checks.