Re: [fpc-pascal] The new Delphi 2010 RTTI

[Alex Shishkin]

As an example, your
proposal would imply that no external calls whatsoever would be possible
(including calls to external libraries due to them using different calling
conventions, etc.).

Tomas

By the way despite the fact that static linking to external libraries 
will be impossible, but dynamic linking could be implemented. Anyway I 
understand that platform independence of code imposes certain 
restrictions and that restrictions impact on application design. F.e. 
interface to external platform dependent systems should be isolated in 
separate package (as I wrote about LCL and its widget sets). But I think 
it makes design better.


Alex

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] The new Delphi 2010 RTTI

[Alex Shishkin]

10.01.2011 17:40, Jonas Maebe пишет:


On 10 Jan 2011, at 14:46, Alex Shishkin wrote:

By the way despite the fact that static linking to external libraries 
will be impossible, but dynamic linking could be implemented. Anyway 
I understand that platform independence of code imposes certain 
restrictions and that restrictions impact on application design. F.e. 
interface to external platform dependent systems should be isolated 
in separate package (as I wrote about LCL and its widget sets). But I 
think it makes design better.


What you are proposing is something similar to Google Native Client 
(http://code.google.com/p/nativeclient/), except that they also added 
code verification because it's intended for running native 
applications downloaded from websites.

Interesting link. Thanks.


That is not directly related to packages, but rather to a completely 
new run time environment with its own ABI, object format etc. 

object format is the main question as for now.
The result of having such an environment is indeed that you can have 
compiled binary code that is portable across different operating 
systems, but that's outside the scope of adding packages support to FPC.

OK


You first have to define such a platform (or you can take the Google 
Native Code platform), then add RTL and compiler support to FPC for 
that platform, and subsequently any program or package compiled for 
that platform by FPC will run on it. Reinventing such a platform and 
embedding it in FPC and its run time library falls outside the scope 
of the FPC project.


Yes, my implementation of packages planed to be just a platform from the 
compiler side. So then "native" support of packages will be added in FPC.


Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] exports VS export

[Alex Shishkin]

what is the difference between "export" proedure/function modifier and 
listing this routine in "exports" section?
On win32 with fpc 2.4.3 i've got a crash on program start then using 
export modifier in statically linked dll.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] exports VS export

[Alex Shishkin]

18.01.2011 15:34, Jonas Maebe пишет:


On 18 Jan 2011, at 13:27, Alex Shishkin wrote:

what is the difference between "export" proedure/function modifier 
and listing this routine in "exports" section?


In theory, they should mean the same.

In practice, FPC currently only actually exports routines that are in 
the "exports" section of a library, or that are marked as export *and* 
that have been (re)compiled during the current compilation run (i.e., 
that were not compiled previous compilation and simply loaded from a 
.ppu file). See http://bugs.freepascal.org/view.php?id=16070



Jonas


Following code crashes if disable define use_export_section.

library lib;

{$mode objfpc}{$H+}

uses
Classes
{ you can add units after this };

{$R *.res}

{$define use_export_section}

procedure PrintHello; {$ifndef use_export_section} export; {$endif}
begin
WriteLn('Hello world');
end;

{$ifdef use_export_section}

exports PrintHello;

{$endif}

begin
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] exports VS export

[Alex Shishkin]

18.01.2011 22:28, Jonas Maebe пишет:

What do you mean by "crashes"? A segmentation fault? If so, where exactly does it crash? 
And how do you import that routine in the program and call it? Currently, the "export" 
modifier apparently does not add an alias for the unmangled name, so I'm not sure how you are even 
getting things linked successfully.

Attempt to run with static linking crashes debugger. Dynamic linking 
simply failed. So I ask what does modifier "export" actually do?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] exports VS export

[Alex Shishkin]

18.01.2011 23:08, Jonas Maebe пишет:

On 18 Jan 2011, at 20:46, Alex Shishkin wrote:


18.01.2011 22:28, Jonas Maebe пишет:

What do you mean by "crashes"? A segmentation fault? If so, where exactly does it crash? 
And how do you import that routine in the program and call it? Currently, the "export" 
modifier apparently does not add an alias for the unmangled name, so I'm not sure how you are even 
getting things linked successfully.


Attempt to run with static linking crashes debugger.

You posted the source to a library. It is not possible to run a library. So 
again: what is the program that you wrote that imports that routine and how did 
you import that routine in that program?

