Re: [fpc-devel] FPC 3.0.2 release target

[tha...@thaddy.com]

New feature. Belongs in 3.1.1.

On 30-May-16 12:38 PM, Alfred wrote:

I would like to support the inclusion of interface RTTI.
Included a patch for this !
Thanks.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 release target

[tha...@thaddy.com]

It says fixed in 3.1.1. It doesn't say it would be back-ported, but 
indeed you can request it.
And indeed in this case I support your request. (Since it was an 
oversight in the first place?)

I have no clue if this is easy to do, but I think it is warranted.

Regards,

Thaddy

On 30-May-16 12:42 PM, Dejan Boras wrote:
Is there a chance to merge the fix for #29321 as well in 3.0.2? Last 
time I tested 3.0.1 (few days ago), this wasn't included. Not really 
in an environment now where I can test it again.




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] C flags, enums, sets, and the "Pascal way"

[tha...@thaddy.com]

Well,

h2pas gives you:
{$packrecords c}

  type
VkFlags = uint32_t;

VkSparseImageFormatFlagBits = 
(VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT := $0001,

  VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT := $0002,
  VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT := $0004
  );

VkSparseImageFormatFlags = VkFlags;



On 01-Apr-16 10:01 PM, Alcom wrote:


I'm working on some translated C headers for Vulkan for use in FPC.

In the vulkan.h header file, we have the following:

typedef uint32_t VkFlags;
typedef enum VkSparseImageFormatFlagBits {
VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT = 0x0001,
VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT = 0x0002,
VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT = 0x0004,
} VkSparseImageFormatFlagBits;
typedef VkFlags VkSparseImageFormatFlags;

For code maintenance purposes, it is desirable to have a header 
translation that is as close as possible to the source. A reasonable 
translation to Pascal of this might be:


TVkFlags = Cardinal;
TVkSparseImageFormatFlagBits =
(
VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT = $0001,
VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT = $0002,
VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT = $0004
);
TVkSparseImageFormatFlags = TVkFlags;


However, this solution has only the *illusion* of being strongly typed 
-- nothing about which the compiler is aware links TVkImageCreateFlags 
with the TVkImageCreateFlagBits.


A seemingly better solution (albeit incorrect) would be the following:

{$packset 4}
TVkSparseImageFormatFlagBits =
(
VK_SPARSE_IMAGE_FORMAT_SINGLE_MIPTAIL_BIT = $0001,
VK_SPARSE_IMAGE_FORMAT_ALIGNED_MIP_SIZE_BIT = $0002,
VK_SPARSE_IMAGE_FORMAT_NONSTANDARD_BLOCK_SIZE_BIT = $0004
);
TVkSparseImageFormatFlags = set of TVkSparseImageFormatFlagBits;

This will not give the expected results, because FPC interprets the 
enum constant as an exponent (or bit position, if you prefer).




My question is this: Is there currently a modifier for the set 
declaration that instructs the compiler to accept the enum values as 
literal constants, instead of interpreting them as exponents?


e.g. something like this:
{$EnumConstantsUseLiteral}
--or--
TVkSparseImageFormatFlags = literalset of 
TVkSparseImageFormatFlagBits;

--or--
TVkSparseImageFormatFlags = set of TVkSparseImageFormatFlagBits; 
literal;

--or--
TVkSparseImageFormatFlags = set of literal 
TVkSparseImageFormatFlagBits;




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Feature announcement: Record management operators

[tha...@thaddy.com]

You mean really,really,smart pointers and the introduction of the comma 
into the language?


On 07-Mar-16 3:37 PM, Maciej Izak wrote:
2016-03-07 15:34 GMT+01:00 Kazantsev Alexey >:



It's cool! What about Copy or CopyRecord?


Work in progress. Will be probably released together with smart pointers.

--
Best regards,
Maciej Izak


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

[tha...@thaddy.com]

I knew that... It is a suggestion to extend the syntax. Sven explained 
how it could work.


On 21-Feb-16 12:16 PM, Ewald wrote:


The first case will compile, the second will not, failing with a 
"Constant Expression expected". So, if you would somehow know the 
instance pointers at compile time, you might get away with it ;-)


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

