In general, what are the ways that we can make sure a single instance of application?
This is not specific to any programming language.
I just want to know how we can prevent starting the second instance of an application?
I can think of two ways:
Application side:
Create a lockfile somewhere on a specified location. If it already exists, another instance is running, otherwise create the lockfile. If the program exits, delete the lockfile. (For example X or firefox do this)
OS side: (Although this wouldn't be that practical)
2.1. For all started binaries, store some hash value somewhere. If an binary is already started, (E.g. the hash value is already available), don't start it.
2.2. This will fail quite often, as you could run only ONE JVM, ONE Python interpreter and so on. So to improve this, the OS could add the commandline arguments for example to the hash value.
Related
I've been given the task of researching whether one can use Powershell to automate the managing of References in VB6 application and then compile it's projects afterwards.
There are 3 projects. I requirement is to remove a specific reference in each project. Then, compile projects from bottom up (server > client > interface) and add reference back in along the way. (remove references, compile server.dll >add client reference to server.dll, compile client.dll > add interface reference to client.dll, compile interface.exe)
I'm thinking no, but I was still given the task of finding out for sure. Of course, where does one go to find this out? Why here of course, StackOverflow.
References are stored in the project .VBP files which are just text files. A given reference takes up exactly one line of the file.
For example, here is a reference to DAO database components:
Reference=*\G{00025E01-0000-0000-C000-000000000046}#5.0#0#C:\WINDOWS\SysWow64\dao360.dll#Microsoft DAO 3.6 Object Library
The most important info is everything to the left of the path which contains the GUID (i.e., the unique identifier of the library, more or less). The filespec and description text are unimportant as VB6 will update that to whatever it finds in the registry for the referenced DLL.
An alternate form of reference is for GUI controls, such as:
Object={BDC217C8-ED16-11CD-956C-0000C04E4C0A}#1.1#0; tabctl32.ocx
which for whatever reason never seem to have a path anyway. Most likely you will not need to modify this type of reference, because it would almost certainly break forms in the project which rely on them.
So in your Powershell script, the key task would be to either add or remove the individual reference lines mentioned in the question. Unless you are using no form of binary compatibility, the GUID will remain stable. Therefore, you could essentially hardcode the strings you need to add/remove.
Aside from all that, its worth thinking through why you need to take this approach at all. Normally to build a VB6 solution it is totally unnecessary to add/remove references along the way. Also depending on your choice of deployment techniques, you are probably using either project or binary compatibility which tends to keep the references stable.
Lastly, I'll mention that there are existing tools such as Kinook's Visual Build Pro which already know how to build groups of VB6 projects and if using a 3rd party tool like that is an option, could save you a lot of work.
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
Update: TL;DR there seems to be no built-in way to achieve this, so a custom task is an easy solution.
Capistrano provides facilities to share files and directories over all releases. This is convenient and provides even some safety on files that should not be easily changed (or must remain the same across releases), e.g. a database configuration file.
But when it comes to replace or just update one of these shared files, I end up doing it manually, directly on the target machine. I would like to improve on that, for instance by asking Capistrano to overwrite some or all shared files when deploying. A kind of --force flag with some granularity.
I am not aware of any such kind of facility, and failing so far in my search. Any pointer?
Thinking about it
One of the reason why this facility does not exist (except that I did not find it!) is that it may be harder than it looks. For example, let's assume we have a shared database configuration file, and we exclude it from version control for security reason (common practice). Current release relies on version 1 of the DB configuration. The next release requires version 2 of the DB configuration. If the deployment goes well, everything's good. It gets harder when rolling back after some error with the new release (e.g. a regression), as version 1 must then be available.
Such automation would be cool and convenient, but dangerous as well. Yet I have practical use cases at hand.
I created a template method to do this. For example, I could have a task like this:
task :create_database_yml do
on roles(:app, :db) do
within(shared_path) do
template "local/path/to/database.yml.erb",
"config/database.yml",
:mode => "600"
end
end
end
And then I have a database.yml.erb template that uses things like fetch(:database_password) to fill in appropriate values. You can use the ask method in Capistrano to prompt for these values so they are never committed.
The implementation of template can be very simple: you just need to read the file, pass it through ERB, and then use Capistrano's upload! to place the results on the server.
My version is a little more complicated than yours probably needs to be, but in case you are curious:
https://github.com/mattbrictson/capistrano-mb/blob/7600440ecd3331945d03e059368b75849857f1fb/lib/capistrano/mb/dsl.rb#L104
One approach is to use a system configuration tool like Chef or Puppet to deploy the configuration files distinctly from Capistrano.
Another approach is to create a custom task to do this: https://coderwall.com/p/wgs6gw/copy-local-files-to-remote-server-using-capistrano-3
I personally don't change on-server configs often enough or on enough servers yet to have tried to automate it. Crafting an scp command which copies the desired config file to all of the required servers has sufficed in the past.
I have an app which works great in the development environment but misbehaves when deployed as an EXE. When I click deploy and make an EXE, all of my queries which are run through DataStore objects succeed (SQLCode 0) but return zero rows. Out of frustration I changed to visible datawindows and it magically worked again under an EXE. So I made the datawindows invisible and it continued to work. This is just bizarre. I have another powerbuilder app which is much larger, uses lots of DataStore objects (on the same database) and those work great.
DataStore ds_wacn
ds_wacn = create datastore
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
ds_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
// Succeeds in development, fetches zero rows under EXE
dw_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
// Succeeds in development and in EXE
I was very careful to make sure that the app that works and the one that fails are using the same settings to connect to the database (but still could be a problem there). This is Powerbuilder 11.5.1
Very likely your DataWindow object isn't being compiled into the EXE.
When you compile an EXE, PowerBuilder starts at the Application object and intelligently tries to determine which objects should be included. Since d_plateaccessions is only referenced in a string in a script, it isn't included.
There are two ways around this.
You can create a PBD for the PBL containing the DataWindow. PBD creation blindly includes all objects in the PBL. This method is quite popular, and many people just mark all their PBLs for PBD creation and deploy the PBDs.
You can alternatively create a PBR for the EXE, telling the compiler to force certain DataWindows and graphic files into the EXE. If you really want a single EXE, but don't want the effort of building an appropriate PBR, you can use PBL Peeper to generate PBRs and scripts to force all DataWindows and objects (and find all relevant graphics) into a compiled EXE, using the PBR Builder Plus report.
Good luck,
Terry.
I have a problem with your first 4 rows.
DataStore ds_wacn
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)
Do you really retrieve on dw_wacn instead of ds_wacn?
And there isn't "create" for your local datastore.
I don't use frenquently local datastore but in this case the code is like this in our program
dataStore ds_myDs
ds_myDds = create datastore
ds_myDds.DataObject = 'myDataObject'
ds_myDds.SetTransObject(SQLCA)
ds_myDds.Retrieve( /*arguments or not*/)
/*
some code
*/
destroy ds_myDs
I'm getting ready to try to deploy some code to multiple machines. As far as I know, using a Makefile.pm to track dependencies is the best way to ensure they are installed everywhere. The problem I have is I'm not sure our Makefile.pm has been updated as this application has passed through a few different developers.
Is there any way to automatically parse through either my source or a few full runs of my program to determine exactly what versions of what modules my application is depending on? On top of that, is there any way to filter it based on CPAN packages? (So that I only depend on Moose instead of every single module that comes with Moose.)
A third related question is, if you depend on a version of a module that is not the latest, what is the best way to have someone else install it? Should I start including entire localized Perl installations with my application?
Just to be clear - you can not generically get a list of modules that the app depends on by code analysis alone. E.g. if your apps does eval { require $module; $module->import() }, where $module is passed via command line, then this can ONLY be detected by actually running the specific command line version with ALL the module values.
If you do wish to do this, you can figure out every module used by a combination of runs via:
Devel::Cover. Coverage reports would list 100% of modules used. But you don't get version #s.
Print %INC at every single possible exit point in the code as slu's answer said. This should probably be done in END{} block as well as __DIE__ handler to cover all possible exit points, and even then may be not fully 100% covering in generic case if somewhere within the program your __DIE__ handler gets overwritten.
Devel::Modlist (also mentioned by slu's answer) - the downside compared to Devel::Cover is that it does NOT seem to be able to aggregate a database across multiple sample runs like Devel::Cover does. On the plus side, it's purpose-built, so has a lot of very useful options (CPAN paths, versions).
Please note that the other module (Module::ScanDeps) does NOT seem to allow you to do runtime analysis based on arbitrary command line arguments (e.g. it seems at first glance to only allow you to execute the program with no arguments) and if that's true, is inferior to all the above 3 methods for any code that may possibly load modules dynamically.
Module::ScanDeps - Recursively scan Perl code for dependencies
Does both static and runtime scanning. Just modules, I don't know of any exact way of verifying what versions from what distributions. You could get old packages from BackPan, or just package your entire chain of local dependencies up with PAR.
You could look at %INC, see http://www.perlmonks.org/?node_id=681911 which also mentions Devel::Modlist
I would definitely use Devel::TraceUse, which also shows a tree of the modules, so it's easy to guess where they are being loaded.