Jump to content

ByteJuggler

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

11 Good

Technical Information

  • Delphi-Version
    Delphi 10.2 Tokyo

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ByteJuggler

    How to identify problem remotely

    My first suggestion would also be madExcept. Aside from that, in the task manager (on Win10) you have two options that might help: "Analyze Wait chain" and "Create dump file". The latter will dump the application image. The image may be inspected with e.g. WinDbg. Here's a bunch of tutorials: https://marc.durdin.net/2015/11/windbg-and-delphi-a-collection-of-posts/ And though it's .Net based and a little old this seems interesting: http://alookonthecode.blogspot.com/2012/02/windbg-101a-step-by-step-guide-to.html And this: http://capnbry.net/blog/?p=18
  2. Relatedly and somewhat in the same vein I read an article yesterday about AirBnB and why they're now moving off of React native, basically too much churn and too many landmines, even if it works really well when it works.
  3. We've been using SVN for many years now, no complaints. We're however planning to migrate to Git at some point, and are already using it in parallel with SVN in several ways. It is perhaps worth it to note that from a size efficiency perspective Git is much more efficient than SVN. The total size of a git repo + working copy files (which remember, includes all the branches and the entire history of the project locally) is typically quite a bit smaller than an SVN checkout (which only contains the working copy and a copy of the pristine files of a single branch with no history.) So any history investigation or switching between branches requires a connection to the remote SVN server, whereas Git does not require this and allows complete freedom to switch branches, create new ones and interrogate the histories offline. This is extremely useful when you want to do some types of work where a connection to your central version control system is not available. To also note: It is entirely possible to use both version control systems sort of independently at the same time, by making each ignore the other's folders. This has benefits as it starts making the notion of "I have a local repository that I can work against" apart from "the remote" clearer. E.g. commit whatever you like, in as small baby steps as you like against your own development git repo, and once ready commit to your "mainline" SVN repo. Meanwhile when upstream updates happen you get practice in merging and learning how to do this properly using git. Eventually this sets you up to simply swap the step that commits to SVN to pushing to a remote Git repo instead. It is also possible to keep a git repo as part of your SVN repo, if needed/wanted/useful. For example, we use and keep third party sources in a dedicated third party SVN repository, and in several cases for ease of updating to ("pulling in") the latest version of the open source project and to have access to the history of these projects, the path of least resistance was to actually commit the git repo into our Subversion repo. To update then is simply a case of pulling from the repo on github, checking if the update breaks anything and then commiting both the source changes and the changes to the git repo to subversion. (One more addition: Another department actually also use Bazaar, it works well but I'd not recommend it as it's essentially dead in terms of development, and the plan is to eventually migrate that to git too. For clients we use the Tortoise* tools.)
  4. This is interesting stuff. What produces the above stats? (As background: Back in when XE5 was released we did some evaluation and based on the admittedly somewhat limited testing we did, concluded that mobile support was [at that time] not good enough to risk a project on. I/we have generally however had the impression in recent releases (since let's just say 10.x) that support was plausibly nowadays "good enough" based on generally favourable anecdotal reports by people with production apps in the Google and Apple app stores. We have therefore been considering revisiting and doing another trial and possibly proceeding with a mobile app development soon. However the above puts a slightly more cautionary spin on things. So your report is useful, thanks, and any further comments are highly appreciated.)
  5. ByteJuggler

    Unit testing for server-side assets

    We do various types of tests (which would categorise I suppose amongst others as smoke tests, integration tests, golden master tests and regression tests) which do verify behaviours by back-end/server side assets like views and stored procedures. We do also directly exercise some server side assets directly in some of the automated tests for behaviour and outputs, we probably don't do nearly enough of this. (We do test bootstrap the entire back-end from scratch.) There are SQL based unit testing frameworks/tools/approaches, we don't yet do this, but we probably should. (https://tsqlt.org/ for example.)
  6. ByteJuggler

    Delete Error With Delphi and Access Table

    Yep, that's also going to be wrong! Missed that! 🙂
  7. ByteJuggler

    Delete Error With Delphi and Access Table

    To add to Dany's answer, you should preferably avoid dynamic SQL generation like above. There's a bunch of reasons for this, including SQL injection attacks, and brittleness (which is to say it's prone to breakage and hard to test) and being slower as it makes it makes it hard for the database to optimise for the general case (as it will all else being equally have to parse and prepare an execution plan for each parameter combination presented to it). Instead use parameterized queries where possible or (for suitable back-end databases) stored procedures.
  8. ByteJuggler

    Illegal characters causing problems and can't be found

    It's not going to be Pos(). I'm slightly wondering what's the content of "IllChar?" Unless that's all characters below 32 you may be missing characters due to them being not in your array, possibly causing trouble. Really, instead of having an array of "Ill characters" and stepping through this repeatedly calling Pos(), I'd probably just step through every character in "ThePN" and check for Char(ThePN) < #32 as all characters below point 32 is non-printable. (This is also slightly more efficient, but that is not any major concern here so I digress.) (Aside, my sympathies. I bled a lot with Paradox and the BDE back in the day. Still have some remnants of the BDE here and there, soon to be all gone... )
  9. ByteJuggler

    Speed up reading multiple text files

    I suspect you're running into something which had me gnashing my teeth in the past... TStringList isn't the most predictable in terms of performance particularly when you set the Sorted property to True ahead of populating it... When you set the Sorted property to True on a TStringList, the stringlist must (of course) maintain the ordering when new strings are Added. To do this, it must determine where to insert the line being added. And to do this it uses a binary search. See: TStringList.AddObject(), and which calls TStringList.Find() before potentially calling InsertItem(). Then see TStringList.Find(). This results in an O(n.log n) time complexity just for reading n lines of text from a single file as opposed to just O(n) without. This is maybe OK, however there's more. TStringList's name and methods implies that it's a list structure when in fact it's not. The underlying datastructure is a contiguous array of strings. This means the actual insert becomes increasingly expensive as the TStringList grows because the Insertions are effectively O(n), even if it uses an fairly efficient copy. See TStringList.InsertItem(). While System.Move() is a pretty quick "block copy" it nevertheless will be increasing as the number of items in the stringlist grows. In a normal linked list the cost of the actual insert once you've found where you want to insert is O(1). Then there's also the growing aspect adding some overhead, e.g. the underlying array have to be enlarged/grown when the number of actual lines matches the capacity of the array and another is inserted. (One might suspect that all this copying and growing may be potentially doing unpleasant things to CPU caches and so on, which also won't be helping performance.) So, the point of this little diatribe is that TStringList's performance behaviour can be a bit different to what one might expect, and you should therefore act accordingly. Given that your lists are already sorted, you should load the data into multiple stringlists without duplicate checking or sorting on which will avoid most of the needless overheads. And then, write a routine to multi-way merge these into a final list. (If you want to get fancy, maybe using a min heap given the varying lengths of the input?) Or, use something else as others have suggested, perhaps. (Maybe we should write a TFastStringList, and while we're at it, make it interfaced, so I can return IFastStringList instances and have them reference counted etc... I digress.)
  10. ByteJuggler

    dotNet framework 4.5 required for Delphi 10.3 Rio

    In case anyone's interested, the same issue reported/discussed here: https://bitbucket.org/sglienke/spring4d/issues/308/buildexe-does-not-build-delphi-103-rio
  11. ByteJuggler

    dotNet framework 4.5 required for Delphi 10.3 Rio

    Also here: https://quality.embarcadero.com/browse/RSP-21670
  12. ByteJuggler

    Web dashboard application

    Hi, To briefly answer you: We're running a production solution for about 18 months now. As of this writing the solution is very stable. I've had continuous up-times in excess of a month. Usually the system is restarted etc not because of some unknown UniGUI problem, but because we've updated the software. And the rare problems we've had has in almost every case turned out to be mistakes in our code, and/or pre-existing problems in code we've reused that have come to light due to UniGUI's multi-session/mutli-user/multi-threaded nature. As for support: The couple of times I've had questions or problems I've mostly been helped pretty rapidly. I cannot complain. With actual suspected bugs, the usual considerations apply as for any software, which is to say if you can give the UniGUI guys a reproducible test case then you tend to get helped much more quickly and eagerly than if you do not. Hope that helps.
  13. ByteJuggler

    Error insight in Rio

    I've searched and it's been reported yesterday already: https://quality.embarcadero.com/browse/RSP-21643
  14. ByteJuggler

    Error insight in Rio

    Looks like the syntax checker/highlighter doesn't support the new inline var syntax properly. See if it's been reported yet and if not report it at quality.embarcadero.com
  15. ByteJuggler

    Migration DbExpress to Firedac , better way ?

    I've used refind to mostly convert an application from BDE to FireDAC. We still also have some modules using DBExpress which remains to be done. I was planning on adapting some of the BDE scripts for this purpose. I have been toying with writing a blog post or something to document some of the lessons learnt. If I find some time I'll have a little look at our DBX modules and whether I can get something going quickly and post so advice for you here. One thing I would say is that I would not advise you to change the structure/architecture of your application when you do this translation. Purely stick the changing the classes over and making any adjustments necessary as a consequence. You can always change/refactor the structure later if you want to.
×