[tha...@thaddy.com]

It is also about notational convenience. In that sense it belongs to the 
language level and not in the library domain.
And it is somewhat obvious to have. (I know I am not the only one who at 
some point in time was surprised you couldn't easily use instance 
pointers as ordinals)



On 21-Feb-16 11:58 AM, Maciej Izak wrote:


No much sense for me. Just use  dictionary, for example TDictionary 
from Generics.Collections (reminder for Sven ;P).




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

[tha...@thaddy.com]

That's exactly what I use (a dictionary) to circumvent this language 
limitation and use a case expressively.

I feel though, it is a limitation that could be solved.

On 21-Feb-16 11:58 AM, Maciej Izak wrote:


No much sense for me. Just use  dictionary, for example TDictionary 
from Generics.Collections (reminder for Sven ;P).




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

[tha...@thaddy.com]

Hi Nikolai,

Readability. A case is often much more readable, structured.
Extended else use tends to become less readable over multiple choices 
than a case.

I often wondered why my suggestion is not already possible.

Regards,

Thaddy

On 21-Feb-16 11:49 AM, Nikolai Zhubr wrote:

Hi,
21.02.2016 13:37, tha...@thaddy.com:



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Ability to handle instance pointers as ordinal type.

[tha...@thaddy.com]

I have been pondering with that idea ever since the implementation of 
strings for case.

This morning I remembered again why it may be useful.
Consider this code vs the alternative I suggest.
 Plz. do not value the code, it is just copied from the forum and 
frankly not the point but an illustration:


1.
   procedure TFrame00.ComboBoxChanged(Sender: TObject);
2.
   Var
3.
  x : TComboBox;
4.
   begin
5.
   If (Sender Is TComboBox) Then
6.
   begin
7.
  x := (Sender As TComboBox);
8.
9.
   case x.Name of
10.
   'ComboBox01':if x.ItemIndex = -1 then x.ItemIndex := PrjIndex else
11.
   begin
12.
   end;
13.
   'ComboBox02':if x.ItemIndex = -1 then x.ItemIndex := HubIndex else
14.
   begin
15.
   end;
16.
   'ComboBox03':if x.ItemIndex = -1 then x.ItemIndex := RimIndex else
17.
   begin
18.
   end;
19.
   'ComboBox04':if x.ItemIndex = -1 then x.ItemIndex := SpkIndex else
20.
   begin
21.
   end;
22.
   end;
23.
   End;
24.
   end;
25.
26.

 Now how much nicer it would be if you could write someting along the 
lines of:


1.
   procedure TFrame00.ComboBoxChanged(Sender: TObject);
2.
   begin
3.
   If Sender Is TComboBox Then
4.
   case TCombobox(sender) of
5.
Combobox1:;
6.
ComboBox2:;
7.
ComboBox3:;
8.
   end;
9.
   end;

In other words, use the instance pointer as an ordinal value.
It looks a lot more logical but as it stands it is of course invalid syntax.
Is it possible to implement?
If so, has it any value? To me at least it looks feasable and less like 
syntactic sugar than some features.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Supported start compiler for trunk

[tha...@thaddy.com]

Point duly taken. (But I knew)

On 02-Feb-16 5:53 PM, Sven Barth wrote:


Am 02.02.2016 14:51 schrieb "tha...@thaddy.com 
<mailto:tha...@thaddy.com>" <tha...@thaddy.com 
<mailto:tha...@thaddy.com>>:

>
> Yes. It is in the wiki. (Sigh)
> But there is an argument to be made to allow fixes branch.

No. Building of trunk will only be allowed with the latest release and 
for some time the one before it. This is not up for discussion. After 
all users want us to fix bugs and implement new features and 
optimizations and not hunt around why revision xyz of 3.0.1 can't 
build revision abc of trunk.


Regards,
Sven



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Supported start compiler for trunk

[tha...@thaddy.com]

Yes. It is in the wiki. (Sigh)
But there is an argument to be made to allow fixes branch.

On 02-Feb-16 11:54 AM, Alfred wrote:

