My boss won't let us move to Berlin until there is a FixPack for it. We have a very large app, and the Fixpack literally saves us hours a day.
My boss won't let us move to Berlin until there is a FixPack for it. We have a very large app, and the Fixpack literally saves us hours a day.
Andreas Hausladen -- We'd love to have a FixPack for Berlin and going forward.
Can we entice you to do it? Would a non-trivial donation help? Can we eliminate any roadblocks or hesitations you may have?
As a side note, have you considered becoming an MVP?
Sorry to be so forward, but we really can't work without the FixPack.
Andreas Hausladen -- We'd love to have a FixPack for Berlin and going forward.
Can we entice you to do it? Would a non-trivial donation help? Can we eliminate any roadblocks or hesitations you may have?
As a side note, have you considered becoming an MVP?
Sorry to be so forward, but we really can't work without the FixPack.
I don't let my boss to move to Berlin until there is a FixPack for it :)
ReplyDeleteI would prefer Embarcadero takes care that the necessary fixes applied via the FixPack will be included with each release. I still don't understand why such a fundamental thing isn't already included. And I don't see any good reason why the FixPack features shouldn't be included out of the box.
ReplyDeleteFred -- I think Marco Cantu can address that particular issue. It's not as easy as just "Throw it in the box".
ReplyDeleteNick Hodges My understanding is: FixPack fixes some errors/problems in the IDE. Why doesn't Embarcadero fix those problems? I fully understand that Embarcadero can't simply grab the FixPack and put it "into the box". I actually see the solution more at the root of the problem.
ReplyDeleteFred Ahrens I think the problem is that Andreas does things that EMBT is not willing to do.
ReplyDelete... or put another way -- FixPack isn't a collection of bug fixes, it's a "Hack" into the compiler to do things that EMBT considers too risky to make part of the compiler. But again, I'm not at EMBT. That's me speculating.
ReplyDeleteNick Hodges Ah, OK, now I get it.
ReplyDelete... and of course, Andreas can explain it best of all.
ReplyDeleteNick Hodges Agree, is a hack making EMB IDE usable from years. If EMB think is a risky hack, but very comfortable make a whole ide work better with a alone code fixer as Andrea. EMB is in a very comfortable position here. The problem is now Andrea don't have enough time anymore. And all the IDE users consider that "hack" is the only way to go over E;B die, me too.
ReplyDeleteBTW, for several commercial reasons i already switch to BERLIN. Seems some unstable right now, but nothing Delphi users don't suffer in the past. Saying that is "usable" and compile faster (but take some time to start so i don't know exactly the average time). Im waiting for a miracle from Andrea , or even more difficult a Fix pack from EMB (an utopia).
ReplyDeleteIMO it would be preferable if they included IDE fixpack as an optional component (with suitable caveats made clear), that is by default not installed but nevertheless formally made available from release day. (Admittedly/Sadly there may be reasons why this is currently not feasible.)
ReplyDeleteNot quite a hard requirement for us, but it certainly boosts productivity by a great deal. Huge shame that this is left to third-party developers.
ReplyDelete/sub
ReplyDelete/sub
ReplyDeleteYeah, because the quality from the IDE is that high, it can break error inside, the refactorings, code inside etc....:-)
ReplyDelete/sub
ReplyDelete/sub
ReplyDeleteIs there anyone using Delphi without the fixpack? I dont count the versions without the fixpack ofcourse. Just wondering if anyone is preferring not to use the fixpack?
ReplyDeleteI would like to have not only the Fixpack, but DDevExt too. Please, Andreas Hausladen
ReplyDeleteBora Aydemir I never used FixPack. I never felt like IDE or compilation is too slow to bother me. The only $%&#@ thing is IDE startup time since XE3
ReplyDeletehttp://qc.embarcadero.com/wc/qcmain.aspx?d=108632
I prefer not to use any extensions because that way it is easier for me to report bugs and issues in IDE. And I know that only Embarcadero is to blame for those I do encounter :)
/sub
ReplyDeleteThis is request number... I stopped counting. Patience... Andy will do something about that topic and DDevExtensions when he think it is time and my name is Hase (DE)
ReplyDelete/sub
ReplyDeleteAbout becoming a MVP: Someone said that he declined such invitation in the past. I wonder why...
/sub
ReplyDelete/sub
ReplyDeleteI don't use the fix pack. In general, I use very few plugins. Parnassus Bookmark/Navigator are the only exceptions.
ReplyDeleteEmba is not able to address the issues with their own resources?
ReplyDelete/sub
ReplyDeleteBeing an MVP comes with restrictions on what you can and can't say. If GetIt was a self serve marketplace tools like this could easily be offered for sale which would offset their development costs.
ReplyDelete/sub
ReplyDeleteWe also miss DDevExtensions dearly.
mr Hausladen has some hacks in the codebase that prevents him to releasing these as OpenSource .I think he explained, in Delphi PodCast perhaps, that some hacks are so close to Crack that he can't release them.
So only possible way most likely would be that Andreas would get permission to add few trusted people top his team, to help him. Or Embarcadero would it self chip in and start maintaining these, by including those fixes and enhancements into the product or just maintain the Add-in it self (With or without Andreas, how ever they would agree).
In any case all that Andreas has ever released has been more than less pure cold! Hope there would be a way to get these projects to go forward, without stressing Andreas out
I never used the FixPack. Tried it several times over several years, but every time it caused problems for me, so I quickly removed it again.
ReplyDeleteHans Lavdal Jakobsen That is one reason why an external FixPack is superior over those fixes baked into the IDE: you can get rid of it when it doesn't work in your environment.
ReplyDeleteDalija Prasnikar I believe the size of the project is the key. On small. medium size projects is aceptable, with larger projects is very uncomfortable ( i have to kill the IDE 3 times on that morning, no response at all, just open a project). There is where Andreas`s works shine. Don't know why EMB can fix own IDE
ReplyDeleteI've tried without it on many Delphi versions. Went to use it for each of them. It's indispensable and one of the tools I'd pay for.
ReplyDeletewe always use FixPack and its availability is a must criteria to switch to a new Delphi version. For a long time it was the only way to make the x64 compiler running with larger projects. Specially interesting would be the IDE Fix Pack 6.0 BETA (improving the compile speed for x64 dramatically!).
ReplyDeleteBut I have to admit that we only use FixPack for development. The final batch built and testing is done without it.
Günther Schoch Why don't you use for final test? AFAIK IDE fix pack don't change the final code. Im wrong?
ReplyDeleteHans Lavdal Jakobsen Can you be specific? What kind of problems did you run into using the fixpack?
ReplyDeleteFrom twitter it seems Andreas just came from holiday and got noticed. #TheWorldIsSaved
ReplyDeleteDavid Berneda link: https://twitter.com/AndyHTech/status/736300954870484992
ReplyDeleteBora Aydemir I cannot say for sure that the FixPack was the reason, but I experience instability and errors in both IDE and compiling (not in the final executable). However, during the Delphi XE+ period there have been plenty of problems when targeting iOS (which I currently do), so my problem might as well be caused by Delphi itself - I just wanted to minimize the potential causes for this.
ReplyDeleteGerman Gentile
ReplyDeleteFor the final build we could not 100% commit to our OEM customers that resulting the binary is identical. Identical means identical to the Escrow version we have to deploy (e.g. for IBM). But "final building" is a larger batch process and no really problem to have some extra time there. But for the daily development work we are in the same situation as Nick Hodges.
Hans Lavdal Jakobsen actually you can just compare binaries with any comparer.
ReplyDeleteGerman Gentile one problem with the compiler is that even with the same source set, it generates different binaries as there are some time depending factors ending up in the binaries.
ReplyDeleteSo, wich is the recommended way to go? Disable IDEFIX for the release binary? I never do, in all that years. Im really surprised about the fact it can change final binary, I remember specifically Andreas say it don't changes final product. I can be wrong, maybe the better way to know is a full release build with both options and compare.
ReplyDeleteMy final builds are always different and actually some 10 kB larger, because of the signing. I usually don't sign builds during development.
ReplyDeleteWe've used IDE Fix pack and the FixPack compiler for our daily IDE use and for our release to customers. We've had exactly zero problems as a result.
ReplyDeleteWhy should I disable the FixPack in the final build while it's enabled in all other phases of development and testing - and doesn't cause any problems there?
ReplyDeleteGerman Gentile don't use the IDE for building other than development builds. Use a CI approach with command-line msbuild based builds without fixpacks.
ReplyDeleteJeroen Wiert Pluimers Thank you for the recommendation, but based in my experience, i prefer to release the same code i was testing, copycat! :)
ReplyDeleteGerman Gentile that's why you have DTAP. D is using the IDE. TAP are using the CI. Sometimes TA are the same.
ReplyDeleteJeroen Wiert Pluimers have no idea about what are you talking, seriously. Don't worry and thanks for the comments.
ReplyDeleteNick Hodges if your donation can expand a day to 48 hours then yes. I'm not against donations but they are no requirement to use IDE Fix Pack. I just don't have the time to work on IDE Fix Pack that much as I had in the past. Donations don't help to get an IDE Fix Pack release faster but are still welcome :-)
ReplyDeleteAll the low hanging fruit patches are already written, what means that the amount of work I have to invest into a new patch doesn't increase the compiler's speed that much. So I need more of those very complicated patches to get more than 20 milliseconds out of the compiler.
I'm not an MVP because I think I don't fit the "job description". If I blog or tweet about Delphi it is mostly negative for Delphi. I don't even remember when I posted my last positive tweet about Delphi. Must have been 8 years ago or so.
About the code that is generated by the compiler with and without IDE Fix Pack.
If there isn't a bug in IDE Fix Pack then the compiler outputs the exact same code as it would output without IDE Fix Pack. IDE Fix Pack doesn't change the code generator. What it does, is to use specialized hash tables instead of linear lists, optimized RTL functions (Move, FillChar, StrCmp), removes unnecessary code (a kind of whole program optimization that can't be done in the source code), moves invariant code out of loops, rewrites some algorithms (e.g. removes the "cleanup delay" between 2 compilations) or shortcuts code (e.g. disabled warnings and hints don't need to build the message string that is then ignored)
I can't guarantee the correctness of the IDE Fix Pack code, because I have to do binary patches and I'm a human being, but after such a long time with thousands of users that use it (aka test it), I'm certain that it doesn't generate defect executables. If it does then I'm usually very fast in either fixing the bug or removing the not working patch.
IDE Fix Pack doesn't contain code that would crack the IDE. DelphiSpeedUp had code from a Delphi 7 patch (2002) that circumvented TurboDelphi's user package loading limitation (2005). So the "crack" existed way before the code that it "cracked" existed :-). But I rewrote the patch after I found that out and deleted all old downloads so you couldn't use the free TurboDelphi without the limitation.
IDE Fix Pack doesn't magically fixes all IDE and compiler bugs. Actually it doesn't fix any compiler bug unless you view performance optimizations as a kind of bug fix. That's why I call them patches.
For example the bug with the not working CodeInsight (Ctrl+Space) if you have declared a static array in a class, won't be fixed by IDE Fix Pack. You have to wait for EMBT to fix that. I don't have the time to hunt that one down. And I just don't use Delphi that much anymore, especially the newer versions, that it "forces" me to find a fix.
Why don't I release the IDE Fix Pack's code? Well that is not only for personal reasons, but the personal reasons are that I don't want another rival product, I don't want to answer questions about how this and that works, I don't want you to see the unreadable code with all the global variables, hair-raising code flow and assembler code without comments (the older the patch the less comments).
Why isn't EMBT incorporating the IDE Fix Pack patches? I remember the time when Delphi XE came out and the IDE Fix Pack for XE was very small compared to the 2010 version. It consisted of about 5 patches compared to the 38 from 2010. And those XE patches would be very hard to implement in the source code because they make assumptions and store values across multiple function calls.
Almost all newer compiler patches are of that kind. It is like a whole program optimization. It would make the source code unmaintainable and unreadable.
And last but not least one positive thing about Delphi 10.1 Berlin. The Generics optimizations that EMBT did to the compiler are slightly faster than my own Generics optimizations. So I will remove those patches from the 10.1 Berlin release (Actually those patches can't be applied anymore, so they must have touched the same code parts that I patched).
ReplyDeleteAfter spending almost 2 hours today answering emails and writing this, I may not work on IDE Fix Pack today. Maybe tomorrow.
BTW: Andreas (male) is not the plural of Andrea (female) in German. Just use "Andy".
Andy --
ReplyDeleteThanks so much for your response. I'm looking forward to telling my boss that things are in the works.
I understand that your time is valuable -- very valuable if the desire here to see a Berlin Fix Pack is any indication.
I hope you know how much we here in the Delphi community value and appreciate the time you spend making our development experience better.
Thanks for a thorough post, the excellent and interesting explanations, and for your time and effort on the FixPack.
/sub
ReplyDeleteNick Hodges "My boss won't let us move to Berlin"
ReplyDeleteTell him about the beer gardens! :-)
Nick Hodges do you test now? I can say Andy fixes solve the speed problem for me, still takes a few seconds more to start a build process but the idea is very responsive. I like it.
ReplyDeleteNo, we haven't had a chance to run Berlin through its paces. But I suspect we will -- it just has to get put on our schedule.
ReplyDelete