Anders Melander

https://github.com/SynEdit/SynEdit

Yes

No. I claimed that they would exhibit the same symptoms. I.e. incorrect result due to accumulation of rounding errors. That's not twisting anything. The degree of imprecision will be the same for the same data type regardless of the compiler since we're dealing with a native data type implemented on the CPU. The exact error might differ, but that doesn't make any difference. I'll take your word for that. It's all GrΣΣk to me

Yes they both suffer from floating point rounding errors. The fact that the exact error values differ doesn't make any difference. All compilers will suffer from this as the imprecision is inherent in the nature of floating point precision. Higher precision will make the error smaller but there will still be errors. As David points out the only way to avoid that is to use another algorithm. If that isn't practical then one might try to implement with an arbitrary precision library.

Why would that make a difference? If the problem is caused by rounding errors then FP will exhibit the exact same symptoms.

So... SO is better than a forum?

stackoverflow

Can't you use middle click to close the file?

I know. Hence the

[Alt]+V = View menu E = New Edit window [Alt]+[Space] = Top level Windows menu X = Maximize

[Alt]+V E [Alt]+[Space] X

Famous last words. I hear the NSA is very fond of hardware firewalls. The firmware is often very old.

Maybe you shouldn't have let that guy with the strange English accent from "Microsoft Support" help you with you "PC problem" Speaking of sleeping right at night; This thread was actually the topic on my dreams (yes, it was a nightmare) last night: I watched in horror as all my systems were being encrypted before my eyes. Somehow the hacker had so much control over my system that it kept on running even after I pulled the plug. Completely unrelated , but the first thing I did this morning was to run a compete scan on my system.

In this example, no, since the only design-time functionality being used is RegisterComponents() which is implemented in the RTL in a runtime package, not a design-time package. So this example can exist in a single runtime+designtime package. What I meant was that it's good practice to separate all run- and design-time code regardless of the fact that I didn't need to in this case. Thus my use of should instead of must. So far we have just your word for that and I contest it. The Delphi Developer's Guide has 14 pages on the topic of creating run- and design-time packages yet nothing that supports your claim. However it does mention one little detail that I had completely forgotten about: The DCLUSR default package. Guess what; It's a design-time only package. Do I need to elaborate on what that implies?

That depends on how you setup your projects. For example I never use the global library search path for anything other than the standard VCL/RTL. All project specific libraries goes into the project search path. Since I also place these libraries in sub folders under the project root all the search path entries can be made relative to the root. This has the benefit that the projects can built anywhere by just pulling the source. All projects are self contained.

That's fine if you only work with projects where only one version of the components are ever used at the same time across projects or branches. If you have to maintain multiple versions or branches of a project then you will potentially have to recompile the packages every time you change the branch you work on. It's a significant effort to have to babysit every commit made by unaware developers because they save forms with component properties that doesn't exist in the version of the components the application will be built with. Compiles and runs fine on their system but breaks at run time when built on the build server. If Embarcadero dog-fooded Delphi on something other that Delphi itself then I'm pretty sure they would have solved this problem a long time ago.

I think you just proved my point there. I'm not saying that you can't get out of trouble. I'm saying it's rather easy to get into trouble. The challenge is figuring out how to do that. https://ohshitgit.com/

It wouldn't - but since that's no worse than the existing system I'd say it's acceptable. Linked modules, base forms etc. would need to follow the same rules as the rest of the project. I don't see the problem. Then those packages would not be supporting per project configurations. You need to establish a set of rules and exclude those that doesn't follow them. Not supporting dynamic unload is already a bug with the existing system.

That's me The only times I've had to use Git from the command line is when Git has f*cked something up (yes, I blame it on Git ). Git is a powerful tool but when you shoot yourself in the foot with it it leaves a rather large hole. I can recommend the Atlassian Git tutorials even for those not using Atlassian tools. Most of the tutorials are tool agnostic. https://www.atlassian.com/git

You can't use the rules for what a design-time packages cannot do as an argument for why a design-time package must also have a run-time package. Nowhere in what you quoted, or elsewhere, does it say that; It's a straw man argument. Say I have this custom component: unit MyComponent; uses Classes; type TMyComponent = class(TComponent) end; procedure Register; implementation procedure Register; begin RegisterComponents('My stuff', [TMyComponent]); end; end. Apart from the fact that I should split this into two units, are you saying that if I place this into one package then I must mark it as both design- and run-time and if I place it into a design-time only package then I must split the unit into two and also create a run-time package? If so, that is simply not true. Going back, all the way to Delphi 1 (yes, I've just checked), there has never been a documented requirement for that.

If you use interposers then you don't need all that. You just declare the interposer and use the unit where it's declared (or declare it in the unit where you use it). That's the point of it: You don't need to change the existing forms and often not even the code. When I use interposers to fix bugs in existing components (mostly VCL), or alter their behavior, I place the interposer in a separate unit and use that. When I need to alter a few controls on a single form I just declare the interposer in that forms unit. Problem solved, next case. I'm not saying one shouldn't use proper design-time registered components, I still consider interposers somewhat of a hack, but given the hassle of maintaining design-time packages across multiple projects and versions, interposers are a blessing. In order to remove the need for interposer classes Delphi would need: A package management system that allowed us the define per project design-time packages. The current project package configuration doesn't work. It still operate on a global package list. A mechanism to redirect the class resolver when forms are streamed. Since it already uses a global class registry when streaming a form it shouldn't be that hard to implement. I do wish the VCL had an official mechanism to solve the same problems that interposer does - but it doesn't.

Um yes. As you know we've had this discussion before. I can accept that in your opinion it is best to have both design- and run-time packages (or both in one), but it's not a requirement and never have been.

...or just mark it as a design-time package. That will work equally fine.

No. PlasticMerge is a part of PlasticSCM. So what you do is to install the free version of PlasticSCM and then just use the stand alone merge tool. It used to be a separate download but it's long been a part of the SCM suite. I haven't tried SemanticMerge. I believe there's an abandoned project for a Delphi parser somewhere out there. Yup, found it: https://github.com/andremussche/SemanticMergeDelphi (last commit 7 years ago) Linked to from here: http://blog.plasticscm.com/2015/09/custom-languages-in-semantic-version.html

As I mentioned I use SourceTree too and I'm fairly satisfied with it. Latest version is 3.3.9. The basic functionality works well but there are some annoying bugs with regard to BitBucket integration that keeps being fixed and then come back after a few releases: The BitBucket integration (Check out in SourceTree) crashes SourceTree: SRCTREE-7109 The remote account extended integration option isn't persisted: SRCTREEWIN-12912 The worst thing however is the poor performance of the integrated Diff view. Select a large DFM-file and it can take 20-30 seconds before the UI responds. Stage one hunk and you have to wait for the diff to complete again. Now imagine having to cherry pick changes from a large DFM with hundreds of small changes. In this scenario its best to have an alternative tool for just that case. That's one of the nice things with Git; All the tools are compatible. You can stage some changes in one tool and others in another. I usually handle file renames and moves by staging in TortoiseGit and then committing in SourceTree. Oh and one absolutely needs to have an external Diff and Merge tool. I use Araxis for Diff and Plastic for Merge. Plastic is free if you just install the community edition.