Leaderboard

Just finished a personal project for consuming and creating YAML in Delphi: https://blog.grijjy.com/2019/06/03/a-yaml-library-for-delphi/

If someone is only using Win32 and looks at the last releases there is no point in paying for a subscription that ends up adding more bugs at every turn. My guess is that EMBT found that out and are now turning to 'rentalware'. The 'bump' thing simply delays and staggers 'complainers', eventually you simply won't be able to move Delphi to a new computer unless you subsidize the worst subscription mechanism I've seen (lately). Nothing like getting an email 4-6 months ahead of time padded with useless extras.. Your mileage may vary..

Ah, I see now, they are all hidden in that innocently looking TestParse and TestEmit methods - was expecting to see them more fine grained :) I have some suggestions for some possible low level optimizations (for example eliminating some unnecessary code from function prologues and epilogues caused by usually not raised exceptions but the fact the exception creation code is directly coded into the methods (and in fact is repeated multiple times) - will file a PR.

I totally agree! This is not something one should just accept/dismiss/ignore/whatever. They will only learn, if they are told what they do wrong. This might not even be ill will on their part. And while writing about the issue in the coolest Delphi forum on the planet is... well, cool. It is not "telling them". This should be done directly.

I pay for the subscription and am happy to do so. It's pays for itself. However, when they pull shenanigans like not allowing people who bought a perpetual license to run software they paid for it makes me wonder if this is a company I want to do business with. They better respond in crystal clear fashion that they are making a permanent change to this process to avoid people getting locked out of software they paid for.

One of the things that really annoy me is when applications don't allow me quick access to the file I just saved/exported/created/generated/print to pdf... Examples: Save attachment from Outlook, Save as in Word, Excel - in these cases and many more you need to manually go and locate the file you just saved. Annoying. I'm thinking of redesigning my message for any file created with my application. Right now I have a few different messages using ShowMessage, like 'Action executed.', 'Done', 'File saved.', 'File copied', 'Project summary saved as PDF.' and others - all related to files begin saved - a mess. I'm thinking of having a new message form with button 'Locate file' so that any file generated from my application is accessible right away. How do others deal with this? I'm interested in any suggestions on design, maybe extending my initial idea to something even more useful. Thanks!

Their renewal process is ridiculous. They tack on some $500 "premium" support thing. My subscription should cover "support". Jet brains is the model for how renewals should be handled. Then they try to sell you 24, 36 months. why can't i just go online and renew? i have to deal with a sales guy first.

Mike, I completely agree with you. I also have a subscription but the risk that this kind of behaviour adds to my business is not something I'm prepared to just accept. Given the very poor response by Atanas in his blog post, I'll be looking elsewhere. I wonder how many others will do the same. https://community.idera.com/developer-tools/b/blog/posts/from-the-gm-new-updates-and-changes-to-the-registration-bumps-policy It's a shame really because it could so easily have been resolved. Ignoring the fact that it shouldn't have happened in the first place.

When I'm reading the YAML introduction part of your article, I map its syntax to JSON, and mostly notice the differences, it's so easy to understand this way! And what another GREAT and useful library you (and the grijjy team) have created! As far as I know, this is the first open source Pasal/Delphi library for manipulating YAML.

Yes, my library isn't really suitable for very large files, since it loads the entire file into memory. Since YAML is used a lot for small(ish) files, I wanted to keep it simple. I may add a SAX type interface at some point. Libyaml already provides a such an interface (it is what I used to build the DOM) and it could be adopted to something more Delphi-friendly...

What does the enter key do? Depending on the usual workflow (does the user usually want to view the report? Or does he want to copy or send it somewhere?) one of the other buttons might be a good option. Another frequently required information for further processing is the full file name, so maybe there should be a fourth button to copy it to the clipboard.

Last thing I want to see from an application is a modal dialog telling me that the app just did what I told it to.

While things are already in motion now, I thought it might help to go a bit more public: MMX Needs New Icons – Are You Willing To Help?

Can't argue that... Problem is that expansion to other platforms started as customers request. If we all knew then what we know now, maybe things would play out differently.... on the other hand, maybe not... when you have need to support other platforms and your toolset does not have them, you have to find some that does... when you start moving away, sometimes you may be inclined to move away completely. Also, development team shrinking process happened after expansion to other platforms... Quite unexpectedly, if I may say, because at that point it should have been obvious that more platforms means more work and more work requires more people, not less. We can argue here until the end of the world, but how can you argue anything when actual events (decisions) defy all logic. For all we know, maybe even without additional platforms Windows side would be in similar position as it is now.

But you cannot survive just with legacy! The expenses for maintenance would be copable when development would be steady in cadence with the plattforms. It is a great problem when there is the need for "reaction" in hassle. EMBT have ti build a homogenous platform with one front end (compiler) per language and one back end per platform. The development should be decoupled ( compiler, code gen, runtime, ide).

Maybe somebody at Unity didn't have to ask because there is huge number of Unity Android games with large distributions out there. Google knows what kinds of applications they host and how many don't support 64bit.

In latest roadmap it was newer scheduled for 10.3, but for some 10.3.x update Android 64bit is scheduled for 10.4 AFAIK, this roadmap as far as those compilers are concerned is still valid. When exactly any of those releases will actually hit the road, anyone's guess is as good as mine. macOS 64-bit is needed not just for developing macOS apps, but also internally for iOS development toolchain and supporting iOS 11 and iOS 12 simulators. Last year, there was public beta for Delphi developers on active subscription that allowed publishing Android applications built with beta on Google Play store. If nothing else similar scenario can be expected for Android 64 bit compiler. I know this is far from ideal... but... To be on the safe side... anyone should prepare for the worst and release any major updates before August deadline...

But the next version of macOS doesn't support it anymore. macOS mojave juust warns when starting 32 bit apps. In this case "only" the distribution in the play store is affected. In macOS the apps will stop working!

It's on the roadmap for 10.4.x (Mid 2019) https://community.idera.com/developer-tools/b/blog/posts/rad-studio-august-2018-roadmap But you're right. It's hard to believe that Emba will deliver on time.

Existing apps will not be not removed until 2021: https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html The August 1, 2019 requirement is for updates and new apps.