DUPLICATEENABLE is old, but since it is something for IDE packages to avoid intersections with user/3rd party packages there is no need for a documentation. I do use it in an IDE package that did use the JCL/JVCL units as well and does another unit with a common name. IIRC I did mention it related to MonkeyMixer.
I think he argues that documentation is both not needed, but the usage of the directive sometimes is. Which somehow feels like a contradiction to me.
PS2: via Stefan Glienke, an error message that is related to this:
---------------------------
Error
---------------------------
Cannot load package 'Package2.' It contains unit 'Whatever', which is also contained in package 'Package1'.
---------------------------
OK
---------------------------
Windows 10 Creators Update 1703 caused issues with all Delphi programs, libraries and packages because it changed how Windows loads imported DLLs in such a way that it causes performance issues and can crash the debugger.
Delphi 10.2 Tokyo Update 2 fixed this by not producing multiple dll import sections for one DLL anymore.
IDE Fix Pack 6.1 implements that “feature” for all previous Delphi versions (2009-10.1 Berlin) and extends it to not only eliminate duplicate dll imports but also duplicate delay dll imports.
There are also (optional) updates that you can enable with new compiler switches:
Eliminating fwait instructions (but be careful, as they can confuse the debugger)
Optimising calls to virtual methods through interfaces
TFileStream.Create('c:\a.txt', fmCreate or fmShareDenyNone).WriteBuffer(Pointer(TEncoding.UTF8.GetBytes(BigStringVar))^,Length(TEncoding.UTF8.GetBytes(BigStringVar)))
They all work form the debug inspector, but they do leak memory. See comments below.
Interesting stuff; I wonder if there is a case for it as well:
The Cluster HAT interfaces a (Controller) Raspberry Pi A+/B+/2/3 with 4 Raspberry Pi Zeros Configured to use USB Gadget mode, it is an ideal tool for teaching, testing or simulating small scale clusters.
Maybe for my LoT (LAN of Things): having multiple (even many) local LANs some each with their section of LoT equipment nicely separated and partially being able to talk to some of the other LANs or part of the outside world.
Some links that might help me getting this set up:
So it was in the Drivers unit, but also easy to incorporate in your own unit by linking the .OBJ file and providing the external declaration in any unit.
The Drivers unit is very independent of the rest of Turbo Vision: it uses the Objects unit (which most projects use as the System unit at ~500 lines of code provided very little functionality by itself).
For the diskette based install, the .TPU files were on the standard disks and the sources for both RTL and Turbo Vision on separate disks, but anyone would install them as they provided a lot of insight. The CD-ROM has them all on the same medium (both as installers and unpacked in the BP directory).
I just checked Turbo Pascal 6.0 (that I did have a VM for) which has them in the same way.
I hope I’m not alone on this but I find the cURL documentation hard to follow and short on examples.
My goal was to mimic some HTTP XML posting traffic a server gets from IoT devices. Google Chrome Postman (or Postman REST Client) reproduction is very easy and will send.
TL;DR
ensure you have an empty --header "Content-Type:" header: this ensures that cURL doesn’t add one and does not mess on how the content is being transferred.
use the --data or --data-binary command with an @ to post a file as body.
if you want --write-out then be sure you have a recent cURL version.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This will hang the connection: somehow cURL will never notify the upload is done and the HTTP server keeps waiting. When you put --verbose or --trace-ascii - on the command-line you will see something like this before hanging: * upload completely sent off: 245 out of 245 bytes.
This will automatically add a Content-Length: 245 header and complete the transfer. But it will also add a Content-Type: application/x-www-form-urlencoded header causing the content not being posted as a body.
This will automatically ad a Content-Length: xxx header (way longer than 245) because it converts the request into a Content-Type: multipart/form-data; boundary=------------------------e1c0d47bac806954 one (the hex at the end differs) which is totally unlike what Postman does.
It is also unlike to what the HTTP server accepts.
It turns out that --data-ascii is exactly the same as --data and that --data-binary just skips some new-line conversion when compared to --data or --data-ascii. Contrary to the --data-raw documentation that suggest it is equivalent to --data-binary it seems --data-raw behaves exactly like --data and --data-ascii. Odd.
So these are all stuck with the Content-Type: application/x-www-form-urlencoded and I thought I was running out of options.
It posts exactly the same content as the IoT devices and Postman do.
Phew!
I tried to combine this with the --write-out (a.k.a. -w) option, but for older versions of cURL (I could reproduce with 7.34) that forces cURL back in to Content-Type: application/x-www-form-urlencoded mode so watch your cURL version!
Later I will put more research in chuncked transfer. Links that might help me:
The Wiert Corner - irregular stream of stuff 