Additionally, afaik FPC does not currently support creating statically linkable 
libraries. So how did you statically link a compilation unit that starts with the 
"library" keyword into a program?

I meant using "external 'lib.dll' "

Dynamic linking simply failed

What is the error that you got?

"procedure could not be found"

So I ask what does modifier "export" actually do?

a) it makes the routine's symbol public, so that it can be referenced from 
other object files
b) for the OS/2 and EMX targets, it also adds the routine to the "deffile" (I 
don't know the details about that)


clear thanks.

Alex.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] fgl.TFPGMap

[Alex Shishkin]

Following code causes error "Operator is not overloaded: "TObject" < 
"TObject""

How to make it work?

program generictest2;
{$mode objfpc}{$H+}
uses
  fgl;
operator < (a: TObject; b: TObject): boolean;
begin
  result := PtrInt(a) < PtrInt(b);
end;
type
  TMyMap = specialize TFPGMap ;
begin
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap

[Alex Shishkin]

20.01.2011 22:18, Honza пишет:

2011/1/20 Alex Shishkin:

Following code causes error "Operator is not overloaded: "TObject"<
"TObject""
How to make it work?

program generictest2;
{$mode objfpc}{$H+}
uses
  fgl;
operator<  (a: TObject; b: TObject): boolean;
begin
  result := PtrInt(a)<  PtrInt(b);
end;
type
  TMyMap = specialize TFPGMap;
begin
end.

AFAIK TFPGMap can be specialized only with types which have the
relational operators predefined by the compiler. See also:
http://bugs.freepascal.org/view.php?id=15480
As I understand problem is in the compiler. It cant use overloaded 
operator if it was defined after generic.

BTW this code compiles successfully.
program generictest2;
{$mode objfpc}{$H+}
operator > (a: TObject; b: TObject): boolean;
begin
  result := PtrInt(a) > PtrInt(b);
end;
type
  generic TComparator  = class
class function Compare(a,b:T): Integer;
  end;
class function TComparator.Compare(a, b: T): Integer;
begin
  if a>b then
Result := 1
  else if b>a then
Result := -1
  else
Result :=0;
end;

type
  TObjectComparator = specialize TComparator;

begin

end.
Data can be any type  but Key only "native comparable". If drop 
TFPGMap.KeyCompare along with DataCompare leaving only custom comparison 
it will work with any Key type.

You can take a look on this container lib, which might be helpful for your task:
http://code.google.com/p/fprb/wiki/heContnrs

Good lib, but Lazarus codetools does not support  nested classes as for now.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: fgl.TFPGMap

[Alex Shishkin]

21.01.2011 0:26, leledumbo пишет:

Another good one:  http://code.google.com/p/stlpascal/ STLPascal
Uses pattern commonly used by C++ STL, but fortunately written in a much
more readable way. It has more data structures than heContnrs, but missing
the BTree implementation. Really, IMHO somebody's got to merge all of these
libraries (including fgl).
stlpascal released under GPLv3 but fpc libraries under modified LGPL. If 
stlpascal will change license to modified LGPL it will be good to see it 
in fcl.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap

[Alex Shishkin]

21.01.2011 3:07, Paul Ishenin пишет:

21.01.2011 0:28, Alex Shishkin wrote:
Following code causes error "Operator is not overloaded: "TObject" < 
"TObject""

How to make it work?

program generictest2;
{$mode objfpc}{$H+}
uses
  fgl;
operator < (a: TObject; b: TObject): boolean;
begin
  result := PtrInt(a) < PtrInt(b);
end;
type
  TMyMap = specialize TFPGMap ;
begin
end.

Please report this bug to the tracker.

Best regards,
Paul Ishenin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Also please see http://bugs.freepascal.org/view.php?id=18573, this 
related with generics to.

Alex
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TField.Attributeset explanation?

[Alex Shishkin]

05.09.2011 12:30, michael.vancann...@wisa.be пишет:



On Mon, 5 Sep 2011, Reinier Olislagers wrote:

That is normal.

Just set the 'Required' property of the CUSTNO field to False.

Forget the 'Attributeset' property. It's not used in FPC.

(in fact, I don't even know what it's for or where it comes from)

Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/DB_TField_AttributeSet.html
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work

[Alex Shishkin]

06.10.2011 16:37, Reinier Olislagers пишет:

