On Sat, Jun 30, 2018 at 10:54 PM, Florian Klämpfl
wrote:
> Afaik the mantissa function is defined like this for the records, yes. They
> do not include the hidden bit.
Hmm, then Rudy Velthuis is wrong (or Delphi).
I saw that my patch for the floathelpers caused a regression, see
Am 30.06.2018 um 18:19 schrieb Bart:
Hi Florian,
I do nut really understand why you return a mantissa with the highest
bit stripped off for type Extended.
From what I have gathered about 80-bit extended type the mantissa of
this type _is_ the full 64 bits, see
I'm trying to figure out how to fix bug 33914. This bug causes gdb to read
variable addresses
from flash, not RAM. Looking at the DWARF info, the address of a variable is
written as a word,
while gdb expects a prefixed address ($80 + address) to indicate a RAM
address, so the size
of the
Hi Florian,
I do nut really understand why you return a mantissa with the highest
bit stripped off for type Extended.
From what I have gathered about 80-bit extended type the mantissa of
this type _is_ the full 64 bits, see
http://rvelthuis.de/articles/articles-floats.html
Does Delphi strip
Am 29.06.2018 um 21:27 schrieb Thorsten Engler:
>>> [...] COM interface methods can't logically not be virtual,
>>
>> I think you are confusing things here. They can be virtual or not
>> virtual in COM and CORBA.
>
> I think a lot of people simply don't understand how interfaces are
>
On Sat, 30 Jun 2018, Willibald Krenn wrote:
Managed fields of records are "setup" ;)
I will add a section about this in the documentation, seeing that people
often confuse the 2 concepts.
In an ideal world, either the language would not let you write code that has
random behavior or the
Am 30.06.2018 um 12:02 schrieb Willibald Krenn:
Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
Von: "Michael Van Canneyt"
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
The variables we're talking about here *are* initialized.
Bit lost here. Maybe A and B are setup, but not
>Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
>Von: "Michael Van Canneyt"
>> Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
>>> The variables we're talking about here *are* initialized.
>
Bit lost here. Maybe A and B are setup, but not result. And the apparent re-use
of tmp vars also
On Sat, 30 Jun 2018, Maciej Izak wrote:
2018-06-30 8:55 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
No, the bad taste is too have a class that appears to be named
specifically to fit a specific third party project inside a general purpose
library.
Ok, I agree
Am 30.06.2018 um 09:52 schrieb Maciej Izak:
2018-06-30 8:55 GMT+02:00 Sven Barth via fpc-devel
mailto:fpc-devel@lists.freepascal.org>>:
No, the bad taste is too have a class that appears to be named
specifically to fit a specific third party project inside a
general purpose
On Sat, 30 Jun 2018, Maciej Izak wrote:
But not problem, please advise on the changes needed to a) fix the
mentioned example so it actually compiles.
b) Speed up the default hash.
I (or someone else) will be happy to change it.
Ok, but in the future you should ask for such important
2018-06-30 8:55 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> No, the bad taste is too have a class that appears to be named
> specifically to fit a specific third party project inside a general purpose
> library.
>
Ok, I agree here, but why Michael Van Canneyt decide
2018-06-30 8:33 GMT+02:00 Michael Van Canneyt :
> As noted in the bugreport, your own examples did not compile with your
> supplied code.
> Next time, please test that too.
>
The most important was to finish new collections, deep refactoring and
proper tests suite than testing all examples.
On Sat, 30 Jun 2018, Florian Klämpfl wrote:
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
Willibald Krenn mailto:willibald.kr...@gmx.at>>
schrieb am Sa., 30. Juni 2018, 08:01:
TBH, I didn't know this issue existed in Delphi and I've done my
share of Delphi over time. I
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
Willibald Krenn mailto:willibald.kr...@gmx.at>>
schrieb am Sa., 30. Juni 2018, 08:01:
TBH, I didn't know this issue existed in Delphi and I've done my share of
Delphi over time. I still maintain that
for managed types the
Maciej Izak schrieb am Sa., 30. Juni 2018, 08:16:
> Hi,
>
> renaming for TMormotHashFactory to TGenericsHashFactory is somehow
> acceptable (but IMO bad taste) but change for default hashing algorithm in
> such important library is really really really bad idea.
>
No, the bad taste is too have
Maciej Izak schrieb am Sa., 30. Juni 2018, 08:15:
> 2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org>:
>
>> - why is it that you adjusted DaThoX' copyright range, but not yours at
>> the top?
>>
>
> on the top is date of creation :) (it seems like standard,
Willibald Krenn schrieb am Sa., 30. Juni 2018,
08:01:
> TBH, I didn't know this issue existed in Delphi and I've done my share of
> Delphi over time. I still maintain that for managed types the compiler is
> responsible for some minimal initialization (like it's done for records
> etc, no?).
>
On Sat, 30 Jun 2018, Maciej Izak wrote:
Hi,
renaming for TMormotHashFactory to TGenericsHashFactory is somehow
acceptable (but IMO bad taste) but change for default hashing algorithm in
such important library is really really really bad idea.
As noted in the bugreport, your own examples
Hi,
renaming for TMormotHashFactory to TGenericsHashFactory is somehow
acceptable (but IMO bad taste) but change for default hashing algorithm in
such important library is really really really bad idea.
This was not consulted, change like that or proposition should be reported
here :
2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> - why is it that you adjusted DaThoX' copyright range, but not yours at
> the top?
>
on the top is date of creation :) (it seems like standard, but maybe I am
wrong).
--
Best regards,
Maciej Izak
2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
>
> Sorry that it took me so long, but I wanted to reread your proposed
> FastRTTI changes before deciding and I only found the time this evening.
>
> I'm currently indeed leaning towards option 2.
>
This is
Hi Jonas,
(Sorry for TOFU, I'm doing this from a web interface.)
First, how you implement things cannot dictate the semantics of the language. It is the other way around. Similarly and by analogy, Spectre/Meltdown for sure are bugs that need fixing and you don't treat them as features
23 matches
Mail list logo
