I followed this guide to implementing build numbers in an XCode iPhone project (guide).
I tried it and I am getting the wrong build number when NSLogging. It's not updating correctly and is always one or two numbers behind the info.plist. I need it to be the same number. Anyone know why this is happening?
i.e "[[[NSBundle mainBundle] infoDictionary] objectForKey:#"CFBuildNumber"]" is not the same as the plist's CFBuildNumber.
The script is set to run first, before copy bundle resources and everything. This is the output and info.plist numbers I get:
Application Version: 1.0 Build No: 52 Build Date: Wed Nov 10 15:10:05 CET 2010
(info.plist is build number: 54 and date: Wed Nov 10 15:10:43 CET 2010)
Application Version: 1.0 Build No: 54 Build Date: Wed Nov 10 15:10:43 CET 2010
(info.plist is build number: 55 and date: Wed Nov 10 15:12:54 CET 2010)
Application Version: 1.0 Build No: 54 Build Date: Wed Nov 10 15:10:43 CET 2010
(info.plist is build number: 56 and date: Wed Nov 10 15:13:49 CET 2010)
Application Version: 1.0 Build No: 56 Build Date: Wed Nov 10 15:13:49 CET 2010
(info.plist is build number: 57 and date:Wed Nov 10 15:14:46 CET 2010)
It seems to follow this pattern throughout. So continuing it would be 56 (real 58), 58 (real 59), 58 (real 60), 60 (real 61), 60 real (62), 62 (real 63) etc. etc.
The script (that is set to run before everything else) is:
#!/bin/bash
# Auto Increment Version Script
buildPlist="Project-Info.plist"
CFBuildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBuildNumber" $buildPlist)
CFBuildNumber=$(($CFBuildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBuildNumber $CFBuildNumber" $buildPlist
CFBuildDate=$(date)
/usr/libexec/PlistBuddy -c "Set :CFBuildDate $CFBuildDate" $buildPlist
Because project's Info.plist processed prior to 'Run Script' phase. See 'Build results' window in XCode. To resolve this you should
1) Create new target with type "Run script only" and configure it to update version number
2) Create new target with type "Aggregate" and add to it "Version update" target and "you product" target.
So when you build "Aggregate" target, at first step - version will be updated, and at second step - your product.
I ended up using the already-copied plist file, ${TARGET_BUILD_DIR}/${INFOPLIST_PATH}, and placing the "copy bundle resources"-phase before the script runs instead. That way the number will always be synchronized.
Related
I am trying to convert a .osm.pbf file to a .osm file.
https://wiki.openstreetmap.org/wiki/Osmosis/Quick_Install_(Windows)
I followed the instructions here:
Installed Java Runtime
Downloaded osmosis and extracted it to a directory
Created a bat file containing "C:\Users\paul\Desktop\osmosis\bin\osmosis.bat"
In a dos command prompt when im in the directory of where the batch file I created is located I try:
osmosis --read-pbf c:\dir\somefile.osm.pbf --write-xml c:\dir\somefile.osm
It just runs really quickly and doesnt convert the file and gives this output:
Nov 24, 2021 4:40:20 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.48.3
Nov 24, 2021 4:40:22 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Nov 24, 2021 4:40:22 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
Nov 24, 2021 4:40:22 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
Nov 24, 2021 4:40:22 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline complete.
Nov 24, 2021 4:40:22 PM org.openstreetmap.osmosis.core.Osmosis run
INFO: Total execution time: 2297 milliseconds.
Some sources provide a .osm.bz2 or .osm.zip format which uses standard compression. You can use a program like 7zip to covert those files to a raw .osm file. This format is the easiest to convert to a raw .osm.
However if you need to convert a binary .pbf to a raw .osm I would recommend the tool OSM Convert. Download the large file support version. Unfortunately Osmosis has been unmaintained since September 2018, so try to use newer tools. There is a list of them kept here on the OpenStreetMap Wiki.
With OSM Convert I've used this command with success on Windows 10: osmconvert us-latest.osm.pbf --out-osm -o=us-latest.osm_01.osm to convert us-latest.osm.pbf to us-latest.osm_01.osm
I wanted to view the contents of a perl script in our environment which is called dfv_run.pl and specifically check line 245. Line 245 from that script printed the message "Finished checking test result" in my simulation log file. After executing % which dfv_run.pl I am pointed to this location:
drwxr-xr-x 2 dfvmgr dfvadmin 4.0K Jun 22 2017 .SYNC
-r--r--r-- 1 dfvmgr dfvadmin 3.2K Jun 22 2017 loadenv.csh
-r-xr-xr-x 1 dfvmgr dfvadmin 5.2K Jun 22 2017 loadenv
drwxr-xr-x 4 dfvmgr dfvadmin 4.0K Jun 22 2017 ..
drwxr-xr-x 3 dfvmgr dfvadmin 4.0K Jun 22 2017 .
lrwxrwxrwx 1 dfvmgr dfvadmin 7 Jun 22 2017 dfv_comp.pl -> loadenv
lrwxrwxrwx 1 dfvmgr dfvadmin 7 Jun 22 2017 dfv_run.pl -> loadenv
lrwxrwxrwx 1 dfvmgr dfvadmin 7 Jun 22 2017 dfv_sim.pl -> loadenv
/tools/dfv/scripts/v11/bin
However the script is only less than 200 lines and I can see the same content for dfv_comp.pl, dfv_run.pl, and dfv_sim.pl (also diff did not show any difference among the 3 perl scripts). loadenv of course also showed me the same contents.
Any help as to how I can view the real content of each perl script is much appreciated. Additional info which might help:
SHELL=/bin/tcsh
KONSOLE_DBUS_SERVICE=:1.46
KONSOLE_DBUS_WINDOW=/Windows/17
KONSOLE_DBUS_SESSION=/Sessions/30
Kindly let me know if additional info is needed. Thank you in advance!
What you're seeing is the real content. All three *.pl filenames are aliases to the loadenv script - that one script handles all four commands.
If you look at the contents of loadenv (or any of the other three names), you will most likely see that it checks to see which name was used to invoke it and then sets some flags which will cause it to behave differently depending on which name was used.
I just encountered some strange behavior with Perl 5.16.3 on FreeBSD 9.3-RELEASE-p3. We've got a cron job which runs every five minutes and generates some text status files. I just happened to list the contents of the output directory and saw that the timestamps for some of the files were in the future! The files are created like this:
if (open(OUT, "> $status_file_path")) {
print OUT "$status_info\n";
close OUT;
}
Now, the file handle OUT is used in several places, however it is opened and closed within the same block as shown above. And like I said, out of ten files, only a few had future dates when displayed using ls.
For example, files with the current date had timestamps like 04/02/2015 20:29:46, files with future timestamps were out in November, e.g. 11/10/2015 09:38:41.
What might be going on here?
EDIT
I've got two tests running:
1) a perl script running a loop of 1000 iterations, sleeping a random time up to 10 seconds between iterations, using the open/print/close logic to create an output file and abort the script if the file's modification time is in the future.
2) a cron entry to touch a test file every minute, e.g. touch /home/test/test_file_date_with_cron.txt
TEST RESULTS
Neither of the tests generated output files with a timestamp in the future.
This is scary.
EDIT 2
Here is the filesystem info, the files are written in the /usr directory.
# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/gprootfs 2G 133M 1.7G 7% /
devfs 1.0k 1.0k 0B 100% /dev
/dev/gpt/gpusrfs 431G 3.8G 392G 1% /usr
procfs 4.0k 4.0k 0B 100% /proc
EDIT 3
Running the script outside of cron for several hundred iterations didn't duplicate the problem. HOWEVER, I just found some other files, which are created by a CGI script which have the future dates:
-rw-r--r-- 1 test test 5783 Nov 10 2015 Config.xml_20150210_104151
-rw-r--r-- 1 test test 34548 Nov 10 2015 Config2.xml_20150210_104151
-rw-r--r-- 1 test test 6105 Nov 10 2015 Config.xml_20151109_232210
-rw-r--r-- 1 test test 34554 Nov 10 2015 Config2.xml_20151109_232210
-rw-rw-r-- 1 root test 2075 Nov 9 2015 Config.xml_20151109_231055
-rw-rw-r-- 1 root test 1232 Nov 9 2015 Config2.xml_20151109_231055
These are archive files, which get moved and renamed with the file's mtime timestamp. Note that BOTH ls and Perl's stat() function report the future date -- stat() is used to generate the file's timestamp portion of the name.
Looking at the first entry, ls reports "Nov 10 2015", whereas when the CGI script processed it, Perl's stat() reported "20150210_104151", i.e. "Feb 02 2015" which is most likely correct.
Further down, we see ls showing "Nov 10 2015" and stat() reported "20151109_232210", i.e. "Nov 09 2015".
Finding those additional archived config files helped me track down the cause, which was as others have suggested, that the system date and timezone changed.
From: 1447147328 and America/Adak
To: 1426637771 and America/New_York
What was throwing me off, was that I thought the cron script wrote ALL of the output files each time it executes, but that's not the case. The files have different "refresh intervals".
I'm running a JMeter test plan from command line and it's currently outputting something along the lines of:
Created the tree successfully using C:\*****\TestPlan.jmx
Starting the test # Thu Oct 11 10:20:43 EDT 2012 (1349965243947)
Waiting for possible shutdown message on port 4445
Tidying up ... # Thu Oct 11 10:20:46 EDT 2012 (1349965246384)
... end of run
Is there any way to turn off this output and have the plan execute 'silently'?
Found a way to do this, by following this article http://www.robvanderwoude.com/battech_redirection.php
and appending > NUL to the command
jmeter -n -t C:\***\TestPlan.jmx -Jhostname=%1 > NUL
i created a GWT project in eclipse, and it's time to put some code back into source control. i'm not sure at this point which files are generated and can be left out of source control,
a. under war/myapp/gwt/... i see many, many files related to the standard GWT themes.
b. under war/myapp,
-rw-r--r-- 1 10102022 1602597546 1876 Jan 24 16:41 0182DE3CC529E42DA72BBD969A44841E.gwt.rpc
-rw-r--r-- 1 10102022 1602597546 1456 Jan 24 14:09 4F701266A6E52E1E409583EA9AEC39E2.gwt.rpc
-rw-r--r-- 1 10102022 1602597546 1876 Jan 25 08:38 D98FD8FE56B70659E9608109BCF8B3C1.gwt.rpc
-rw-r--r-- 1 10102022 1602597546 43 Dec 16 16:01 clear.cache.gif
drwxr-xr-x 6 10102022 1602597546 204 Jan 25 08:26 gwt
-rw-r--r-- 1 10102022 1602597546 11289 Dec 17 01:33 hosted.html
-rw-r--r-- 1 10102022 1602597546 5232 Jan 25 08:31 photodrop_web_gwt.nocache.js
normally i'd just rely on eclipse build > clean to get rid of the build time artifacts. however, i did that, and i still see WEB-INF/classes full of class files, so i know that clean isn't working.
"war/myapp" is by default GWT's output directory. So as long as you haven't saved any files there manually (you shouldn't), you can delete that directory completely.
As always, make a backup first...
I'm using source control for GWT + GAE, and this ignore file has been working great:
syntax: regexp
^war/myapp$
syntax: regexp
^war/WEB-INF/appengine-generated/datastore-indexes-auto\.xml$
syntax: regexp
^war/WEB-INF/appengine-generated/local_db\.bin