Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ByteJuggler

  1. ByteJuggler

    Creating a "pull request" for jvcl

    Ah, I'm sorry you feel a bit burned. 😞 Out of interest and for what it's worth: I had a look at what your patch is for, it seem to me from the StackOverflow discussion that the issue your patch works around is only present in a specific build of Windows and that's there's a fix for it [in Windows] since about a month ago? The maintainers need to respond and state whether this is the case, but it might be that they don't really want to fix OS bugs in the JVCL, an understandable position to take. (Aside, we maintain our own versions of some open source libraries as well as Delphi Source because of similar reasons, being that long ago issues remain unpatched in the official source whether due to lack of interest from the maintainers or lack of demonstrability/completeness/quality/testing or whatever of the issue and/or patch on our end. Sometimes just the way it goes. πŸ™‚ )
  2. ByteJuggler

    Creating a "pull request" for jvcl

    Yes. One of the nice things of open source is that if a project isn't well maintained you can simply "run with it" yourself. Your fork may well eventually become the de-facto official version, if it should turn out that your version of the code in question ends up consistently better maintained and up to date than the original. To be clear: I'm not casting shade at the JCL/JVCL project per se here, just agreeing with your point that there's nothing wrong with maintaining your own fork and the consequences that may have, and that this is sometimes no bad thing. πŸ™‚ Also as a minor digression, while this does obviously require some necessary conceptual branching understanding and how this is handled in git, it's reasonbly easy to create a new feature branch from a master branch even after the fact to fix the "problem" above with multiple pull requests. And it's also of course possible to just roll both sets of changes into a single new pull request. Given that there's some issues with the existing pull request in terms of supported versions (it seems, perhaps?), it seems this may be a fair course of action.
  3. ByteJuggler

    Creating a "pull request" for jvcl

    Especially with new contributors to open source (but also in general) it's usually advisable in the interests of friendly cooperation to exercise some patience and politeness and give contributors some friendly feedback about their pull requests if they should accidentally miss this or any other type of requirement that change requests should comply with (and to do so in the context where the pull request was submitted.) If the JCL/JVCL maintainers are not giving at least this feedback to people trying to contribute then that's rather a shame. 😞
  4. ByteJuggler

    Creating a "pull request" for jvcl

    Nice. Now nosy people like myself can also go have an, er, nosy around to see what you've done and even grab the change if I want it. πŸ™‚
  5. ByteJuggler

    Creating a "pull request" for jvcl

    Without wanting to be polemical and for the sake of anyone else reading this thread: As written that doesn't make sense, I assume you must've meant to write: "You need to commit the change to the local repository, then push it to your remote fork, then create a "pull" request in github" against/from your remote fork.
  6. ByteJuggler

    Creating a "pull request" for jvcl

    Just to emphasise: Yes -- they must have somewhere to pull from that's accessible, which is kind of the point of github (So you're not too stupid to use git after all! )
  7. ByteJuggler

    Creating a "pull request" for jvcl

    Guys, while pulling updates from a remote repo is part of git (e.g. git pull from the command line for example), a "pull request" is not something intrinsically part of git, but something that github institutes, or that we agree between ourselves as developers. It literally is saying to someone else "Please {git} pull from me as I've got something you might want to review/use." It follows that in order for someone else to "pull" changes from you, that you must have some accessible place for them to pull from. Obviously users on the internet won't have access to your local repo on your developer PC, so they cannot pull from there. Nor would you normally be able to push to their repo (or their github repo) if that is where you originally pulled from (unless you're one of the project administrators/owners of course.) There therefore needs to some other repo, that must belong to you and is accessible so that someone else can pull from, that you can also first push to. (Just like there needs to be a shared SVN server, say, if you want another dev to get some changes you've made and are using subversion.) And this is where github comes in. It provides an easy to access place where you can fork and create your own remote repositories (from others) that are therefore just as easily accessible by others too. All that background is to help you understand the following: The normal process for working on github, if you want to contribute changes, is to 1.) Fork the repo of the project you want to contribute to in your github account. This creates a cheap remote repo (think "my own SVN server at github" if that helps) that belongs to you, than you can push to. 2.) Clone this fork (your own copy of this github repo) to your local PC. 3.) Do your work, commit locally. Once totally happy, git push, which obviously goes to your own remote repo (from the fork.) 4.) Now you're a few revisions ahead of the original repo, and you can then tell the original upstream repo maintainers that you'd like them to pull from your repo as you've got changes to fix some issue or whatever. In github, you do this by simply clicking "New Pull request" button in github. Hope that helps! Edit: By the by, if you've previously pulled from someone else's project directly, made some changes and now want to push this somewhere else, it's quite easy to fork the project "after the fact" and then tell git/update that "remote"/"upstream" is now else, to e.g "push" to your fork instead. (It's also possible to have multiple remotes if you want, but I digress...)
  8. Thanks, Correct yes. That's what I read/was referring to. And my apologies, I shouldn't have used "won't" in my post, should've been "can't". As it happens I see I've been prompted with an OS update/upgrade notice last night on said phone (which will upgrade to Android Pie) so hopefully the problem will be gone later today! πŸ™‚
  9. I have recently (last couple of days) been (re)-introduced to the wonderful world of (trying to) get set up with an emulator to do Android development with Delphi. πŸ™‚πŸ˜žπŸ˜« (Had lots of fun and games trying to make the default Android SDK emulators work ... eventually started looking into alternatives including Nox... hence my response to this post) Suffice it to say that: I can successfully run .apk's produced with my newly recently installed 10.3.1 Rio installation by dragging and dropping the .apk onto Nox version I've also managed to make nox show up in Rad studio and deploy directly to nox, with some fiddling with adb: In short, after running Nox and following the instructions here: https://www.bignox.com/blog/how-to-connect-android-studio-with-nox-app-player-for-android-development-and-debug/ ... and then also using the adb.exe shipped with RAD Studio, e.g. the one in C:\Users\Public\Documents\Embarcadero\Studio\20.0\PlatformSDKs\android-sdk-windows\platform-tools to run: adb connect system responds: connected to ... refreshing the "Target" node then displayed the Nox emulator as a valid android target: I have however not managed to debug directly on Nox, this fails every time with the app stuck on the firemonkey icon and the Delphi debugger terminating immediately upon startup. Not sure what's going wrong or how to debug this yet. As a digression, I've also found (irritatingly) that out of the 2 phones I have available, debugging also doesn't work on the newer one (Note 8 ) because of "reasons" (something Google changed supposedly and Emba therefore says they won't fix), while it does work on the older phone (note 4). Meanwhile the test app I've tried while starting on both behaves rather inconsistently in regards of camera feature control (flipping between front and back cameras works on one, doesn't on the other, and setting the auto-focus mode doesn't seem to work the same between the phones either.) Perhaps these are all teething issues and possible to be worked around... Hope that helps.
  10. Welcome to the [BDE] club. That BDE installer isn't just the BDE but also installs the BDE components into the IDE, which is why it looks for RAD studio. After installation on the developer PC there's a file BDE_ENT.msi buried under ProgramData somewhere which is how you're meant to deploy it, not very obvious I know. (Easy to find with "Everything".) Alternatively you might consider a third party source. (For what it's worth we've extensively inspected and used this package, but treat it with the usual caution. It has some benefits in that it steps around/fixes the restrictions/problems that the BDE normally has on Vista and above due to the restrictions placed on Program Files, root folder and other system locations, that you might have to fix if you use the default Windows installer package.)
  11. ByteJuggler

    aItem := nil

    Yes, I was responding primarily to "TItem.Create" in your original post in context with the question "What is the right way of freeing the local class variables?". When applied in context of iterator then obviously the items belong somewhere else already etc. If your only concern is actually warnings about needlessly assigning nil then either don't do that or turn the warning off. (There's a way to disable most warning messages, I don't know off the top of my head whether and how to disable this particular message. Also some version of the Delphi compiler emitted as I recall some warnings or hints not entirely when you'd expect it. What version of Delphi are you using? If this is why you're seeing this, then ... )
  12. ByteJuggler

    aItem := nil

    Normal Delphi objects, using the Windows compiler, does NOT have garbage collection or any kind of automatic memory management like Java, C# etc. This means if you merely assign "nil" to an object reference, the memory pointed to originally by that reference is still allocated in the heap somewhere, but now "lost" -- you've caused a memory leak(!). Normal objects should be disposed of by calling the destructor, e.g. var LMyLocalObj : TSomeClass; begin LMyLocalObj := TSomeClass.Create(...); try //do something with LMyLocalObj finally LMyLocalObj.Free; //or if you prefer FreeAndNil(LMyLocalObj); end; // more code perhaps... end; Setting the reference to nil is a safeguard since if you do not do this then the value of the object reference will point to where the now-freed object used to be. For a while this may still look valid if accidentally used/derefenced, whereas if you reset the reference variable to nil then trying to dereference it will cause an access violation to be raised to alert you to the misuse. If there's no further use of the variable however in the current scope then setting to nil of course is redundant and serves no purpose. You should carefully review and ideally check your programs for memory leaks using for example the memory leak checking features of FastMM or some other tool. (There are several.) All that said, there are forms of automatic memory management available in Delphi on Windows: Interfaces support reference counting based memory management whereby the compiler will automatically free an interfaced object referenced via an interface reference when the enclosing method/function terminates, via code the compiler generates to check the reference count and act when it reaches zero. You should not manually free an interfaced object as this in turn may also cause an exception when the compiler auto-generated code also tries to free the object. This is a so-called "double-free" error. FastMM (or some other tool) can also be employed to help detect this type of mistake. Additionally please note that Embarcadero decided arguably somewhat controversially (in a departure from the behaviour on Windows) to adopt similar semantics for plain objects on the Delphi mobile compilers, this is commonly referred to as ARC ("Automatic Reference Counting", see here). So, when you write Delphi code and compile for a mobile target, then you do not need to explicitly call .Free() or even set to "nil" since the object will be automatically freed when its reference count hits zero. However, because of vaious reasons including not least the runtime cost of ARC and the conflicting semantics between the platforms, it looks like Embarcadero is now going to revert to making the mobile compilers behave the same as on Windows after Delphi 10.3 Rio, see here: http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html I hope that helps.
  13. ByteJuggler

    Style missing..

    Probably something in the .dproj file. It's worth taking a peek at where "Iceberg" occurs in the old .dproj file vs new ones and making suitable adjustments. Perhaps get rid of the theme specification entirely and then add it back in.
  14. 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
  15. 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.
  16. 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.)
  17. 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.)
  18. 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.)
  19. ByteJuggler

    Delete Error With Delphi and Access Table

    Yep, that's also going to be wrong! Missed that! πŸ™‚
  20. 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.
  21. 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... )
  22. 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.)
  23. 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
  24. ByteJuggler

    dotNet framework 4.5 required for Delphi 10.3 Rio

    Also here: https://quality.embarcadero.com/browse/RSP-21670
  25. 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.