Leaderboard

When using the </> button in the text editor, it always defaults to HTML syntax highlighting. Can this be changed to Pascal by default?

https://sdtimes.com/softwaredev/industry-watch-the-developer-transformation/

I just published a blog article about how to write clean code, and also high-performance code. http://blog.synopse.info/post/2018/11/12/EKON-22-Slides-and-Code These were sessions at latest EKON 22 conference in Germany: we were more than 140 Delphi developers! Hope this helps!

Site is now https. 🙂

Works great!

I wrote a simple & elegant calculator for Android using Delphi Tokyo 10.2.3 and released the source code on GitHub: https://github.com/bLightZP/ElegantCalculator This sample demonstrates basic scalable Android UI, taking screen scale into account. I wrote a basic string math formula parser since I couldn't find anything free that would compile for Android. You can check out the compiled Elegant Calculator on the google play store: https://play.google.com/store/apps/details?id=com.inmatrix.ElegantCalculator

But will this be the right solution? These types have different sizes (tested for Win32): if SizeOf(Pointer) <> SizeOf(TWndMethod) then ShowMessage('No way.'); // 4 <> 8 I tried this: var i64: UInt64; ... i64 := fld.GetValue(TabSet1).AsUInt64; proc := TWndMethod(i64); But get Exception EInvalidCast 'Invalid class typecast' for GetValue.AsUInt64. Update. I did it like this: var p: Pointer; ... p := fld.GetValue(TabSet1).GetReferenceToRawData; proc := TWndMethod(p^); Thanks @Lars Fosdal for the hint!

what if you first extract it as a pointer, and then cast the pointer to TWndMethod?

Perhaps the other way around: let strong typing be OFF by default (backward compatible) but enable it to ON for new code requiring it. 🙂 About Unicode/AnsiString it was a requirement due to another breaking change.

An easy way to implement formulas is to rely on FireDAC expressions. It is very powerful (I built a simple spreadsheet-like application with very small effort!) Sincerely

Hi, there was no demo showcasing how to handle multipart/form-data on the server side with MARS. But, since a couple of minutes, there is! 🙂 Have a look here: https://github.com/andrea-magni/MARS/tree/master/Demos/MultipartFormData Build and run the demo, then use a browser to navigate http://localhost:8080/rest/default/helloworld/1 to have a simple HTML page with a multipart/form-data form. The last part of the URL can be 1, 2, 3 or 4. On the server side, you will notice four methods marked with the POST attribute, to handle the 4 requests. It is actually the same http request served through 4 different available ways in MARS (see here: https://github.com/andrea-magni/MARS/blob/master/Demos/MultipartFormData/Server.Resources.pas😞 1) ask the library to inject a dynamic array of TFormParam: [FormParams] AParams: TArray<TFormParam> Implementation of the REST method loops on that array to provide a result value; 2) target specific params (by name) using the following syntax: [FormParam('json')] AJSON: TFormParam; [FormParam('image')] AImage: TFormParam; FormParam is defined in MARS.Core.Utils and can represent both simple parameters and files; 3) push a bit more and ask for automatic deserialization of the first parameter into a TJSONObject. The methods has these arguments defined: [FormParam('json'), Consumes(TMediaType.Application_JSON)] AJSON: TJSONObject; [FormParam('image')] AImage: TFormParam; Note the type of the first argument is no more TFormParam but TJSONObject 4) last version takes advantage of JSON to record serialization (built-in with MARS): [FormParam('json'), Consumes(TMediaType.Application_JSON)] ARecord: TPerson; [FormParam('image')] AImage: TFormParam; All these four variations have a TMyResult record as return value. This record gets automatically serialized to JSON by the library. You should be able to build clients in any language (I tested with Postman and the HTML page, using Chrome). Let me know if everything is clear and working. Sincerely, Andrea

More data, some old, some new. Firstly, two very old CPUs (the oldest I could find in the company): This pattern repeats very consistently every 64 bytes (size of cache line): Very interesting pattern but the worst thing is the terrible slowdown when memory access crosses the cache line. Similar data can be seen in a Xeon of a similar age: For a moment I thought I used the wrong data files - that's how similar both results are! And now a suprise! A very modern & fast AMD Ryzen Threadripper: Wow! The cache line is only 32 bytes and memory access across that line is still slow! Interestingly, accessing 4-aligned 8-byte data in 64-bits works great even when straddling cache line. MemAtomic proves that cache line is only 32-byte: 1: 2: 15 31 47 63 79 95 111 127 4: 13 14 15 29 30 31 45 46 47 61 62 63 77 78 79 93 94 95 109 110 111 125 126 127 8: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 No wonder Intel is still a king for non-optimized software!

It will not get them more customers just because it's 64bit and runs out of memory later because all the instabilities and the compiler getting into a bad state because of compile errors or what not crashing the IDE will still be there as will the poor code tooling. Going the easy/cheap way every time is what puts Delphi and the IDE into the current situation of constantly having to react to external factors and tinker around edges. Sometimes I really have a hard time believing that or you just avoid certain features or have subconsciously developed a certain habit to do things differently. Or you just use it to prepare demos.