Worlds dumbest IDE



  • Delphi 2005 - it's just my daily glimpse of what hell could be like.

    At first it looks alright, seems to work for a while, but then... all kinds of little annoyances start to surface. On their own, they are just little bugs. But together they create an environment that could make programmers go postal. Today I found a new one, it's really ugly, let me tell you.

    The conclusion: it appears that the IDE shows files with corrupt line endings the way you'd expect, a #13 without #10 will still be shown like a #13#10 line ending. So the code looks alright and compiles correctly.

    But as soon as you want to debug, you'll notice the blue dots (in the margin, to show which code was compiled) appear in strange places. It is impossible to step through the code in a normal way. I've had this blue dots problem before, at the time it was caused by looking at another .pas file with the same name as the actually compiled file, and the IDE thought it was this compiled file. So I checked and double checked but this wasn't the case. I finally found out about the line endings. They were corrupted because I used a broken regex to convert an SQL script to Delphi strings :(
     



  • I agree with you that Delphi 2005 sucks. Up to verion 7 it was getting better and I loved it. It worked really fast (initial loading, compiling, debugging etc.). I took a look at Delphi 2005 a couple of years ago and I noticed that it is loading terribly slow (about a minute, while visual studio 2003 was loading for less than 10 seconds... delphi 7 took no more than 2 seconds to load). It also screwed up something in IIS and Visual Studio couldn't create a new web project anymore. Can't remember what other damage it caused and even uninstalling didn't help so I had to reinstall the entire machine.



  • The line endings thing is more of a Windows WTF. In the Windows world, text files and binary files are distinct from each other - this is why FTP clients on Windows are legendary for buggering up files by "converting" them from binary to text format.

    Why Windows has to perputuate this hangover from the teletype days (where two characters signified "carriage return" then "line feed" so that the teletype had time to move the print head to the beginning of the next line) is beyond me.


     



  • Yep, I think it went waay downhill when they rewrote it in Java.  It used to  be speedy but now lags even on a 3GHz PC.

     

    Try opening a 30MB data file sometime-- yawn.

     

    particularly bad is the help system-- it used to be WONDERFUL,  you'd press shift-F1 and up would pop the right thing, complete with a usable example, and useful links to related concepts, and links upwards to more general topics.

     

    Now you press help and it chugs for about ten seconds (Java starting up you know), then it pops up instead of the old useful paragraph or two, a sentence at most written by some clueless mouth-breather, no examples, no useful links sideways or up.  And most of the time it's talking about .NET or C++ similar concept, not the Delphi one.  If I'm in Delphi, writing Delphi code, why would I ever want a .NET or C++ help page?  Sheesh.

     

    And the "back" button in Help never does what you expect.

     

    And the code-completion "feature" never seems to do anything correctly-- it inserts bogus zero-based for loops, which I never want.  It inserts extra ends when I've explicitly already put one in.  And it doesnt diagnose the most common syntax error-- missing begins or ends.  

     

    *And* Delphi now comes bundled with tons of really poorly working, poorly conceived, and poorly documented add-ons.  Perhaps they should ask some programmers what they need-- it's rarely another shaky and pointless UML tool.  And what's the point of all the unhelpful names?  How am I suppsed to remember that "Refulgence Gold" is a database designer, "Bootylicious Extreme" is a useless rectangle and line drawer, and "Picadilly Ultra III" is a slow, limited,  and buggy CVS?   Sheesh!

     

    Obviously, the marketers are in full charge.

     

    How's about giving us things we really need like:

     

    *  A code profiler.

    *  A memory leak catcher.

    *  A code formatter.

    *  A IDE that understands "with" statements.

    *  A API parameter lookup tool that doesnt get tripped up by an undeclared variable.

     

     Delphi is a wonderful tool overall, but sheesh, why all the obvious bugs and misfeatures?


     

     

     

     

     



  • @LizardKing said:

    The line endings thing is more of a Windows WTF. In the Windows world, text files and binary files are distinct from each other - this is why FTP clients on Windows are legendary for buggering up files by "converting" them from binary to text format.

    And don't forget that Macs compound the problem by only using single LF characters rather than the single CR you get on unix.  A decent FTP client will usually warn you if you are using the wrong text/binary settings though.


    The solution where I work was to install a script on the CVS server that checks line endings on commit.  They have to be consistent throughout a given file or the commit is rejected and you have to fix it before trying again.  We do the same for tabs in source files after historical problems with mixed tabs and spaces.

     



  • Yes, I agree with all your points. The thing is, I have to maintain a program written by a guy who couldn't. And he started working on it in Delphi 5. The code has never been refactored, the units just got bigger and bigger. Now it's a mess and I (used to be a .NET programmer with Visual Studio 2003 - 2005) have to solve all the problems. Delphi 2005 is not exactly helping me to do my job...



  • If you think maintaining legacy Delphi code is bad with Delphi 2005, try this one; interopping assemblies written in Delphi.NET with C# assemblies. You'd be surprised at the amount of loopholes you'd have to jump through to get some things working, while other things will simply never work.

    For me, a big WTF came from an ASP.NET webservice, which serialized custom objects to send to the clientside facade (which of course Delphi 2005 automatically generates...). Sending objects themselves; no problem. Sending arrays of objects; Hey, why do all my arrays have 0 elements when retrieved by the client?! Answer; Because Delphi internally does something really disgusting, leading to incompatibilities between .NET's built in System.Array and Delphi's own array implementation, horribly messing up the results from the auto-generated clientside delegate function that calls the actual webservice function. The kicker; The Delphi one is (atleast documented) to be converted to a System.Array when compiling anyway...

    That wasn't the biggest WTF I had with Delphi 2005 though. The biggest one came when I had to juggle with some array indices (to get a Delphi array 'talking to' a System.Array, ironically) and ended up having to retrieve the 0-th element for some reason. So we retrieve myArray[0], at which point the compiler screws up and claims 0 is not a System.Int32. Okay... So maybe it can't handle const ints for some reason? We create a new System.Int32 myIndex = 0, then retrieve myArray[myIndex] at which point the compiler claims that the type System.Int32 is not compatible with the type System.Int32.... WTF?! (I probably could have submitted that one to popup potpourri, but by that point I had already grown apathic to Delphi WTFs.)

    Screwups like the above won't really seem all that weird anymore once you've used an assembly inspector tool to look at the inside of a Delphi.NET generated assembly though. Borland used some rather... interesting?... ways to maintain the classic Delphi way of working with units, unit global variables, etc. Let's just say that it's a miracle System.Reflection isn't completely broken on Delphi.NET generated assemblies. And yes; it is partially broken, which gives plenty of WTFs when working with large System.Reflection dependent C# frameworks.

    Then there's Borland's design decision when it came to namespaces. You see; the Delphi.NET and regular .NET namespace differ. Yes, they're different. Delphi 2005 'automagically' gives a class a C# namespace by chopping off the last section of the name of the unit the class resides in. The catch here is that code generated in Delphi.NET still needs that last section, while C# code must have it removed. That means happy time when dealing with embedded resources as well.

    And that's just the compiler and generated code. Don't even get me started on the IDE quirks. Arbitrarily deciding to lock up, erasing or corrupting code files, randomly unregistering assembly references from your projects, randomly resetting paths to resource files to places where said resource files do not exist, randomly popping up dialog boxes stating something being a null reference, etc. etc. The list goes on and on and on.

    Eventually (as in 'after several months of time') I figured out a few things to get it reasonably (as in 'no longer mind-destroying') stable though;
    Disable Together support on your project and use task manager to assign the IDE process to a single CPU. Apparantly a slew of the more exotic quirks are simply caused by non-threadsafe code, while Together can be attributed a 150MB memory leak that develops over time. As it turns out, the randomly popping up dialog boxes with null references are caused by code completion. With that shut off you might just as well be using freakin' Notepad to code.
     

     Borland; From hero to zero.



  • @Gabelstaplerfahrer said:

    Delphi 2005 - it's just my daily glimpse of what hell could be like.

    At first it looks alright, seems to work for a while, but then... all kinds of little annoyances start to surface. On their own, they are just little bugs. But together they create an environment that could make programmers go postal. Today I found a new one, it's really ugly, let me tell you.

    The conclusion: it appears that the IDE shows files with corrupt line endings the way you'd expect, a #13 without #10 will still be shown like a #13#10 line ending. So the code looks alright and compiles correctly.

    But as soon as you want to debug, you'll notice the blue dots (in the margin, to show which code was compiled) appear in strange places. It is impossible to step through the code in a normal way. I've had this blue dots problem before, at the time it was caused by looking at another .pas file with the same name as the actually compiled file, and the IDE thought it was this compiled file. So I checked and double checked but this wasn't the case. I finally found out about the line endings. They were corrupted because I used a broken regex to convert an SQL script to Delphi strings :(
     

     

    Soooooooooo....YOU fudged up the file conversion with a bad regex and created a corrupted/invalid format, and the IDE is the WTF? Wow.

     

    That would be like blaming the reader for being unable to read/comprehend a book that hasn't been properly punctuated.



  • @unklegwar said:

    @Gabelstaplerfahrer said:

    Delphi 2005 - it's just my daily glimpse of what hell could be like.

    At first it looks alright, seems to work for a while, but then... all kinds of little annoyances start to surface. On their own, they are just little bugs. But together they create an environment that could make programmers go postal. Today I found a new one, it's really ugly, let me tell you.

    The conclusion: it appears that the IDE shows files with corrupt line endings the way you'd expect, a #13 without #10 will still be shown like a #13#10 line ending. So the code looks alright and compiles correctly.

    But as soon as you want to debug, you'll notice the blue dots (in the margin, to show which code was compiled) appear in strange places. It is impossible to step through the code in a normal way. I've had this blue dots problem before, at the time it was caused by looking at another .pas file with the same name as the actually compiled file, and the IDE thought it was this compiled file. So I checked and double checked but this wasn't the case. I finally found out about the line endings. They were corrupted because I used a broken regex to convert an SQL script to Delphi strings :(
     

     

    Soooooooooo....YOU fudged up the file conversion with a bad regex and created a corrupted/invalid format, and the IDE is the WTF? Wow.

     

    That would be like blaming the reader for being unable to read/comprehend a book that hasn't been properly punctuated.

    The WTF is the fact that the IDE and the compiler don't warn you about the file being corrupt, I think. I've run into this a few times myself (related to files going corrupt when the IDE would lock up on me).
     



  • @unklegwar said:

     Soooooooooo....YOU fudged up the file conversion with a bad regex and created a corrupted/invalid format, and the IDE is the WTF? Wow.

     That would be like blaming the reader for being unable to read/comprehend a book that hasn't been properly punctuated.

    Finally, someone who makes sense. :-)

    I've been a Delphi developer since Delphi 1 was released (prior to that I worked in C/C++/Clipper). Delphi 2005 is a great product, once you've installed the hotfixes that have been released.

    The mismatched line endings problem has existed for quite some time now. It's a problem with the compiler. It's also well known, and could probably be found with a Google search on "Delphi missing blue dots"; I didn't try the search myself, but I'd suspect it would find enough info to point out the two causes of the problem. (Duplicate file on search path than the one opened in the editor and mismatched line endings.)

    On my development machine (2GHz AMD Turion 64, 1GB RAM, 100GB HDD) BDS 2005 with only the Delphi personality loading takes approximately 15 seconds to initially start; the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds. 

    The Code Insight stuff works fine for me, too. As for API parameters, there's a registry setting you can add that allows Ctrl+Space to show you the proper parameters and their types.

    All in all, BDS 2005 is a great product. I've used Visual Studio Express (C#) for some projects that needed the .NET 2 framework, and it's a piece of crap compared to the BDS IDE. Talk about being extremely slow!

     



  • @KenW said:

    the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds. 

    The .NET CLR is spun up on a per process basis; if you stop the process (close the IDE) and re-start it, it still has to spin up the CLR again. It shouldn't incur a greater cost the first time, I don't think.

    -cw

     



  • @CodeWhisperer said:

    @KenW said:

    the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds. 

    The .NET CLR is spun up on a per process basis; if you stop the process (close the IDE) and re-start it, it still has to spin up the CLR again. It shouldn't incur a greater cost the first time, I don't think.

    -cw

    Maybe an effect of harddisk caching?
     



  • @KenW said:

    @unklegwar said:

     Soooooooooo....YOU fudged up the file conversion with a bad regex and created a corrupted/invalid format, and the IDE is the WTF? Wow.

     That would be like blaming the reader for being unable to read/comprehend a book that hasn't been properly punctuated.

    Finally, someone who makes sense. :-)

    I've been a Delphi developer since Delphi 1 was released (prior to that I worked in C/C++/Clipper). Delphi 2005 is a great product, once you've installed the hotfixes that have been released.

    The mismatched line endings problem has existed for quite some time now. It's a problem with the compiler. It's also well known, and could probably be found with a Google search on "Delphi missing blue dots"; I didn't try the search myself, but I'd suspect it would find enough info to point out the two causes of the problem. (Duplicate file on search path than the one opened in the editor and mismatched line endings.)

    On my development machine (2GHz AMD Turion 64, 1GB RAM, 100GB HDD) BDS 2005 with only the Delphi personality loading takes approximately 15 seconds to initially start; the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds. 

    The Code Insight stuff works fine for me, too. As for API parameters, there's a registry setting you can add that allows Ctrl+Space to show you the proper parameters and their types.

    All in all, BDS 2005 is a great product. I've used Visual Studio Express (C#) for some projects that needed the .NET 2 framework, and it's a piece of crap compared to the BDS IDE. Talk about being extremely slow!

    The hotfixes? BDS 2005 had three official updates and none of those really fixed any usability problems. Infact, installing update 3 on my machine actually toasted the help file and I had to use 3rd party tools to manually recompile and reintegrate it into the help system.

    It's also no wonder you're having little problems with BDS 2005; You're only loading the Delphi personality (and I assume only the Win32 one at that). Try loading the Delphi.NET one and see how well you fair. I can almost guarantee that your user experience will be less than satisfactory. Contrary to what Borland would probably like to tell you, cutting out over two-thirds of an expensive product (with a draconian license to top it off) does not constitute 'fixing the product'. (Actually, I bet it's even more probably they'd just try to shovel 2006 on you.)

    Startup time of the BDS IDE when using the Delphi.NET personality was approx. 1,5 minutes on my dev. machine (1.8GHz Pentium 4, 2GB RAM). Afterwards, opening a project of about 20kloc to work on would take an additional 15 seconds. This in contrast to VS 2005, which manages to start up perfectly fine in 25 seconds, including loading a project in the same order of size.

    Oh yeah, as for Code Insight, code completion, ctrl+spacing; It's true that it works a lot better on the Delphi-Win32 personality, but when using the .NET personality you can count on running into heaps and heaps of weird quirks.

     

    So, all in all BDS 2005 is a great product, yes, if you are looking for nothing other than a new IDE for maintaining your legacy Delphi-Win32 applications. But wait; Didn't you have Delphi 7 for that?



  • @CodeWhisperer said:

    The .NET CLR is spun up on a per process basis; if you stop the process (close the IDE) and re-start it, it still has to spin up the CLR again. It shouldn't incur a greater cost the first time, I don't think.

    -cw

     

    Yes, but the OS caches the files that were opened the first time, and they're still in the cache during the restart. Thus, the increase in speed. :-) 



  • @Ragnax said:

    The hotfixes? BDS 2005 had three official updates and none of those really fixed any usability problems. Infact, installing update 3 on my machine actually toasted the help file and I had to use 3rd party tools to manually recompile and reintegrate it into the help system.

    Three official updates? There have been 9 hotfixes released, IIRC. Enough so that they bundled them into the hotfix rollup. And none of the hotfixes caused any problems when installed.

    @Ragnax said:

     

    It's also no wonder you're having little problems with BDS 2005; You're only loading the Delphi personality (and I assume only the Win32 one at that). Try loading the Delphi.NET one and see how well you fair. I can almost guarantee that your user experience will be less than satisfactory. Contrary to what Borland would probably like to tell you, cutting out over two-thirds of an expensive product (with a draconian license to top it off) does not constitute 'fixing the product'. (Actually, I bet it's even more probably they'd just try to shovel 2006 on you.)

    Where did I say that? I was discussing startup speed. Nowhere did I say I only use the Delphi personality (or Win32). I use all of the personalities (well, rarely the C++ - why punish myself?). 

    @Ragnax said:


    Startup time of the BDS IDE when using the Delphi.NET personality was approx. 1,5 minutes on my dev. machine (1.8GHz Pentium 4, 2GB RAM). Afterwards, opening a project of about 20kloc to work on would take an additional 15 seconds. This in contrast to VS 2005, which manages to start up perfectly fine in 25 seconds, including loading a project in the same order of size.

    Bull. If that's the case, you're running everything else on your machine simultaneously. I can load the full BDS 2005 (all personalities) in less than a minute, while VS Express takes about 2 minutes (I say about because I haven't timed it, so I'm approximating. I'll be glad to time it when I get back to that machine tonight, though.

    @Ragnax said:


    Oh yeah, as for Code Insight, code completion, ctrl+spacing; It's true that it works a lot better on the Delphi-Win32 personality, but when using the .NET personality you can count on running into heaps and heaps of weird quirks.

     

    When will it start? I haven't experienced it at all yet (in over a year of using BDS 2005). 

    @Ragnax said:


    So, all in all BDS 2005 is a great product, yes, if you are looking for nothing other than a new IDE for maintaining your legacy Delphi-Win32 applications. But wait; Didn't you have Delphi 7 for that?

    Yep. Still use Delphi 7 occasionally; I've got some apps that use components that won't compile under Delphi 2005, and I don't do enough with those components anywhere else to make it worth porting them over.

    When I do have to use Delphi 7, though, I miss all of the enhancements to the IDE. I get things done, but it's a lot slower; I have to remember how I did things the old-fashioned way now that I'm used to the BDS IDE. 



  • Well, I know that Delphi users are not compatible with Visual Studio users, but I am using both for some time now and I can tell you, I want to get rid of Delphi ASAP. It's not the little things that differ, it's just that it's really clear to me how much energy Microsoft puts in its IDE to make it better. All the tiny little additions, the slightly better intellisense, the native .NET support and good help system, they are things that just make me happy as a developer.

    Of course every program can have its bugs but I think it's really clear why Borland tried to get rid of Delphi (and why it didn't succeed in doing so...)



  • @MET said:

    @LizardKing said:

    The line endings thing is more of a Windows WTF. In the Windows world, text files and binary files are distinct from each other - this is why FTP clients on Windows are legendary for buggering up files by "converting" them from binary to text format.

    And don't forget that Macs compound the problem by only using single LF characters rather than the single CR you get on unix.  A decent FTP client will usually warn you if you are using the wrong text/binary settings though.


    Um, you have that backwards. Unix uses LF, Macs used CR.

    It gets even more confusing than that, though. First, Apple started supporting Unicode, which means that there are programs which record Unicode line endings (which can mean the Paragraph Separator (U+2029) and Line Separator (U+2028) in addition to the old options and a couple of other new ones). Then came Mac OS X, which [i]is[/i] unix, but has an API called Carbon that allows you to recompile old Mac code with minimal changes, plus text support in the higher-level APIs is all via Unicode anyway. So you have:

    --> Old Mac programs that use CR
    --> Old Mac programs that use Unicode
    --> Carbon programs that use CR
    --> Carbon programs that use Unicode
    --> Unix output that uses LF
    --> Unix output that understands Unicode and uses Unicode
    --> New programs that use LF
    --> New programs that use Unicode

    The great simplifier for Macs is BBEdit (and the free-but-stripped-down variant, TextWrangler), which not only understands and auto-fixes line endings, but also lets you control which one you want (including the DOS/Windows form), and has a built-in FTP client for opening and saving files with the proper settings (that is, it encodes the file properly and sends it in binary mode). And you can either use the "Text Factory" option in BBEdit or the scripting support in either one to do a batch fixing of line endings. (I've done this in a couple of cases.)



  • @MET said:

    @LizardKing said:

    The line endings thing is more of a Windows WTF. In the Windows world, text files and binary files are distinct from each other - this is why FTP clients on Windows are legendary for buggering up files by "converting" them from binary to text format.

    And don't forget that Macs compound the problem by only using single LF characters rather than the single CR you get on unix.  A decent FTP client will usually warn you if you are using the wrong text/binary settings though.


    The solution where I work was to install a script on the CVS server that checks line endings on commit.  They have to be consistent throughout a given file or the commit is rejected and you have to fix it before trying again.  We do the same for tabs in source files after historical problems with mixed tabs and spaces.

    1)  Treating text files differently from binary files is not a Windows-ism.  FTP has two transfer modes - binary and text, and it's people who download binary files in text mode that have problems, regardless of operating system version.

    2)  Unix uses the LF character, not CR character (0x0a).  That includes the current MacOS.

    3)  There's nothing wrong with having separate carriage return and linefeed characters.  Using only the latter is a poorly-conceived attempt to reduce the size of text files, not the result of a sensible decision.  It's Unix and its derivatives that's screwed up, not DOS and its derivatives.  Consider that all Internet RFCs define line terminators as a CR/LF pair (0x0d0a), regardless of the operating system.

     



  • @Thanny said:

    1)  Treating text files differently from binary files is not a Windows-ism.  FTP has two transfer modes - binary and text, and it's people who download binary files in text mode that have problems, regardless of operating system version.

    If you are running a Unix platform instead of a Windows one, you will not have any problems with transfers that are not 7bit clean. This problem is entirely specific to Windows clients.

    (You may still have problems with transfers that are not 8bit clean, but if you do, for pity's sake stop using netkit-ftp - just about everything else gets this right)

    3)  There's nothing wrong with having separate carriage return and
    linefeed characters.  Using only the latter is a poorly-conceived
    attempt to reduce the size of text files, not the result of a sensible
    decision.

    You just made that up. It was never an attempt to reduce the size of text files. Shouldn't you be posting this kind of nonsense to slashdot?

    The fact that unix line endings just happen to use one of the two characters in Windows line endings is a fortunate coincidence. They have no common ancestry. Unix systems descend from systems that was created using character 0x0a as the line terminator, which was originally called "newline" in the old unix control code scheme. Later, this conviniently happened to coincide with the "line feed" character in ASCII. I can't remember the exact sequence of inheritance, but the Unix scheme descends from the EBCDIC world (which had CR and LF characters, but had a third "next line" character that was used as the generic line terminator - CR and LF had other purposes).

    Windows uses CR+LF because DOS did, which is generally believed to have inherited this behaviour from CP/M. CR+LF was originally used only on teletype devices, because the print head needed time to settle down after returning to the start, and inserting extra characters provided this time - it's a cheap hack, in other words.  It should be noted that the original teletype systems did not always store CR+LF in files, they just added it in the teletype driver where necessary. CP/M came much later and had no need to bother with this; there is some speculation as to why it did, ranging from mindless emulation of earlier teletype-based DEC operating systems, to a deliberate attempt to differ from the popular AT&T Unix in order to reduce the possiblity of lawsuits.

    But whichever way you look at it, Unix came first. You are full of shit.

    Consider that all Internet RFCs define line terminators as a CR/LF pair (0x0d0a), regardless of the operating system.

    This is done to ensure that all platforms see something that they consider to be a line ending. It is generally considered preferrable to give a line ending surrounded by noise rather than noise without any kind of line ending. It is a modern invention, which you will only find in relatively recent protocols, after the CR/CR+LF/LF issue became well-known. You should also note that all recent protocols indicate that clients should accept CR+LF or LF as line terminators, because programmers are used to writing "\n" in C and that only gives you an LF. Windows has a special hack in its stdio implementation to rewrite this into CR+LF, but stdio is not used with network sockets, so most Windows applications just send LF over the network - as a result, LF is the most common line terminator on networks in the real world.

    Ironically enough, it is the Unix applications which tend to send CR+LF over the network, because unix programmers are intimately familiar with the need to write \r\n when you want CR+LF. 



  • @KenW said:

    @Ragnax said:


    The hotfixes? BDS 2005 had three official updates and none of those really fixed any usability problems. Infact, installing update 3 on my machine actually toasted the help file and I had to use 3rd party tools to manually recompile and reintegrate it into the help system.



    Three official updates? There have been 9 hotfixes released, IIRC. Enough so that they bundled them into the hotfix rollup. And none of the hotfixes caused any problems when installed.



    [url]http://www.codegear.com/Downloads/RegisteredUsers/Delphi/tabid/150/Default.aspx[/url]
    I can see only three official updates from the codegear page. Where is this hotfix rollup? All I'm able to find is a hotfix rollup for Delphi 2006 (BDS 4.0), but none for Delphi 2005.


    @KenW said:
    @Ragnax said:


    It's also no wonder you're having little problems with BDS 2005; You're only loading the Delphi personality (and I assume only the Win32 one at that). Try loading the Delphi.NET one and see how well you fair. I can almost guarantee that your user experience will be less than satisfactory. Contrary to what Borland would probably like to tell you, cutting out over two-thirds of an expensive product (with a draconian license to top it off) does not constitute 'fixing the product'. (Actually, I bet it's even more probably they'd just try to shovel 2006 on you.)



    Where did I say that? I was discussing startup speed. Nowhere did I say I only use the Delphi personality (or Win32). I use all of the personalities (well, rarely the C++ - why punish myself?).



    You said it here:
    @KenW said:


    On my development machine (2GHz AMD Turion 64, 1GB RAM, 100GB HDD) BDS 2005 with [b]only the Delphi personality[/b] loading takes approximately 15 seconds to initially start; the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds.




    @KenW said:
    @Ragnax said:


    Startup time of the BDS IDE when using the Delphi.NET personality was approx. 1,5 minutes on my dev. machine (1.8GHz Pentium 4, 2GB RAM). Afterwards, opening a project of about 20kloc to work on would take an additional 15 seconds. This in contrast to VS 2005, which manages to start up perfectly fine in 25 seconds, including loading a project in the same order of size.



    Bull. If that's the case, you're running everything else on your machine simultaneously. I can load the full BDS 2005 (all personalities) in less than a minute, while VS Express takes about 2 minutes (I say about because I haven't timed it, so I'm approximating. I'll be glad to time it when I get back to that machine tonight, though.



    Actually, the machine in question wasn't running anything else at the time, apart from a resident antivirus guard. Maybe the difference lies in the version of Delphi 2005? The version I'd been running was Enterprise.

    @KenW said:
    @Ragnax said:


    Oh yeah, as for Code Insight, code completion, ctrl+spacing; It's true that it works a lot better on the Delphi-Win32 personality, but when using the .NET personality you can count on running into heaps and heaps of weird quirks.



    When will it start? I haven't experienced it at all yet (in over a year of using BDS 2005).



    I guess you got lucky, it is something with running a different version of Delphi 2005, its due to one of these mysterious hotfixes I'm not able to find through official channels, or its due to you working with Delphi 2006, instead of Delphi 2005.

     



  • @asuffield said:

    You just made that up. It was never an attempt to reduce the size of text files. Shouldn't you be posting this kind of nonsense to slashdot?

    [snip] 

    Windows uses CR+LF because DOS did, which is generally believed to have inherited this behaviour from CP/M. CR+LF was originally used only on teletype devices, because the print head needed time to settle down after returning to the start, and inserting extra characters provided this time - it's a cheap hack, in other words.  It should be noted that the original teletype systems did not always store CR+LF in files, they just added it in the teletype driver where necessary. CP/M came much later and had no need to bother with this; there is some speculation as to why it did, ranging from mindless emulation of earlier teletype-based DEC operating systems, to a deliberate attempt to differ from the popular AT&T Unix in order to reduce the possiblity of lawsuits.

    Now who's making stuff up?  CR & LF have clearly separate  functions on a teletype - both do what their names say.  CR returns the print carriage to the left margin.  LF moves the paper up one line.  They can be used independently - the standard way of printing bold on a teletype was to print the whole line, CR (without LF) and print just the bold parts again.  As well, I've seen a teletype used as a (very) poor man's chart recorder by issuing LF's and printing * whilst using space or BS characters to position the head right or left.  There *is* a built in delay in the original teletype standards (to allow the mechanism to cycle) but it's in the stop bits of the transmission protocol so is on a per-character basis, not per-line.

     
    Also, your reference to "stored files" and drivers in the context of teletypes is amusing.  Teletypes predate file storage in that sense although messages could be punched to paper tape. I don't think there was much discussion of print drivers in the 1920's when Teletype Corp started production.

    I don't really give a fig what format is used, as long as it's used clearly and consistently.

     



  • @CodeWhisperer said:

    @KenW said:

    the delay is caused by the fact that some of the refactoring support is provided using .NET, and the framework has to be loaded. If I immediately exit and restart it, the IDE starts in ~3 seconds. 

    The .NET CLR is spun up on a per process basis; if you stop the process (close the IDE) and re-start it, it still has to spin up the CLR again. It shouldn't incur a greater cost the first time, I don't think.

    -cw

     

    Wait a minute... that's not right. If another application has already loaded the CLR (which is likely, nowadays, since so many programs use it) it does not need to restart it - the CLR is a shared pool of libraries (otherwise every .NET program would consume 50-100MB of memory individually).  This especially applies if you have IIS/ASP.NET installed.  The only overhead should be loading any namespaces that no other program is using (which were likely unloaded when you closed the application in question)


  • @Ancient_Hacker said:

    Yep, I think it went waay downhill when they rewrote it in Java.  It used to  be speedy but now lags even on a 3GHz PC.

    ...

    Now you press help and it chugs for about ten seconds (Java starting up you know), then it pops up instead of the old useful paragraph or two, a sentence at most written by some clueless mouth-breather, no examples, no useful links sideways or up.  And most of the time it's talking about .NET or C++ similar concept, not the Delphi one.  If I'm in Delphi, writing Delphi code, why would I ever want a .NET or C++ help page?  Sheesh.

    What are you talking about?  There is no version of BDS written in Java.  None.  Never has been.  Never will be.  The Help system is ALSO not written in Java.  Never has.  Never will be.

    Let me address your misconceptions.

    BDS itself is (to my knowledge) written in C++ or whatever it used to be.  The overhead is that it now must load the .NET Runtime to work, as it needs it to provide certain IDE or development functionality.  I think that if you tell it not to load the Delphi for Windows Forms .NET functionality, it can dodge loading the CLR, but don't quote me on that.  Note that on my 3GHz P4 with 768MB memory, it loads in 15 seconds.  With Delphi for Win32, Delphi for Windows Forms .NET, and C# Builder (as well as the Jedi Code Library) all loaded.

    The Help System - Microsoft Document Explorer, is written in Unmanaged C++.  It takes a while to load due to the arcane file format of the Help collections, which must be decompressed before being displayed.  This is the same help system (written and provided by Microsoft, not Borland) that Visual Studio itself uses.

    Your post makes even Slashdot appear to be the paragon of truth. 



  • @Kyanar said:

    Wait a minute... that's not right. If another application has already loaded the CLR (which is likely, nowadays, since so many programs use it) it does not need to restart it - the CLR is a shared pool of libraries (otherwise every .NET program would consume 50-100MB of memory individually).  This especially applies if you have IIS/ASP.NET installed. 

    Nope.   The CLR is a COM component (MSCorWks.dll) which is loaded into each process that needs it, each instance is independent of each other.  Libraries are loaded once per instance (actually, once per AppDomain, but we won't go there).

    I'm not sure where you get 50-100 Mb, a test I just ran shows 7 Mb total memory for a minimal app,   The runtime DLL is 5.5 Mb.  Then you add the libraries, but unless you're adding every .NET library on your machine you shouldn't be getting close to 100 mb.

    -cw



  • @MET said:

    And don't forget that Macs compound the problem by only using single LF characters rather than the single CR you get on unix.  A decent FTP client will usually warn you if you are using the wrong text/binary settings though.

    Oh, it's really fun on OS X.  Programs that were written using the old-school Carbon API use 0x0D for line breaks, while programs using the Cocoa API use the Unix standard 0x0A. 



  • @petersod said:

    Now who's making stuff up?  CR & LF have clearly separate  functions on a teletype - both do what their names say.  CR returns the print carriage to the left margin.  LF moves the paper up one line.  They can be used independently - the standard way of printing bold on a teletype was to print the whole line, CR (without LF) and print just the bold parts again.  As well, I've seen a teletype used as a (very) poor man's chart recorder by issuing LF's and printing * whilst using space or BS characters to position the head right or left.  There is a built in delay in the original teletype standards (to allow the mechanism to cycle) but it's in the stop bits of the transmission protocol so is on a per-character basis, not per-line.

    That is true only for some teletypes. A lot of earlier models needed you to send multiple-character sequences, like CR+LF, or sometimes even CR+CR+LF or CR+LF+NUL+NUL, to give the print head time to settle. It should also be noted that there was a single EBCDIC control code for "move to the start of the next line", but they didn't use it for teletypes because it didn't give them enough time. That is the true origin of the CR+LF convention. The LF convention inherits from the parts of the industry that could and did use the single EBCDIC code instead.


    Also, your reference to "stored files" and drivers in the context of teletypes is
    amusing.  Teletypes predate file storage in that sense although
    messages could be punched to paper tape. I don't think there was much discussion of print drivers in the 1920's when Teletype Corp started production.

    Teletypes were in use for a considerable period when magnetic tape spools were the common storage system. A lot of early financial systems operated with that combination. Teletypes were used a lot over the years after the 1920s.

    Drivers came much later, but still overlapped with the use of teletypes. These are not "print drivers". These are terminal drivers. The most well-known terminal driver was called "getty" and is still in use today on most unix systems (although it usually talks to serial and virtual terminals rather than teletypes nowadays). One of its many tasks is to mediate the line-ending convention.



  • Speaking of Delphi, has anybody tried the Turbo offering? The IDE starts up pretty fast for me (~16 seconds), but that doesn't help much, since it needs about this long to get in an infinite loop of errors after I start typing... I'm keeping with 7 for now.



  • Tried it and ditched it as it didn't allow my third party components to integrate with the designer. For a language like Delphi, which is all about RAD, that just about kills its usefullness, possibly degrading it to those who wish to only experiment with programming or those who are taking classes on programming and require a first-time practical OO language. (Though I doubt those specific users could find their way through the forest that is the IDE's UI anyway.)
     


Log in to reply