Anders Melander

1 minute ago, pyscripter said:

RSP-23093 

That was the performance issue. RSP-14749 was the leak.

But as Dave suggested, the change in ComObj probably fixed both.

3 hours ago, pyscripter said:

The first VCS I used a long-time ago were CVS and FreeVCS (anyone remembers that?). 

Here's my VCS journey, as I remember it:

1994: MKS Source Integrity

1997: StarBase Versions & StarTeam, PVCS and CVS

1999: Borland TeamSource & Visual SourceSafe

2004 Borland StarTeam

2008 SVN

2018 Visual Studio Team Services

2019 Git

Of these VSS and VSTS were bad but PVCS was horrible. Borland TeamSource is best forgotten.

2 hours ago, Angus Robertson said:

I tried a git pull once, put me off Git for life, so complicated.

Reminds me of the time I tried to teach the great grandparents to use a mobile phone...

26 minutes ago, David Heffernan said:

Flashing can be quite visually aggressive.

Yeah. There's a reason we don't have <BLINK> in HTML anymore.

P.S. I just tried googling "blink html"... WTH? Do they think they're clever? Okay they're a bit clever because if you google "html blink" the result differs subtly.

9 minutes ago, Stefan Glienke said:

Consider GitLab - while the hosting offer is probably similar their entire CI/DevOps stack is superior to what GitHub offers. Especially for using a language like Delphi where you cannot simply use some cloud service to compile stuff.

Looks nice.

Do you know if they can also host the Gitlab runners or do you need to host those elsewhere? As far as I can tell, for a Delphi environment, I would need a runner running on Windows hosted on another platform (e.g. Azure) or a docker service running somewhere.

11 minutes ago, dummzeuch said:

What was I thinking?

8 minutes ago, Lars Fosdal said:

The organization wants us to switch from SVN to GitHub, but most of use have very limited experience with git - so it is a learning curve that I expect will yield some hard-earned experiences.

Coming from SVN I struggled for a long time with Git. Primarily because the terminology is different. Once I understood the terms properly it clicked and I haven't touched SVN since. Nor do I want to.

38 minutes ago, dummzeuch said:

the GUI tools I have tried are clunky compared to TortoiseSVN

I think you need to try some more then. There's always TortoiseGit. I have it installed but I very seldom use it. It just feels clunky compared to *everything else*.

41 minutes ago, dummzeuch said:

This works fine, most of the time, unless you want to rename a file, which apparently is not possible for whatever reason. 

One thing you need to be aware of is that in Git a file rename (or move) is is just a delete followed by an add.  So there is no move/rename per se.  That these two operations (delete+add) constitutes a move/rename is detected based on the content of the file. Therefore you should never rename a file and change the content in the same commit.

32 minutes ago, dummzeuch said:

the former top dog Slashdot

Slashdot? https://slashdot.org/

Did you mean SourceForge? https://sourceforge.net/

Also, there are plenty of other public Git sites besides Github.

14 minutes ago, Tommi Prami said:

I would think [...]? Maybe?
[...] or something like that.
But [...], don't know.

Are you sure?

4 minutes ago, Fr0sT.Brutal said:

But it could be a bug in RTL's wrapper

Yes it could. And before reporting it as such one should find out if it is.

5 minutes ago, Fr0sT.Brutal said:

zlib is used much more widely so such a critical bug would've been reported much earlier

That's not really a reliable metric to determine where a bug is located. Regardless, these kind of problems are regularly found in ZLib. Just try to search for "zlib loop" or go through the issue list at Github.

5 hours ago, Vandrovnik said:

I still believe that decompressor with wrong input should not enter an endless loop.

Yes, that's probably a bug.

I don't know if ZLib is supposed to be able to handle anything you throw at it gracefully but being a general purpose library I would think so.

We haven't seen the code that exhibits the problem or a sample of the data that causes it, so I'm hesitant to declare the problem a bug in ZLib or the Delphi wrapper.

4 hours ago, Fr0sT.Brutal said:

Anyway I think the problem MUST be reported to QC together with problem files because the issue is critical, it could cause DoS on any Delphi server.

If it's caused by a bug in ZLib then it would be a good idea to also report it at the ZLib repository: https://github.com/madler/zlib

I don't think Embarcadero is likely to fix bugs in ZLib.

13 minutes ago, A.M. Hoornweg said:

we still don't know if the data or the implementation is broken

That is not the purpose of the checksum. The purpose is to guarantee that the output is correct.

19 minutes ago, A.M. Hoornweg said:

If that were true, a non-matching checksum would mean a broken algorithm and not necessarily broken data. It would tell us exactly nothing.

I think the checksum is there to guard against a broken implementation. You can't validate the algorithm. Only the output it produces.