While trying to build trunk, I encountered the following peculiarity.

Building trunk with 3.0.0 : ok.
Building trunk with 3.0.1 (fixes ios) : not allowed due to wrong version.
Building trunk with 3.0.2 (normal fixes) : not allowed due to wrong 
version.


Is there a reason why you can only build trunk with 3.0.0, and not 
with any 3.0 fixes ?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Random thread-safe

[tha...@thaddy.com]

The point is partially more or less at the end of the link I included. 
The reference to the Rdrand 


Which means software should take advantage of hardware when possible.
But it is about more than that.

And with due regards: the choice of the Mersenne twister over a Delphi 
equivalent one was made by about the same arguments I have now: it was 
better.


This is not that I disagree with your initial answers (also from Jonas) 
but to put things in an historical perspective.
You were both involved at the time the Mersenne twister was chosen , I 
believe. Correct me if I am wrong.


PRNG's are more and more important. They deserve extra effort even if it 
is not used for the compiler itself.
(It may very well be: when all software needs signing on all major 
platforms, which is tomorrow in IT standards)


Regards,

Thaddy

On 28-Jan-16 3:43 PM, Michael Van Canneyt wrote:



On Thu, 28 Jan 2016, Jonas Maebe wrote:



thaddy wrote on Thu, 28 Jan 2016:

Then wouldn't it be possible to make PRNG's  plugable. The Mersenne 
twister is still good as it is but definitely not suitable for every 
and any case. Marsialigla's might be a better choice nowadays.
And the seeding can nowadays often been done from reading hardware 
random, like on the Raspberry Pi.
e.g. 
http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/


The random number generator is just there as a general purpose tool, 
for TP/Delphi functional compatibility (not implementation 
compatibility, as we use a different PRNG). Unlike functionality such 
as the memory manager and code page conversions, it is not used by 
other parts of the language or RTL. As a result, there is no need to 
complicate the system unit by implementing a complete plugin 
infrastructure for this.


Indeed. You can just write and use your own random number mechanism if 
this is so

important. read /dev/urandom or so...

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Random thread-safe

[tha...@thaddy.com]

Then wouldn't it be possible to make PRNG's  plugable. The Mersenne 
twister is still good as it is but definitely not suitable for every and 
any case. Marsialigla's might be a better choice nowadays.
And the seeding can nowadays often been done from reading hardware 
random, like on the Raspberry Pi.
e.g. 
http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/


But that is not an exclusive.

Thaddy

On 28-Jan-16 1:30 PM, Jonas Maebe wrote:


Ondrej Pokorny wrote on Thu, 28 Jan 2016:

Regarding: http://bugs.freepascal.org/view.php?id=29526 (because I 
cannot answer on closed issues).


Also: the entire state of the random number generator consists of 
regular global variables, so it is not safe to use it from multiple 
threads in parallel.


Would it make sense to you to make random thread-safe? E.g. with the 
use of "threadvar" instead of "var" for the global variables in 
question?


No. The Mersenne twister has a lot of state (about 2KB). Duplicating 
this for every thread, along with associated slowdown, is not worth 
it. It's better to use a class that encapsulates the state of a random 
number generator and then instantiate this class for every thread.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Array of char

[tha...@thaddy.com]

@ Florian.

You closed the typecast from array of char to string issue.
Maybe you are right,
I just can prove that every d2-xe7 adds a #0, so a cast (partially, 
agreed) works in delphi and not in fpc.
I suggest you reconsider this. The raw pointer cast should work, which 
means an array of char should have a hidden terminator as well as a 
hidden pre.


With all respect,

Thaddy



smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Array of char

[tha...@thaddy.com]

No, it's about the KR compatibility.
That's all, nothing more, nothing less.
It has always been there for an array of char (old c style, now 
ansichar) ) in Delphi.


On 25-Feb-15 6:08 PM, Jonas Maebe wrote:

On 25/02/15 17:02, tha...@thaddy.com wrote:

@ Florian.

You closed the typecast from array of char to string issue.

http://bugs.freepascal.org/view.php?id=27530


