Is there a way to find out what the number is that the build process assigns to the * when I have the assembly version set to something like 1.0.0.*?
I've been looking at the "EnvDTE" namespace in the macros, but haven't been able to find anything useful.
According to MSDN if you have a version number in the form of
major.minor.build.revision
and specify
1 . 0 . * . *
then
major = 1
minor = 0
build = build to be equal to the number of days since January 1, 2000 local time
revision = revision to be equal to the number of seconds since midnight local timeivided by 2
Related
I've got sports data that I've imported from an online source via a .xlsx file. Each observation is a penalty in an NFL (American football) game. In order to later merge this with another dataset, I need to have certain variables/values that match up between the two files. I'm hitting an issue with one variable, however.
In the main dataset in question (the penalty dataset originally mentioned), my ultimate goal is to create two variables, Minute and Second, that are of type byte and format %8.0g. This would make them perfectly correspond with the respective variables in the destination dataset. I have the required information available, which is the time remaining in the given quarter of the NFL game, but it's stored in a strange way, and I'm having trouble converting things.
The data is stored in a variable called Time. Visibly, the data looks fine as imported from the original .xlsx file. For example, the first observation reads "12:21", indicating that there are 12 minutes and 21 seconds left in the quarter. When importing from the .xlsx sheet, however, Stata assumes that the variable Time is a date/time variable measured in hh:mm, and thus assigns it a type of double and a format of %tchh:MM.
In the end, I don't really care about correctly formatting this Time variable, but I need to somehow make this match the required Minute and Second columns of the destination file. I've tried several different approaches, but so far nothing seems to work.
If Stata is misreading minutes and seconds as hours and minutes, and also (as it does) storing date-times in milliseconds, then it is off by a factor of 60 (minutes/hour) x 1000 (ms/s) = 60000. So, consider
. clear
. set obs 1
number of observations (_N) was 0, now 1
. gen double wrong = clock("1jan1960 12:21:00", "DMY hms")
. format wrong %tchh:MM
. clonevar alsowrong = wrong
. format alsowrong %15.0f
. list
+------------------+
| wrong alsowr~g |
|------------------|
1. | 12:21 44460000 |
+------------------+
. gen right = wrong/60000
. gen byte Minute = floor(right/60)
. gen byte Second = mod(right, 60)
. list
+--------------------------------------------+
| wrong alsowr~g right Minute Second |
|--------------------------------------------|
1. | 12:21 44460000 741 12 21 |
+--------------------------------------------+
I can't comment easily on your import, as neither imported file nor exact import code are given as examples.
EDIT Another way to do it:
. gen alsoright = string(wrong, "%tchh:MM")
. gen minute = real(substr(alsoright, 1, strpos(alsoright, ":") - 1))
. gen second = real(substr(alsoright, strpos(alsoright, ":") + 1, .))
. l alsoright minute second
+----------------------------+
| alsori~t minute second |
|----------------------------|
1. | 12:21 12 21 |
+----------------------------+
For [2018]EME Conformance Tests - v20171221
WidevineH264MultiMediaKeySession
I find this test for 8 times Initialize & 8 times GenerateKeyRequest for Key
So I can get 8 times provisioning message for key license.
But the Test's success situation is as follows:
In emeTest-20171221164539.js
runner.checkGE(video.currentTime, 15, 'currentTime');
runner.checkEq(testEmeHandler.keySessions.length, 8,
'keySessionCount'); runner.checkEq(testEmeHandler.keyCount, 128,
'keyCount');
Current Time great than 15 sec is pass.
Session count is 8 is the same.
But Keycount=128, I can't pass it. Only 8 time generateRequest.
I can't get 128 keys for 16 keys in one session for this test.
and I find in emeManager-20171221164539.js
onKeyStatusesChange() { self.keyCount++; }
So I assume I need to get 128 AddKey() for onKeyStatusesChange()
But Now I have no idea to solve it.
I am using Cobalt RC 11.119147. and Widevine CDM 3.2.1
Is this version RC11 is support for multiKeyseeion >
Is there any Sample to process this Test for Widevine CDM process ?
Why need 8 times Init with 8 times GenerateRequest ?
why not one init and 8 times GenerateRequest ?
does Init need to clean Something ? or We need 8 CDM instance ? Each one have only one session ?
We recently fixed a bug in the test, is it possible for you to try again to see if you can still reproduce the above mentioned issue.
I've looked at this answer, that states that this problem might happen when the description files for the negative images is created with tools different from Opencv_createSamples, but this is not the case here.
The break occurs somewhere between the fourth and the seventh stage. In another post, someone suggested that this message means the classifier cannot be improved, but with only 5 stages, it is at least odd.
For training, I´m using numPos=800 while the vec file (60x60 px) contains 1200 positive samples. Moreover, I´m using 1491 negative samples(30x30 px). I´ve made all kinds of changes in the parameters, and none of them worked.
For the last attempt I used the parameters as follows:
cascadeDirName: 15stages
vecFileName: pos.vec
bgFileName: neg_dir.txt
numPos: 800
numNeg: 1491
numStages: 15
precalcValBufSize[Mb] : 1024
precalcIdxBufSize[Mb] : 1024
acceptanceRatioBreakValue : -1
stageType: BOOST
featureType: HAAR
sampleWidth: 60
sampleHeight: 60
boostType: GAB
minHitRate: 0.9999
maxFalseAlarmRate: 0.3
weightTrimRate: 0.9
maxDepth: 1
maxWeakCount: 100
mode: ALL
I had the same problem, after making a big research, I've got the best parameters that should be supplied to the opencv_traincascade.
If you are using a rectangular image, specify -w 24 -h 24, In addition make sure you have more positives than negatives and set -maxFalseAlarmRate 0.5.
That worked for me very well, hope it is useful for you too.
i also have this problem before. but after i reduce the param [maxFalseAlarmRate] ,like set small than 0.1 , it works ok. hope this have some help.
In Lua 5.2.1, I tried to generate a random number with
num = math.random(9)
However, every time I run my program:
num = math.random(9)
print("The generated number is "..num..".")
I get the same number.
brendan#osiris:~$ lua number
The generated number is 8.
brendan#osiris:~$ lua number
The generated number is 8.
brendan#osiris:~$ lua number
The generated number is 8.
This is frustrating, because everytime I try to generate a new number and restart the program, I get the same sequence.
Is there a different way of generating a number?
Also, I've looked into
math.randomseed(os.time())
but I don't really get it. If this is indeed the solution could you explain how it works, what it does, and what number I'd get?
Thx,
Brendan
This is not particular to Lua. Pseudorandom generators usually work like that: they need a seed to start and the sequence they generate is not really random, but actually deterministic given a seed. This is a good thing for debugging but for production you need to alter the seed in a "random" way. An easy and typical way of doing that is to use the time to set the seed once at the start of the program.
In Lua this is the expected output. You are not guranteed to get different sequences across different sessions.
However, any subsequent calls to math.random will generate a new number:
>> lua
> =math.random(9)
1
>> lua
> =math.random(9)
1
>> lua
> =math.random(9)
1
> =math.random(9)
6
> =math.random(9)
2
math.randomseed() will change which sequence is replayed. If you set math.randomseed(3) for example, you will always get the same sequence, just like above:
>> lua
> math.randomseed(3)
> =math.random(9)
1
> =math.random(9)
2
> =math.random(9)
3
>> lua
> math.randomseed(3)
> =math.random(9)
1
> =math.random(9)
2
> =math.random(9)
3
If you however set math.randomseed() to a unique value each run, for example os.time(), you will ofcourse get an unique sequence each time.
First, you have to call 'math.randomseed()'
'Why?'
Because Lua generates pseudo random numbers.
--One of the best seeds for 'math.randomseed()' is the time.
So, you'll first write:
math.randomseed(os.time())
After this,
num = math.random(9)
print("The generated number is "..num..".")
However, there is a bug on Windows. Then if you just write 'num = math.random(9)' the generated number will be the same for 1 hour, i think.
'So how can I resolve this?'
It's easy, you need to do a for loop.
for n = 0, 5 do
num = math.random(9)
end
So, in Windows, the final code would be:
math.randomseed(os.time())
for n = 0, 5 do
num = math.random(9)
end
print("The generated number is "..num..".")
OBS: If 'for n = 0, 5 do' does not work perfectly, then replace 5 with 10.
os.time() in Luaj returns time in milliseconds, but according to lua documentation, it should return time in seconds.
Is this a bug in Luaj?
And Can you suggest a workaround that will work with Luaj(for java) and real Lua(c/c++)? because i have to use the same lua source for both applications.(cant simply divide it with 1000, as they both have return different time scale)
example in my lua file:
local start = os.time()
while(true) do
print(os.time() - start)
end
in c++ , i received output:
1
1
1
...(1 seconds passed)
2
2
2
in java (using Luaj), i got:
1
...(terminate in eclipse as fast as my finger can)
659
659
659
659
fyi, i try this on windows
Yes there's a bug in luaj.
The implementation just returns System.currentTimeMillis() when you call os.time(). It should really return something like (long)(System.currentTimeMillis()/1000.)
It's also worth pointing out that the os.date and os.time handling in luaj is almost completely missing. I would recommend that you assume that they've not been implemented yet.
Lua manual about os.time():
The returned value is a number, whose meaning depends on your system. In POSIX, Windows, and some other systems, this number counts the number of seconds since some given start time (the "epoch"). In other systems, the meaning is not specified, and the number returned by time can be used only as an argument to os.date and os.difftime.
So, any Lua implementation could freely change the meaning of os.time() value.
It appears like you've already confirmed that it's a bug in LuaJ; as for the workaround you can replace os.time() with your own version:
if (runningunderluaj) then
local ostime = os.time
os.time = function(...) return ostime(...)/1000 end
end
where runningunderluaj can check for some global variable that is only set under luaj. If that's not available, you can probably come up with your own check by comparing the results from calls to os.clock and os.time that measure time difference:
local s = os.clock()
local t = os.time()
while true do
if os.clock()-s > 0.1 then break end
end
-- (at least) 100ms has passed
local runningunderluaj = os.time() - t > 1
Note: It's possible that os.clock() is "broken" as well. I don't have access to luaj to test this...
In luaj-3.0-beta2, this has been fixed to return time in seconds.
This was a bug in all versions of luaj up to and including luaj-3.0-beta1.