Does it signify latest commit OR latest release OR latest tag ?
I tried looking for answer in bower docs.
Bower is using semantic versioning (semver) for its version numbers.
The asterisk (*) is used for X-Ranges, which are defined as (quoted from node-semver):
X-Ranges
Any of X, x, or * may be used to "stand in" for one of the numeric values in the [major, minor, patch] tuple.
* := >=0.0.0 (Any version satisfies)
1.x := >=1.0.0 <2.0.0 (Matching major version)
1.2.x := >=1.2.0 <1.3.0 (Matching major and minor versions)
A partial version range is treated as an X-Range, so the special character is in fact optional.
"" (empty string) := * := >=0.0.0
1 := 1.x.x := >=1.0.0 <2.0.0
1.2 := 1.2.x := >=1.2.0 <1.3.0
It's a wildcard character. Very common in Computer Science:
http://en.wikipedia.org/wiki/Wildcard_character
Related
Is there a built-in way to compare two strings representing paths in Inno Setup Pascal? If not with one function, then perhaps via some normalisation of the path.
Naively comparing strings is obviously not correct, even if we ignore case with SameText() (as per the Windows rules).
As a minimum, correct comparison must
Treat \ and / as identical
Ignore multiple separators like \\ (theat them as one, like the OS)
Ignore trailing separators (to compare directory paths correctly, for which it is mainly needed)
Resolve paths (foo\..\bar equals bar, at least if foo exists)
etc. (rules are well known)
Not require the paths actually exist in the file system.
Resolving absolute vs. relative paths is a bonus, but it requires specifying the current path. Perhaps CWD is OK, but I'm not sure Inno accepts relative installation paths anyway.
This must be a fairly common task for an installer, but I'm surprised not to find an easy yet correct solution...
Combine ExpandFileName, AddBackslash and SameText:
function SamePath(P1, P2: string): Boolean;
begin
P1 := AddBackslash(ExpandFileName(P1));
P2 := AddBackslash(ExpandFileName(P2));
Result := SameText(P1, P2);
end;
The ExpandFileName:
Converts / to \.
Normalizes a sequence of any slashes to one backslash (except for leading backslashes in UNC paths).
Resolves relative paths.
The AddBackslash takes care of ignoring the trailing separators.
Tests:
procedure TestSamePath(P: string);
begin
if not SamePath(P, 'C:\my\path\MyProg.exe') then
RaiseException('Test failed: ' + P);
end;
function InitializeSetup(): Boolean;
begin
TestSamePath('C:\my\path\MyProg.exe');
TestSamePath('C:\my\path\MYPROG.exe');
TestSamePath('C:\my\path\\MyProg.exe');
TestSamePath('C:/my/path/MyProg.exe');
TestSamePath('C:\my/path//MyProg.exe');
TestSamePath('C:\my\path\MyProg.exe\');
TestSamePath('C:\my\..\my\path\MyProg.exe');
SetCurrentDir('C:\');
TestSamePath('\my\path\MyProg.exe');
TestSamePath('my\path\MyProg.exe');
SetCurrentDir('C:\my');
TestSamePath('path\MyProg.exe');
TestSamePath('.\path\MyProg.exe');
Result := True;
end;
I've just stared looking at the Delphi Encryption Compendium (I used GetIt to install v6.3 in Delphi 10.4.2)
Here is a simple procedure I have used to calc a File Hash
var
HASH : THash_SHA3_384;
s : rawbytestring;
begin
try
HASH := THash_SHA3_384.Create;
HASH.Init;
s := HASH.CalcFile(edFilename.Text,Tformat_HEX);
EdHashedFile.Text := s;
hash.Done;
finally
HASH.Free;
end;
end;
The resulting hash agrees with various online resources that calc a SHA3_384.
However a message box is displayed when it's doing the calc.
"Absorb: number of bits mod 8 <> 0 or squeezing active. Bits:0, Squeezing: True."
Don't know if it's important ?
if it is what do I do about it ?
if it isn't how do I supress it ?
Many thanks
Wanted to check with you experts if there are any drawbacks in this funtion. Will it work properly on the various Windows OS ? I am using Delphi Seattle (32 and 64 bit exe's). I am using this instead of Findfirst for its speed.
function GetFileDetailsFromAttr(pFileName:WideString):int64;
var
wfad: TWin32FileAttributeData;
wSize:LARGE_INTEGER ;
begin
Result:=0 ;
if not GetFileAttributesEx(pwidechar(pFileName), GetFileExInfoStandard,#wfad) then
exit;
wSize.HighPart:=wfad.nFileSizeHigh ;
wSize.LowPart:=wfad.nFileSizeLow ;
result:=wsize.QuadPart ;
end;
The typical googled samples shown with this command does not work for filesize > 9GB
function GetFileAttributesEx():Int64 using
begin
...
result:=((&wfad.nFileSizeHigh) or (&wfad.nFileSizeLow))
Code with variant record is correct.
But this code
result:=((&wfad.nFileSizeHigh) or (&wfad.nFileSizeLow))
is just wrong, result cannot overcome 32-bit border
Code from link in comment
result := Int64(info.nFileSizeLow) or Int64(info.nFileSizeHigh shl 32);
is wrong because it does not account how compiler works with 32 and 64-bit values. Look at the next example showing how to treat this situation properly (for value d, e):
var
a, b: DWord;
c, d, e: Int64;
wSize:LARGE_INTEGER ;
begin
a := 1;
b := 1;
c := Int64(a) or Int64(b shl 32);
d := Int64(a) or Int64(b) shl 32;
wSize.LowPart := a;
wSize.HighPart := b;
e := wsize.QuadPart;
Caption := Format('$%x $%x $%x', [c, d, e]);
Note that in the expression for c 32-bit value is shifted by 32 bits left and looses set bit, then zero transforms to 64-bit.
Unbound to how you get the filesize: it would even be faster if you'd use a type (manual) that exists for ~25 years already to assign the filesize directly to the function's result instead of using an intermediate variable:
Int64Rec(result).Hi:= wfad.nFileSizeHigh;
Int64Rec(result).Lo:= wfad.nFileSizeLow;
end;
In case this isn't obvious to anyone here's what the compilation looks like:
Above: the intermediate variable w: LARGE_INTEGER first gets assigned the two 32bit parts and then is assigned itself to the function's result. Cost: 10 instructions.
Above: the record Int64Rec is used to cast the function's result and assign both 32bit parts directly, without the need of any other variable. Cost: 6 instructions.
Environment used: Delphi 7.0 (Build 8.1), compiler version 15.0, Win32 executable, code optimization: on.
The following code which attempts to convert a value well beyond the double precision range
StrToFloat('1e99999999')
correctly reports an incorrect floating point value in Delphi 10.2r3 with the Windows 32 bits compiler, but when compiled with the Window 64 bits compiler, it silently returns a 0 (zero).
Is there a way to have StrToFloat report an error when the floating point value is incorrect?
I have tried TArithmeticException.exOverflow, but this has no effect in that case.
I also tried TArithmeticException.exPrecision but it triggers in many usual approximation cases (f.i. it triggers when converting '1e9').
Issue was noticed with Delphi 10.2 update 3
addendum: to workaround the issue, I have started a clean-room alternative implementation of string to double conversion, initial version with tests can be found in dwscript commit 2ba1d4a
This is a defect that is present in all versions of Delphi that use the PUREPASCAL version of StrToFloat. That maps through to InternalTextToExtended which reads the exponent like this:
function ReadExponent: SmallInt;
var
LSign: SmallInt;
begin
LSign := ReadSign();
Result := 0;
while LCurrChar.IsDigit do
begin
Result := Result * 10;
Result := Result + Ord(LCurrChar) - Ord('0');
NextChar();
end;
if Result > CMaxExponent then
Result := CMaxExponent;
Result := Result * LSign;
end;
The problem is the location of
if Result > CMaxExponent then
This test is meant to be inside the loop, and in the asm x86 version of this code it is. As coded above, with the max exponent test outside the loop, the 16 bit signed integer result value is too small for your exponent of 99999999. As the exponent is read, the value in Result overflows, and becomes negative. So for your example it turns out that an exponent of -7937 is used rather than 99999999. Naturally this leads to a value of zero.
This is a clear bug and I have submitted a bug report: RSP-20333.
As for how to get around the problem, I'm not aware of another function in the Delphi RTL that performs this task. So I think you will need to do one of the following:
Roll your own StrToFloat.
Pre-process the string, and handle out of range exponents before they read StrToFloat.
Use one of the functions from the C runtime library that performs the same task.
Finally, I am grateful for you asking this question because I can see that my own program is affected by this defect and so I can now fix it!
Update:
You may also be interested to look at a related bug that I found when investigating: RSP-20334. It might surprise you to realise that, StrToFloat('߀'), when using the PUREPASCAL version of StrToFloat, returns 1936.0. The trick is that the character that is being passed to StrToFloat is a non-Latin digit, in this case U+07C0.
I'm working with IPv6 addresses in the form:
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Internally, I store them in an array:
TIp6Bytes = array [0..15] of Byte;
I need to manipulate the IPv6 addresses in a number of ways including adding, dividing, multiplying etc. Can anyone suggest a good way to do this?
I guess I should have mentioned that I'm working with Delphi 2009
Jes Klinke wrote a bignum unit for Pascal here.
Disclaimer : I have not used this library personally.
After trying many of the suggestions I could not find a library that fulfilled all my needs and were bug free. I searched a little harder and found a relatively new library by Alex Ciobanu which does BigIntegers (and Big Cardinals) seamlessly allowing you to manipulate them in much the same way as you manipulate normal Integers, Cardinals etc.
As well as BigIntegers, the library also provides a number of very useful features. From the readme:
A set of generic collections classes
(List, Dictionary, HashSet, etc).
Date/Time functionality all combined
in a few structures (somehow
equivalent to .NET's DateTime
structure)
Type Support concept that defines a
set of default "support classes" for
each built-in Delphi types (used as
defaults in collections). Custom
"type support" classes can be
registered for your custom data
types.
BigCardinal and BigInteger data types.
Smart pointers in Delphi
The library is being actively developed. In fact, the author fixed a small bug I found within a day.
You can read more about the library on Alex's blog and download DeHL from Google code.
I once wrote a IPv4 and IPv6 conversion unit including a custom variant type for both types of IP addresses.
For instance, with these Variant types, the following example arithmetics and conversions are possible:
procedure TForm1.Button1Click(Sender: TObject);
var
I4: TIPv4;
I6: TIPv6;
V1, V2, V3, V4: Variant;
begin
I4 := StrToIPv4('192.0.2.128');
I6 := IPv4ToIPv6(I4);
V1 := VarIPv6Create('2001:db8:85a3:0:0:8a2e:0370:7334');
V2 := IPv6ToVar(I6);
V3 := V1 - V2;
V4 := V1 or V2;
if V3 < V4 then
Log(V3 + ' is smaller than ' + V4);
if V2.Equals('::ffff:192.0.2.128') or V2.IsZero then
Log('OK');
Log('V1 = ' + V1.AsStringOutwritten);
Log('V2 = ' + V2.AsURL);
Log('V3 = ' + V3.AsStringCompressed);
V4.Follow;
end;
procedure TForm1.Log(const S: String);
begin
Memo.Lines.Add(S);
end;
Custom variant types really are quite powerfull.
I would say that if you can add, you can then use it to subtract, multiply and divide using addition. Should I assume overflows will be simply ignored?
I seem to recall a method of adding bit-oriented variables using XOR. I am looking for that answer now.
Hopefully, this will point you in the right direction. If I can find that XOR code, I will post it for you.
Here it is:
Bitwise operation
Exclusive disjunction is often used for bitwise operations. Examples:
1 xor 1 = 0
1 xor 0 = 1
1110 xor 1001 = 0111 (this is equivalent to addition without carry)
And the reference is:
http://www.absoluteastronomy.com/topics/Exclusive_disjunction