Maybe you are right,
I just can prove that every d2-xe7 adds a #0, so a cast (partially,
agreed) works in delphi and not in fpc.

It's unrelated to the terminating #0. It's about the hidden length and
other metadata that is stored before the dynamic array and the string.
This data is not compatible in either FPC or in Delphi. Delphi happens
to store the length data in the same way, but other data for strings is
not present with dynamic arrays (as your own test in comment 0081403 shows).

If you were to pass such typecasted arrays to arbitrary Delphi routines
that expect ansistrings, you'll also get garbage results there in
certain cases (because of missing code page information, so arbitrary
data before the dynamic array will be interpreted as code page -- in
fact, in principle this can even cause crashes, in case the memory
coming before the dynamic array has not been mapped).

You'll probably also get memory corruption if you assign the result of
the typecast to an ansistring, then set the dynamic array reference to
nil (so the ansistring contains the last reference) and then set the
ansistring to an empty string (because Delphi will then probably try to
free a pointer that starts 16 or 32 bytes before the string data,
while in case of a dynamic array it starts fewer bytes before the array
data -- at least in FPC, but probably in Delphi too).


I suggest you reconsider this. The raw pointer cast should work, which
means an array of char should have a hidden terminator as well as a
hidden pre.

A dynamic array and an ansistring are two completely unrelated types.
There is no reason why an explicit typecasts between them should work.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Array of char

[tha...@thaddy.com]

My bad, hidden post #0

On 25-Feb-15 5:02 PM, tha...@thaddy.com wrote:

@ Florian.

You closed the typecast from array of char to string issue.
Maybe you are right,
I just can prove that every d2-xe7 adds a #0, so a cast (partially, 
agreed) works in delphi and not in fpc.
I suggest you reconsider this. The raw pointer cast should work, which 
means an array of char should have a hidden terminator as well as a 
hidden pre.


With all respect,

Thaddy



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] 64 bit ASM stack fixup code

[tha...@thaddy.com]

Hi,

I am trying to do some maintenance on the X86 intel assembler writer.

At the moment I am stuck on the .params nbr of params  macro that 
delphi supports.
Is there an easy way to fix up 64 bit code without having to write code 
that supports that macro?



Regards,

Thaddy



smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] For Stocki. Regarding interfaces.

[tha...@thaddy.com]

Oh, I see. Oeps.

On 26-8-2014 22:04, Sven Barth wrote:

Then why haven't you make up for it and put up the link? ;)

For the record, we are talking about this issue: 
http://bugs.freepascal.org/view.php?id=26602


Regards,
Sven





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] For Stocki. Regarding interfaces.

[tha...@thaddy.com]

Mm,

Marco, since you were the first one to put me right (and I was referring 
to block rsolution, which was false) I do not think - in the light of 
Danny's writings - that a {$modeswitch delphibugs} is appropriate. ;)


Anyway, I hope that this reconciles Stocki's thinking about the subject.

Delphi got it wrong FPC got it better (maybe not right, but close and 
better than delphi) conceptually.


On 27-8-2014 10:12, Marco van de Voort wrote:

In our previous episode, Sven Barth said:

And unless we have it somewhere black on white in the official
documentation we won't change anything there. And even then we'd likely
only do it for mode Delphi...

Make it a modeswitch then :-)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] New KOL 32/64 bit version 3.22 beta

[tha...@thaddy.com]

For those interested in smaller executables that perform the same as 
codebloated :-X  there is a new and up to date beta Key Objects 
Library available. Follow this link: 
http://kolmck.net/kol322-x64-unofficial.7z


It has been thoroughly tested during the summer and has become much more 
stable.


Works for FPC 2.6.4, 2.7.1, and all Delphi versions in32 bit and 64 bit.

Note:
If you want UNICODE, plz define -Mdelphi and -dUNICODE_CTRLS , NOT 
-dDELPHIUNICODE and/or -dUNICODE. This is because KOL had full unicode 
support before Freepascal and we use our own mechanism. That is not 
going to change.


In the final beta - due for release in October - we will add a 
comprehensive  example directory.


Regards,

Thaddy




smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] For Stocki. Regarding interfaces.

