David Heffernan

8 hours ago, Remy Lebeau said:

I'm sure either one will be fast enough for your needs.  Chess isn't very computationally heavy.

I'm baffled. Both of these statements are wrong. 

Delphi is known to be produce very poor and inefficient code. Although I'm not qualified to comment on FPC's code gen. 

Yes. Probably the easiest way is with UnmanagedExports but it can also be done with COM. 

You may need to create a wrapper C# DLL to bridge the interface. 

Looks like your json parsing code is wrong but you didn't show any code. Very hard for us to say what's wrong with your code when we can't see it. Don't be shy. 

42 minutes ago, Sherlock said:

Considering the simple fact that a VPN access point would be exposed to the entire Internet with its sh*tload of malevolent entities out there just waiting to pounce on just another self made "secure" server I would not touch this project with a ten foot pole and oven mits...and a hazmat suit. Just introduce your pal to WireGuard and be done with it.

Exactly. Why reinvent the wheel? And if you absolutely had to implement VPN in Delphi code, then hire an expert that has implemented VPN before.

Using TArray<T> is better because it doesn't have type compatibility issues like this. It makes it easy for different libraries to interop. Because the different libraries don't need to know about each other and declare types in a shared unit. 

This doesn't seem to hang together. Could you provide a complete program to demonstrate the issue. 

I get that if you need to support pre generics versions then TArray<string> is out but if you don't need to support those ancient versions then this for is much preferable. 

49 minutes ago, Remy Lebeau said:

Only a return of -1 (error)

I didn't see that condition documented. I also hadn't realised that some streams can read fewer than the requested bytes but there still could be more left. 

That does seem a strange design choice. If you can wait for at least one byte then surely you can wait for all requested. 

I not advocating the repeat. I think the TryRead is nice. Class helper for TStream would be good. I general TryXXX methods tend to be useful in loads of places. 

Weird repeat loop. I'd do:

repeat

  BytesRead := Stream.Read(Buffer, BufSize);

until BytesRead < BufSize;

It's because the second arg must refer to writeable memory and UniqueString ensures that. A websearch on CreateProcess and UniqueString will yield many discussions of the issue. 

At this point, you probably need to sort it out yourself. You seem to have decided to take an approach that won't work. Given that nobody can make it work, you need to come to that realisation yourself. 

Why are you asking the shell to create a cmd process which in turn creates another process. Use CreateProcess and miss out the cmd middle man. 

6 hours ago, pyscripter said:

If not have you read Installation · pyscripter/python4delphi Wiki (github.com)?

Seems like a good place to start. Why keep asking here if when the answer comes, you don't heed it?

So what is the question? 

WinProcs? Why are you working with code from the 1990s? Where did that code come from? 

Is this a minimal do nothing program? Or is your actual application logic there? 

Likely a defect in your code. You'll need to start debugging. 

20 minutes ago, A.M. Hoornweg said:

But still, replacing "double" by "currency" in OP's example produces the expected result in both 32 and 64 bit mode.

There will be other calculations where that isn't the case

Floating point can be tested for exactness too. 

Your idea of doing floating point calcs and then rounding to 4dp before equality testing is still subject to issues. If there are differences after the floating point calc, then the round to 4dp could fall on different sides of the rounding boundary. 

Always in these discussions there needs to be more specifics of the calcs involved. 

2 hours ago, A.M. Hoornweg said:

One would only do this if one wants to convert floating point numbers to fixed point numbers. Fixed point numbers can be compared with exactness and there are use cases for that. 

 

 

 

 

 

Why would you be calling power and then truncating to 4dp and comparing for exactness? 

1 hour ago, A.M. Hoornweg said:

functions like "power" return a double or extended. Prior to comparing the results of such functions, store them in currencies.

Seems like bad advice. Why would you do this? 

Generics in 2010 were super bugged but generics is irrelevant for a port. Trying to find versions of all libraries that work with 2010 could be tricky. I see no reason in doing multiple ports here. 

3 hours ago, dummzeuch said:

Since as the last step he does an actual comparison between the input string and the string "found" by the hash function(*1), it should work with any input string.

This is the part I didn't watch, but yeah, that makes so much more sense now! 

10 minutes ago, Sherlock said:

This is a highly specialized subject and neither my job nor my personal interests got me all to involved in this area of computer science. So as a layman, if I understand this correctly, he'll have to go back to the drawing board, as soon as he discovers characters are now UTF8, UTF16 or even UTF32, because his finely tuned algorithm is designed for single byte characters. Or is it as easy as switching data types?

He's probably using UTF-8 

It's a sign from above