dummzeuch

I do understand the basics of Git, I just don't like it and I don't like Github either. And as I am nearing retirement age, maybe I won't bother. Other things (from the application domain) are more important for my current job and if I lose that job, I'll probably retire early. Hm, maybe that could become a problem because I don't plan to stop developing software even when I retire, but probably no longer with Delphi (I don't want to pay that high price and the Community Edition is not a viable option either. Unfortunately other projects also follow that path.

The plug-in, that @Ondrej Kelle mentioned looks promising. You'd need to adjust the path which it checks for, but it shouldn't be too difficult.

He is not just talking about RTL or VCL files but about files in the search path, which as I read it includes the project search path e.g. possibly ..\libs\some\library\source Putting these into read-only folders is not feasible.

You mean that the registry settings under HKCU are not deleted because there are GExperts settings stored under that path, and because the installer detects that this path exists, it does not create the default settings for the IDE? I guess that's possible, but unlikely to cause that error message.

That's odd, because that assertion is in a destructor that is usually only called when exiting the IDE, not when starting it. The problem on exiting the IDE has already been reported several times. Please file a bug report on Sourceforge for this new problem.

No, it can't.

I can't speak for other people, only for me. And Github is the barrier for me, in particular because I don't use git, and that's because I don't see any advantage for me using it (people have tried to convince me and failed, so don't waste your time trying it again). So I'd have to start using git just to contribute to something on Github? Unlikely to happen.

That's exactly why I stopped contributing. Before the project moved to Github I had write access to the svn repository and could simply commit my changes, so for me the process has become much more complicated. Anders Melander has summed up the process on Github nicely.

What exactly do you mean by "include the sources"? If it is about not compiling the sources all the time, you could simply link precompiled dcu files. If it's about not having the compiled code in your executable, the best way is linking with packages, which has some drawbacks though. A DLL is the worst option as you would lose the ability to easily add those controls to your forms.

I'm not an active JEDI member either. I stopped contributing - as little as I did - when they switched do Github. Not sure how many active people are left in that project.

Nobody is looking at the issue tracker any more, I wouldn't be surprised if it turned out the admin sccount for it has been lost. But on the Github page things seem to be not quite so dead.

I have got to handle huge files which store floating point numbers between 30 and 200 with a precision of 3 decimal places. Currently the file format uses the floating point type Single for these numbers. Each requiring 4 bytes. Is there any way to reduce that memory requirement without sacrificing (or even improving) precision? My first idea was to: subtract 30, giving me numbers between 0 and 170 squash that into 2 bytes using the largest possible 10 based divisor Unfortunately that gives me only two decimal places with a divisor of 100 because 17000 < 65535 < 170000 Alternatively I could use a divisor of 200 which would fit into 2 bytes as 34000 but I would still lose some precision. I could use 3 bytes rather than 2 which would give me the required precision 170000 < 16777215 but would be awkward to handle. I could even reduce that to 18 bits with even more awkward handling involved. Any alternative ideas? Background: These files store the data of macro texture laser measurements in road condition surveys. There are 2x200 values for every 25 cm surveyed, giving me 2x200x4 values per metre plus some additional info for each dataset. While that isn't much when compared to the videos, this data will frequently be transferred via mobile internet (which in Germany means bl***y slower than in the average 3rd world country), while videos won't. I see two options here: Make the file format use less space without sacrificing precision Always compress and uncompress the files with some standard algorithm I'm not quite sure which way to go yet.

Yes. I never even thought about using tabs because they usually are a pain in the lower back everywhere.

These values are used for measuring the "macro texture". In the end they are combined into two numbers, the Mean Profile Depth (MPD) and based on that the Estimated Texture Depth (ETD). There is an ISO standard for the measurement and the (rather complex) calculation. Those numbers describe a part of what constitutes skid resistance of a road. And that's about structures that are nearly too small to see. The way to measure it requires 200 values measured in a line, no more than 1 mm and no less than 0.5 mm apart. For the calculation I need the full resolution of the laser, so any lossy compression is out. (One could argue that the algorithm loses most of that resolution anyway and that there is already a lot of noise in the data, but I have to adhere to the ISO standard.) The linked Wikipedia article describes quite a lot of what we do in road condition survey, just in case anybody is curious. We survey all autobahns and federal roads in Germany every 4 years, about 1/4 each year. On top of that there are the state roads and lesser roads, that should be surveyed once every 5 years. There are only a hand full of companies that offer this service. We are the market leader in Germany, but we are also active in Switzerland, Austria and France.

The code for the toolbar itself is in the aptly named unit GX_Toolbar, which can be found in the subdirectory EditorToolbar of the source directory. Since that is so obvious, I thought you were asking for more details, in particular since your question mentioned the icons.

I just had to look it up myself, so here is what I found: The code for registering the GExperts actions with the IDE is TGXActionBroker.RegisterActionWithIde in GX_ActionBroker. This method is called from .RegisterAction and .RegisterMenuAction which in turn are called from various places within GExperts. The bitmap to use as an icon is passed as a parameter to that method. so if you grep for RegisterAction and RegisterMenuAction you should be able to find where these bitmaps come from. Most of those bitmaps probably come from a call to GxLoadBitmapFromResource in GX_Utils, which loads these bitmpas from the resource file GXIcons.res (located in the images folder of the GExperts sources which is linked into the DLL. That resource file in turn is generated from the bmp files in the same directory. So I guess it would be possible to somehow manipulate these bitmaps when they are being loaded or load different bitmaps for dark mode. Not sure whether that covers all bitmaps though.

I just for the first time ever came across the warning "[DCC Warning]: W1013 Constant 0 converted to NIL". I got it for the following piece of code: var SomeList: TList; //... SomeObj := SomeList.Extract(0); // <== here WTF? I would have expected a compile error, not a warning because TList.Extract is declared as: function Extract(Item: Pointer): Pointer; inline; without any overload. I overlooked that warning a first, expecting an overload with an integer parameter (the index into the list like with Delete), which would make a lot of sense. (This is with Delphi XE2.) So apparently the compiler automatically converts the integer 0 to a nil pointer. Who (tf) considered this a feature? This is Pascal, after all, not C and is supposed to be type safe!

Hm, wasn't the point of the first post in this thread that FreeAndNil isn't big enough of a subject to make a whole video about? Two pages of discussion say otherwise.

So does the check for <>nil in .Free

I agree that it is a bug, but exactly because of this the issue can not be ignored.

Actually, obj.Free already checks for NIL, so the if statement is unnecessary. FreeAndNil also does something different than the name implies: procedure FreeAndNil(var Obj); var temp: TObject; begin temp := TObject(Obj); TObject(Obj) := nil; Temp.Free; end; (That's the old, non-typesafe version, if I remember correctly) So it should actually be called NilAndFree because it first sets the Object reference to nil and only then calls its Free method. That has some implications if there is code in the destructor / called from the destructor that references the object instance via the same pointer (which shouldn't be done but I have seen it been done.

The 13th (or even 14th in banks) monthly salary in Germany is no bonus, It is part of the regular salary and cannot be withheld if business is slow. It is usually paid with the November salary. It is kind of a tradition here. Personally I think that is kind of stupid. There isn't really any advantage in getting paid the yearly salary in 13 parts rather than 12, but apparently many people don't understand that and insist on it. Of course there are also contracts which specifically specify as a bonus (sometimes on top of the 13 monthly salaries), which in that case isn't considered a "13th monthly salary" but (guess what?) a bonus.

Taking it to work and having it lying around on your desk for a while might actually help when the time comes to renegotiate your salary. On the other hand, I have had some first hand experience with COBOL and I am sure that 15000 (US$?) is not worth the pain. My memory of COBOL is even worse than Visual Basic (the original one, not VB.NET, I don't know the latter).

One of my former coworkers started to call herself the Little Indian (she was of Indian descend and really tiny) after she heard one of the developers talking about little endian vs. big endian format. Somehow it didn't get old, we had a laugh every time she said that (the reason possibly was that we were drunk most of the time, playing Total Annihilation after office hours) Those were the days ...

You are aware that you are talking about 10th of a percent, aren't you? I doubt that that is even statistically relevant.