[tha...@thaddy.com]

Stocki,

Since your report was closed and I didn't fully (the closing) agree with 
that without research, here's a part of my research:


I found this reply by Danny Thorpe on stackoverflow:
http://stackoverflow.com/questions/7759081/is-the-compiler-treatment-of-implicit-interface-variables-documented/19914385#19914385

To quote:
I recall there have been a few bugs in this area over the years. Long 
ago (D3? D4?), the compiler didn't reference count the intermediate 
value at all. It worked most of the time, but got into trouble in 
parameter alias situations. Once that was addressed there was a follow 
up regarding const params, I believe./*There was always a desire to move 
disposal of the intermediate value interface up to as soon as possible 
after the statement in which it was needed, but I don't think that ever 
got implemented in the Win32 optimizer because the compiler just wasn't 
set up for handling disposal at statement or block granularity*/.


As you will see, the original intention by the Delphi architects was to 
release an interface as soon as possible.
The problem was**and is** that their compiler infrastructure doesn't 
allow that.

So the discussion on the buglist should be read in that context.

Even the designer of Delphi's interface implementation wished they were 
able to have a better implementation.

CUDO's to the Freepascal compiler guys for more or less achieving that ;)

You have to read it very carefully. It is not about the question, but 
about the *last part of the answer by Danny.**

*
I hope this sheds some new light on the matter that bothers you so much.

Regards,

Thaddy


smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] For Stocki. Regarding interfaces.

[tha...@thaddy.com]

Sven,
I made some mistakes here as well. About 20 years ago I knew what was 
going on.

I am sorry I didn't put the mail in the proper context.

Regards,

Thaddy

On 26-8-2014 21:55, Sven Barth wrote:

On 26.08.2014 17:27, tha...@thaddy.com wrote:

Stocki,

Since your report was closed and I didn't fully (the closing) agree with
that without research, here's a part of my research:


[...]

I hope this sheds some new light on the matter that bothers you so much.


Addendum: 
http://wiert.me/2014/08/06/delphi-using-iinterface-to-restore-cursor-at-end-of-mehod-prelude-to-a-memento-that-executes-any-code-at-end-of-method/

(look at the comments by me)

And unless we have it somewhere black on white in the official 
documentation we won't change anything there. And even then we'd 
likely only do it for mode Delphi...


Note: It would have been nice if you mentioned the issue which you are 
refering to. Not everyone has an eye on the bug tracker...


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel





smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to convert set to integer and vice versa

[tha...@thaddy.com]

You will find that if you are converting from a Delphi version equal to 
or before Delhi 2009, the {$Mode Delphi} or -Mdelphi directive does 
exactly what you want.


On 22-7-2014 3:37, Gennady Agranov wrote:

Hi,

I am new to FPC, but I do like it - thanks!

We are trying to switch from Delphi to FPC, but I am stuck with the 
following issue - in Delphi you can cast set to integer and get it 
back later - again by casting. In our case it is used for persistence 
purposes.


We have a lot of different set types - i really do not want to write 
set-integer converter for every set type we have :(


Actually I did find a way - I use ^ and @ and cast pointers,
but is there a way to write general set-integer converter in FPC 
that I do not have to worry whether it will work or not?


And what actually -CPPACKSET=0 does - documentation is not clear - at 
least for me :)


Thanks,
Gennady
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Method for write string into TStreamt

[tha...@thaddy.com]

A case for ternary computing is not really a bad idea ;)

On 21-7-2014 21:42, Hans-Peter Diettrich wrote:

Dmitry Boyarintsev schrieb:

How about introducing a default parameter?
The parameter keeps the method backward compatible, allowing write a 
string without the prefix.


public procedure TStream.WriteAnsiString(
  const S: string;
  withLength: Boolean = true;


How should a string without a length be read back?

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Method for write string into TStream

[tha...@thaddy.com]

You can always use KOL for that ;)
But anyway: we implemented that at the cost of read-back speed and 
looking for zero termination, which is flawed anyway for object pascal 
strings, since it can contain zero's.
It can be done through RTTI with my usual complaints about that sort of 
shit.