I'm not really sure what it is you're disputing.

2 minutes ago, Vandrovnik said:

I think decompressor should somehow handle wrong data too

Yes, if it's documented as doing so. It's perfectly acceptable to have an implementation that requires the input data to be valid. For example if you have already verified that the input data is valid elsewhere then you'd probably want the decompressor to not be slowed down with validating the data once more. At some point you have to assume that the input you're given is valid.

44 minutes ago, A.M. Hoornweg said:

This isn't foolproof because the decompressor can only verify that checksum after decompression.

Yes, you're right and it makes sense. The integrity of the data within a container is the responsibility of the container so the ZLib decompressor can assume that it's being given valid data and only uses its own checksum to verify that it is producing the correct output.

As far as I can see the fix suggested in RSP-9819 has already been implemented in DispatchInvoke (I checked D10.3).

The RSP-14749 issue looks more promising. I'm not sure why it was closed with the resolution "test case error" but since it's marked as fixed in 10.4.1 I compared the source of ComObj.pas and the only change in it is this (10.3.1 on the left, 10.4.1 on the right):

That does actually look like a fix for the issue in RSP-14749.

If you don't have 10.4.1 you can try patching the 10.3 ComObj.pas with the above change to see if solves the problem for you.

1 minute ago, Lars Fosdal said:

I feel for you

Yes, poor me. Crying all the way to the bank

Didn't anyone Google "zlib checksum"?

According to the ZLib specification there is a checksum: https://tools.ietf.org/html/rfc1950

Quote

ADLER32 (Adler-32 checksum)
This contains a checksum value of the uncompressed data
(excluding any dictionary data) computed according to Adler-32
algorithm. This algorithm is a 32-bit extension and improvement
of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073
standard. See references [4] and [5] in Chapter 3, below)

Adler-32 is composed of two sums accumulated per byte: s1 is
the sum of all bytes, s2 is the sum of all s1 values. Both sums
are done modulo 65521. s1 is initialized to 1, s2 to zero.  The
Adler-32 checksum is stored as s2*65536 + s1 in most-
significant-byte first (network) order.

Quote

A compliant compressor must produce streams with correct CMF, FLG
and ADLER32, but need not support preset dictionaries.  [...]

A compliant decompressor must check CMF, FLG, and ADLER32, and
provide an error indication if any of these have incorrect values.

1 hour ago, Stefan Glienke said:

Hundreds of lines of code within one routine and you think that *with* is the problem? LOL

That almost sounded like an insult but assuming that wasn't the intention; I didn't write the code but I've been tasked with maintaining, fixing and modernizing it.

with isn't the only problem but it's the one that makes refactoring the code a much harder task than it should have been - and it makes the code undebuggable. Among the other beauties in this code base are the local procedures; The above was actually found in a local procedure, several levels down. The top level method is a few thousand lines of pure horror.

Ummm. I must be missing some deeper meaning here but what is the point of pretending that an integer values isn't already stored in binary format? I mean, I could understand if you were trying to implement bin/dec conversion on a denary computer but other than that this sounds like an algorithm for people that doesn't have access to computers.

1 hour ago, pcplayer99 said:

This ca reduce typing.

I dnt knw bout u, bt I gt $ 4 the Q of my cde. Not for the amount of keystrokes I can save.

1 hour ago, dummzeuch said:

I can still do binary to hex and back in my head

You mean to say that you've memorized all the 16 hex digits? Wow

6 minutes ago, dummzeuch said:

Don't expect this to keep working in future Delphi versions.

I'm still hoping that with will be completely eliminated from the language.

Here's a few lines from the code I'm currently working on:

begin
  ...3-400 lines of code...
  with vPlan.DataController, dbSlaktePlan, BLPlan, Grupper ,Data[Id] do
  begin
    ...a few hundre lines more...
    with vPlan, BLPlan.SiteSum, Plans[Id] do
    begin
      ...and it goes on...

It seems to me that what you're describing is beyond the scope of localization and therefore BTM.

BTM is a localization manager/editor. It provides translations to the standard localization mechanism built into the Delphi RTL. If you're not using that, and it doesn't sound like it, then I can't see how BTM can meet your needs.

That said, the translated resource modules generated by BTM are just DLLs containing the translated resources (i.e. resourcestrings and DFMs). This means that you can use regular Windows APIs to load and extract the resources from these resource modules. It's also possible to hook into the resource loading mechanism and redirect the loading of selected forms to other resource modules. This could provide the multi-language capability. You could also just read the translation project file (it's XML) and extract the translations from there.

But, to be honest, none of the above sounds like a good path to go down.

Just now, A.M. Hoornweg said:

The VCL was strictly Ansi

Yes but that was not what you wrote.