On 4-10-2011 14:41, Reinier Olislagers wrote:

On 4-10-2011 13:14, Marco van de Voort wrote:

In our previous episode, Reinier Olislagers said:

Having some trouble creating patches that actually work.
(On Windows)
I've been using git to get FPC trunk and
git diff --no-prefix>  %temp%\mypatch.diff

I don't know about GIT, but some tips:

1. Play with lineending.  (I use cygwin's dos2unix and unix2dos to convert)

Ok, I've looked at it some more:
Example:
packages\fcl-extra\src\win\ServiceManager.pas

svn:
via web:
http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-extra/src/win/ServiceManager.pas
=>  Unix line endings
Local svn:
svn proplist -v packages\fcl-extra\src\win\ServiceManager.pas
   svn:eol-style
 native
so:
=>  WINDOWS LINE ENDINGS
Therefore patch.exe on Windows probably works

Git:
https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas
=>  Unix line endings
via git pull etc
=>  Unix line endings
not surprising...

Seems the SVN client is converting line endings to my native format.

Seems also that there is no way to get git to convert remote LF to local
CRLF...


Should I give up on git and just switch to SVN?

I'm sure some more knowledgeable/alert person will have a suitable answer!

Thanks,
Reinier
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



there is git config option "core.autocrlf" try to use it
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work

[Alex Shishkin]

06.10.2011 18:59, Reinier Olislagers пишет:

Thanks Alex, I already fiddled with that. I'll try again with
core.autocrlf set to true and false to make sure it doesn't work...

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


not "true" not "false", but "input". Read this if have not yet : 
http://progit.org/book/ch7-1.html http://help.github.com/line-endings/

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work

[Alex Shishkin]

06.10.2011 19:15, Graeme Geldenhuys пишет:



As far as I know, Git will only do the conversion when you clone a new
repository, or when you pull new changes. If you had the setting wrong
at the time you did the clone, the problem is on you. Simply change
the setting, and get another clone (use --depth if you don't want a
full clone again)




No, git do conversion on checkout and commit.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git line endings leading to patch problems - was [Semi-OT] Git format patches don't seem to work

[Alex Shishkin]

06.10.2011 22:41, Reinier Olislagers пишет:

On 6-10-2011 17:04, Alex Shishkin wrote:

06.10.2011 18:59, Reinier Olislagers пишет:

Thanks Alex, I already fiddled with that. I'll try again with
core.autocrlf set to true and false to make sure it doesn't work...


not "true" not "false", but "input". Read this if have not yet :
http://progit.org/book/ch7-1.html http://help.github.com/line-endings/


Alex&  the rest, seems I'm doing something wrong when using input:
rem go to right directory:
cd /d c:\development\fpc\
rem get rid of any gunk there:
rmdir /s /q source
rem set autocrlf to input for entire git system
git config --global core.autocrlf input
rem check setting - yes, input:
git config --global core.autocrlf
input
mkdir c:\development\fpc\source
cd /d c:\development\fpc\source
git clone --depth 5 git://github.com/graemeg/freepascal.git .
rem check situation here - yes, still input:
git config core.autocrlf
input
rem now use notepad++ to open a file:
npp packages\fcl-extra\src\win\ServiceManager.pas

!!!notepad++ shows it has Unix line endings
Could be that I'm misinterpreting the docs/sites, but isn't input
supposed to convert the LFs in the repository to CRLFs?

Tried again using core.autocrlf true, this does result in Windows line
endings.
Creating a patch using git diff --no-prefix gives Unix line endings - as
expected, really.
So while it could be used, I'd have to remember to run unix2dos over it
- that is, if people expect a Windows patch (

Am I doing something stupid with autocrlf input?

Thanks,
Reinier
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



Sorry, my mistake. In your situation "autocrlf yes" should be used.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Any command line interpreters for Free Pascal?

[Alex Shishkin]

15.10.2011 2:25, Andrew Pennebaker пишет:

E.g., if fpi existed, I would add a shebang like this to my code:

#!/usr/bin/env fpi

Cheers,

Andrew Pennebaker
www.yellosoft.us 


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
There are some interpreters for object pascal, f.e. RemObject Pascal 
Script, DWScript. It`s easy to make command line interpreter based on 
one of them.


http://wiki.freepascal.org/DelphiWebScript
http://wiki.freepascal.org/Pascal_Script

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal