Is it possible to rename the guest additions components within virtual-box to anything different?
Some software behaves differently if it finds guest additions components on a machine, but they usually do it by doing string comparison against processes and internal components, so I was thinking that if I could just rename the components then I could avoid the trouble of replicating guest addition functionality manually.
It might not be possible if guest additions expects it's own components to be named correctly if it searches for them in the same way that .dll files get searched for, but I thought it might be worth a shot anyhow.
Related
Are there any plugins that would do this? Let's say you highlight a code block, when you press undo, it undoes the last change with in that code block?
I've done a lot of digging into Sublime's internals, and I don't think this is possible. Commands (processes executed when you select a menu item or hit a key combination) are implemented in one of two ways: either in Python, making use of the API, or internally in C++ and compiled directly into the executable or a library. If a command is implemented in pure Python, such as delete_word (source in Packages/Default/delete_word.py), you can edit the source if necessary or take portions to use in your own code. However, if a command is implemented internally, there's not much you can do to modify it, unless it has options that are documented somewhere. You basically have to use it as-is.
Which brings us to the undo/redo commands, and the edit history. As far as I can tell (since Sublime is not open source - yet), this entire functionality is completely implemented internally, with only the command names exposed. I have been completely unable to find any way of viewing or accessing the actual changes made to the undo/redo stack. The command_history() method of the sublime.View class accesses the commands in the undo/redo stack, but not the actual changes they made.
So, all of this is to say that one could not likely make a plugin that could access the change history of an arbitrary selection in Sublime. One of the major issues (aside from the fact that the change history of the view is not accessible) is that the text you select now might not correspond to anything at a certain point in the history - it might not exist, or could have been altered so fundamentally that it would be essentially impossible to identify which changes should be associated with the selection, and which not. I have never heard of a similar feature in any other editor, most likely for that exact reason.
Here is the context of my question. It is typical that one organizes configuration values into different files. In my case, my criteria is easy editing and portability from one server to another. The package is for Internet payments and it is designed so that a single installation of the package can be used for different applications. Also, we expect that an application can have different stages (development, testing, staging and production) on different servers. I use different files for each of the following three categories: the config values that depend only on the application, those that depend only on the server and those that depend on both. In this way, I can easily move the configuration values that depend only on the application from one server to another, say from development to production. They are edited often. So, it is worth it. Similarly, I can edit the values that are specific to the server in a single file without having to maintain redundant copies for the different applications. The term "configuration value" includes anything that must be defined differently in different applications or servers, even functions. If the definition of a function depends on the application or on the server, then it is a part of the configuration process. The term "configuration value" appeared natural to me, even it includes functions.
Now, here is the question. I wanted the functions to be PHPUnit testable. I use PHP, but perhaps the question makes sense in other languages as well. I decided to store the configuration values as properties and methods in classes and used class hierarchy to organize the different categories. The base class is PaymentConfigServer (depend only on the server). The application dependent values are in PaymentConfigApp extends PaymentConfigServer and those that depend on both are in PaymentConfig extends PaymentConfigApp. The class PaymentConfigApp contains configuration values that depend either on the application or on the server, but the file itself contains values that depend on the application only. Similarly, PaymentConfig contains all conf values, but the file itself contains values that depend on both only. Can this use of class hierarchy lead to issues? I am not looking for discussions about the best approach. I just want to know, if you met a similar situation, what issues I should keep in mind, what conflicts could arise, etc?
Typically, subclasses are used to add or modify functionality rather than remove functionality. Thus, the single-inheritance approach you suggested suffers from a conceptual problem that is likely to result in confusion for anyone who has to maintain the application if/when you get hit by a bus: the base class provides support for server-specific configuration, but then you (pretend to) remove that functionality in the PaymentConfigApp subclass, and (pretend to) re-add the functionality in its PaymentConfig subclass.
I am not familiar with the PHP language, but if it supports multiple inheritance, then I think it would be more logical to have two base classes: PaymentConfigServer and PaymentConfigApp, and then have PaymentConfig inherit from both of those base classes.
Another approach might be to have just a single class in which the constructor takes an enum parameter (or a pair of boolean parameters) that is used to specify whether the class should deal with just server-specific configuration, just application-specific configuration, or both types of configuration.
By the way, the approach you are suggesting for maintaining configuration data is not one that I have used. If you are interested in reading about an alternative approach, then you can read an answer I gave to another question on StackOverflow.
I am writing some support code in the common subset of Matlab/Octave, which comes in the form of a bunch of functions. Let's call it a package.
I want to be able to organize the package, i.e.,
put all the relevant function files in a single place, where users
are not supposed to store their code;
have some internal organization ('subpackages');
prevent namespace pollution;
have some mechanism for user code to 'import' parts of the package;
I don't necessarily want all functions I provide to be
visible from user clients.
On the Matlab side of things, this functionality is pretty much provided by package directories and the 'import' mechanism. This functionality doesn't appear to be available in Octave though (as of 3.6.1).
Given that, I wonder what options remain for organizing my support code package in Octave.
The option of putting everything in a directory and just have the user code do an ADDPATH feels rather unrefined, and doesn't give the level of control I want -- it only addresses point #1 of the list above.
There is plenty documentation here and examples in OctaveForge. Just browse the SVN.
Also there are personal packages all around. For example this one
Happy coding!
We have trouble with keeping apart our different configurations. Allow me to explain with a little
Scenario:
Let's say you have two AX projects, e.g. P and M, that both alter the ProdRouteJob table, calling methods in one of their own project specific classes.
You have all these classes on your developer machine, of course, and ProdRouteJob compiles fine, but for an installation on a new server, you don't want to add stub classes for every non-installed project, do you? So you wrap these calls to project classes in something like
if( Global::isConfigurationkeyEnabled( <projectPConfKey> ) )
// call project P stuff
to encapsulate them cleanly. You declare configuration keys for all your projects, and you're ready to go, right?
However, this throws an error if you haven't installed project P on this machine, because its projectPConfKey is unknown. Now you could at every installation install configuration keys for all your projects, just to tell the server that there is such a thing as a projectPConfKey, but then all these ifs would evaluate to true...
In short: how do you include configuration keys in your project XPOs so that your code compiles, but at the same time so that some configuration keys are disabled from the start?
Or is there something totally basic that I'm missing here?
EDIT:
Consensus among the answers (thank you, demas; thank you, Mr. Kjeldsen) is that it's impractical to attempt a more or less automatic client-side configuration via macros or configuration keys. Thus, when we are installing at the client, we will have to import the standard tables with our changes and manually take out all changes not pertinent to the current installation.
I am a bit at a loss which answer to accept, because demas answered the question I asked, while Mr. Kjeldsen answered the questions that arose in the comment conversation under demas' answer. I shall, with apologies to Mr. Kjeldsen, mark demas' answer as accepted.
if( Global::isConfigurationkeyEnabled( <projectPConfKey> ) )
This check works only execution time and when you compile code you get the error.
So you need create stub classes or compare objects when you import them on production server and import only changes of project M.
There is another one approach but I don't have Axapta to check it. Try:
#if.never
someMissingCall();
#endif
But i'm not sure that it will works now.
Big solution centers (VAR) typically have separate applications for each module.
If you have 2 modules, you have 2 applications.
Good modules have very small collision areas to the standard application, these are kept in a separate project.
Collisions with the standard and other modules are then handled manually at install time. As the collision area is small and rarely change (it should not contain buisness logic) the problem is minimal.
Since MathWorks release a new version of MATLAB every six months, it's a bit of hassle having to set up the latest version each time. What I'd like is an automatic way of configuring MATLAB, to save wasting time on administrative hassle. The sorts of things I usually do when I get a new version are:
Add commonly used directories to the path.
Create some toolbar shortcuts.
Change some GUI preferences.
The first task is easy to accomplish programmatically with addpath and savepath. The next two are not so simple.
Details of shortcuts are stored in the file 'shortcuts.xml' in the folder given by prefdir. My best idea so far is to use one of the XML toolboxes in the MATLAB Central File Exchange to read in this file, add some shortcut details and write them back to file. This seems like quite a lot of effort, and that usually means I've missed an existing utility function. Is there an easier way of (programmatically) adding shortcuts?
Changing the GUI preferences seems even trickier. preferences just opens the GUI preference editor (equivalent to File -> Preferences); setpref doesn't seems to cover GUI options.
The GUI preferences are stored in matlab.prf (again in prefdir); this time in traditional name=value config style. I could try overwriting values in this directly, but it isn't always clear what each line does, or how much the names differ between releases, or how broken MATLAB will be if this file contains dodgy values. I realise that this is a long shot, but are the contents of matlab.prf documented anywhere? Or is there a better way of configuring the GUI?
For extra credit, how do you set up your copy of MATLAB? Are there any other tweaks I've missed, that it is possible to alter via a script?
shortcuts - read here and here
preferences - read http://undocumentedmatlab.com/blog/changing-system-preferences-programmatically/
At the moment, I'm not using scripts, though this sounds like a very interesting idea.
Unless there are new features that you also want to configure, you can simply copy-paste the old preferences into the new prefdir. I guess this should be doable programmatically, though you might have to select the old prefdir via uigetdir. So far, this has not created major problems for me. Note also that in case of a major change in the structure of preferences, any programmatic version would have to be rewritten as well.
I'm adding paths at each startup, so that I don't need to think of manually adding new directories every time I change something in my code base (and I don't want to have to update directory structures for each user). Thus, I also need to copy-paste startup.m for each installation.
If I had to do everything manually, I'd also want to change the autosave options to store the files in an autosave directory. If I recall correctly, Matlab reads the colors and fonts from previous installations, so I don't have to do that.