A (abstract) stream can not know if the length is stored or 
not...without rtti.


If you accept polymorhism this is not a good idea. I may be wrong (again)

On 21-7-2014 10:27, LacaK wrote:

Hi,
When I work with f.e. TFileStream I need often write string into stream.
Now I use:
 Stream1.WriteBuffer(s[1], length(s));

I think, that for convenience it will be useful having something like:
procedure TStream.WriteString(const s: string);
 begin
   WriteBuffer(s[1], length(s)*sizeof(char);
 end;

In FPC we now have for user convenience also WriteByte, WriteWord, 
WriteQWord (which all calls WriteBuffer)
and Delphi has lot of overloaded WriteData (but none of them takes as 
parameter string):


http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TStream.WriteData 



Do you think, that something similar can be added also in FPC ?
Thanks
-Laco.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to convert set to integer and vice versay

[tha...@thaddy.com]

Yes, Marco, as you previously suspected, It does.
I saw you gave already a similar answer to mine.

The pointer casts are definitely not necessary, Gennady.

Can you show a little example WHERE it doesn't work? In plain fpc, not 
lazarus code?



On 22-7-2014 18:13, Marco van de Voort wrote:

In our previous episode, Gennady Agranov said:

Good. And afaik in Delphi mode this works too in FPC? Did you test?


casting integer to set does not compile in FPC - and yes - I use Delphi
mode :(

program setcast;

{$ifdef FPC}
{$mode delphi}
{$else}
{$APPTYPE CONSOLE}
{$endif}

uses
   SysUtils;

type tenum=0..31;
  tmyset= set of tenum;

var x:integer;
 y:tmyset;

begin
   x:=integer(y);
end.

compiles in both FPC (both 2.6.x and trunk) and Delphi (XE4)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Method for write string into TStreamt

[tha...@thaddy.com]

What I was a little bit more than hinting at in my previous answers is 
that it is impossible for an abstract read stream to know that there's a 
string to read. There is at least one higher level of implementation 
necessary: one that recognizes a string.
That means probably something like  storing the length and  storing a 
string marker and/or use RTTI for strings, to be consistent.


In practice, I use json for that kind of streaming. And that is already 
in place.


On 22-7-2014 14:37, Dmitry Boyarintsev wrote:
On Tue, Jul 22, 2014 at 6:46 AM, tha...@thaddy.com 
mailto:tha...@thaddy.com tha...@thaddy.com 
mailto:tha...@thaddy.com wrote:


A case for ternary computing is not really a bad idea ;)

On 21-7-2014 21:42, Hans-Peter Diettrich wrote:

Dmitry Boyarintsev schrieb:

How about introducing a default parameter?
The parameter keeps the method backward compatible,
allowing write a string without the prefix.

public procedure TStream.WriteAnsiString(
  const S: string;
  withLength: Boolean = true;


How should a string without a length be read back?

DoDi

I didn't see DoDi's email anywhere in the thread, though it seems like 
there're two threads anyway:
Re: [fpc-devel] Method for write string into TStream and 
[fpc-devel] Method for write string into TStream


Anyways, answering DoDi's question.
It definitely won't be able to read a string without a size, but it 
doesn't mean that the string size should immediately precede the 
string content.

So maybe a modification like this could help

procedure TStream.ReadAnsiString(knownsize: Integer=-1)
   if knownsize0 then
 TheSize := ...readsize
  else
 TheSize := knownsize

thanks,
Dmitry


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Thank You Sven Barth

[tha...@thaddy.com]

Tnx Sven. I mean it, you know that.

On 10-6-2014 6:36, Sven Barth wrote:


Am 09.06.2014 20:07 schrieb Anthony Walter sys...@gmail.com 
mailto:sys...@gmail.com:


 Sven,

 I noticed you recently fixed many compiler issues which were in the 
bug tracker. I wanted give you a hearty 'Thank You' and let you know 
we appreciate your work.


They were mostly an instance of the same missing functionality (which 
can be seen when looking at my recent commits to trunk/tests), but 
you're welcome and thank you anyway ^^


Regards,
Sven



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel