[fpc-devel] Snapshot x86_64-linux is not valid
Hi snapshot fpc-2.7.1.x86_64-linux.tar.gz ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/x86_64-linux/fpc-2.7.1.x86_64-linux.tar.gz is not valid, build is from 4/1/2014 but packages 28/12/2013 and compiler complains Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Even if KSD or now FireMonkey supports ARM Linux this does not mean anything for Android. While Android does support native Linux applications it does not have a X server. Currently the only possibility for this is to run a X server through a VNC viewer and thus you can not reproduce the usual feel of an Android application. I prefer other approach. My application have webapp with embedded http server, crosscompiled to ARM as Android library Whole GUI act in webview (http://developer.android.com/reference/android/webkit/WebView.html ) Only small Jni is needed to loadlibrary For me browser has more capabilities than native widgets. With full css3 support i can use gradient background, rounded corners etc. HTML5 today is most powerful attempt to GUI : fast,full-featured, multiplaftorm, OS agnostic, And more important for me: the same code I can use on several OS: Android, WebOs, Linux, Windows, .. iOs ( I hope that FPC will be able to crosscompile to iOs soon), server can be embedded or standalone It work on toy tablet with android 2.1 and Samsung Galaxy , then same as on desktop computers. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
And more important for me: the same code I can use on several OS: Android, WebOs, Linux, Windows, .. iOs ( I hope that FPC will be able to crosscompile to iOs soon), server can be embedded or standalone This might not be possible from non Apple targets, because of Apple's licence restrictions (the OS X users might be able to tell more regarding this). If you have a OS X and the iPhone SDK this is already possible... I count on it. Purchase machine with OS X is not problem, when I come around than my source will work. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Declare variables inside the code
W dniu 2011-05-11 11:39, Joerg Schuelke pisze: Am Wed, 11 May 2011 10:21:45 +0200 (CEST) schrieb mar...@stack.nl (Marco van de Voort): FPC is much lighter on that, and never runs constructors automatically. It only initializes some pointer values to NIL. So you'll have to explain that remark in more detail. _ Yes, today. What I mean is that one decision leads to an other. 1. You decide it is nice to declare variables where you need them. 2. You find out that it is better practice to define every variable where you can initialize it, so that every var fulfills the assertions from her type, during the live time . I agree, but in different way. I'd like see pascal more declarative than imperative, and not make statement from declaration. Initialization connected with declaration looks good and we can move then to the declaration section. For example procedure foo; var t : tMyObject(); begin t.myProc; end; that can be equivalent to: procedure foo; var t : tMyObject; begin t:=tMyObject.create(); try t.myProc; finally t.free; end; end; This proposition is not only shorter, more security and possible to achieve. There are some things with similar behavior like interfaces, strings: they are initialize before begin statement and finalize after end. Also some gain of speed can be achieve: this object can be allocate on stack, which is faster. And second: some virtual calls can be resolved and inlining. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Android native application with local webserver
W dniu 2011-04-14 09:38, Michael Schnell pisze: On 04/13/2011 11:11 PM, dar...@emadar.com wrote: Hello I finish first stage to move my webapp as native Android application. Its consists one java file with declaration webWiew, and all rest, written in FPC, is build as library. Of course start is thought jni, but after that http server (based on Synapse) is started, and build in browser can play with them. Sounds great. So your way to overcome the native-code - user interface barrier on Android is to make the apllication a web server and access it via the browser ? yes, this is the same application as for linux or windows I understand the executable has a built-in web server, so it is _not_ a CGI. Correct ? yes Did you already succeed in managing the usual obstacles of this: creating timers, yes notifying the main thread from worker threads, yes doing application initiated active user notifications on the web-page ? I'm not sure I understand when I need this, web page (by Javascript) sequentially ask server -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Android native application with local webserver
W dniu 2011-04-14 11:35, Michael Schnell pisze: On 04/14/2011 10:36 AM, Dariusz Mazur wrote: Did you already succeed in managing the usual obstacles of this: creating timers, yes Great ! How ? What is the problem when pthreads works? notifying the main thread from worker threads, yes Great ! How ? server work in own thread, each request in own, each session (whole application for one user) in own communication between request thread and session threads are done via FIFO queue my old demo webapp http://www.emadar.com/fpc/xwebdemo.zip doing application initiated active user notifications on the web-page ? I'm not sure I understand when I need this, web page (by Javascript) sequentially ask server This is what I meant. So you do polling in the Java script, killing the performance of the whole device. There are Java script based algorithms (such as Comet) that might or might not help and might or might not introduce additional problems. I don't think so But when browser send request, server don't response at now, only wait 30s and then (if its nothing to respond) send message to browser with order to repeat request. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Android native application with local webserver
W dniu 2011-04-14 16:08, Michael Schnell pisze: On 04/14/2011 02:55 PM, Dariusz Mazur wrote: What is the problem when pthreads works? In fact this supposedly is a Lazarus LCL problem, so we might be in the wrong discussion group here, The LCL's Application object defines a main thread, that allows for event driven programing (the program flow stalls after the initialization using (close to) 0% CPU and e. g. TTimers fire main thread events that are queued in an Event Queue and handled one after the other as soon as possible when the time of one has come (waking up the main thread at this point). Now the LCL provides the code that does this in (some of) its Widget Type- (aka interface-) implementations. There are several of those, but only those with a GUI binding do provide event driven programming. (Otherwise you could use a noGUI one for doing a kind of WebGUI). To allow for decent thread programming in an environment with event driven programming, the threads need to be able to notify the (event driven) main thread by firing queue-able main-Thread events. This can be done by stuff like TThread.Synchronize (defined in the RTL, but needs the help of the LCL or whatever ), TThread.Queue (not yet implemented, but available in Delphi), Application.QueueAsychCall (implemented in the LCL), and PostMessage (Windowish stuff, but quite decently cross-platform - implemented in the LCL). I've implement message queue (like in Windows), also VCL/LCL style communication with widgets. TThread.synchronize was reimplement, because there is many Main thread - per each session. All enough to use the same source do build desktop and web application. server work in own thread, each request in own, each session (whole application for one user) in own communication between request thread and session threads are done via FIFO queue So the Server is the Main Thread, No , I mean this is main thread of listen socket which is supposed to do most of the Office Logic work, office logic and changes in used widgets (controls) is done in session thread, and when computing if finished, request thread prepare response, based on new state of visible widgets, there are mutexes, to coordinate flow between this two threads. including handling the TTimer events. IMHO, it's not a good idea top do the Office Logic stuff directly in the threads that are fired by the single requests, as this will ask for huge problems with mutual access of commonly used data, which the user does not really want to handle with a great count of CriticalSections or similar synchronization stuff. I feel that it would be good to have the requests transformed to main Thread Events, so that a normal (= not thread aware) user is able to do the programming seeing only a single thread. In my attempt single session (like desktop application) work in own thread. In session can be use inner threads, events, modal windows etc. similar like in desktop. I don't think so But when browser send request, server don't response at now, only wait 30s and then (if its nothing to respond) send message to browser with order to repeat request. OK. If the program works only on request and the java code does a long sleep, the CPU use will be decently low. But of course this will not provide a very agile experience to the user. Why. When server want to push to browser response earlier (response took less than 200ms including ping), when browser (user) want ask, then send new request, no one wait -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] XMLCFG AnsiStringDOMString conversion
W dniu 2010-11-05 11:52, Felipe Monteiro de Carvalho pisze: On Thu, Nov 4, 2010 at 7:51 PM, Dariusz Mazurdar...@emadar.com wrote: then I have a question : how to change current code page I say wrong: how to change code page used to implicit conversion ansistring- wide string You shouldn't. If you want to convert between code pages, then the I don't want, but there is implicit conversion ansi-wide, inside xmlcfg, depend on current code page. I assume, that this code page depend from OS, but this is bad for me, I need to control how chars are translated, because program can be use on different machines. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] XMLCFG AnsiStringDOMString conversion
W dniu 2010-11-03 23:50, Sergei Gorelkin pisze: dar...@emadar.com пишет: When I using xmlCfg unit i found problem with storing literals in arbitrary code page. XMLCfg perform automatic conversion with omit some chars. I've change it to use utf8string instead of. Maybe this patch will be interesting. Such patch will make all existing config files with non-ascii data unreadable. Today also. All nonasci charracter are translate to '?' during reading (implicit conversion widestringansistring). On other side in XML should not be not asci char In the meantime, I wrote the xmlconf unit exactly to avoid this problem. So if you need Unicode configs, you should switch to xmlconf. Calls to Utf8Encode/Decode will be still necessary because xmlconf.TXMLConfig has WideString parameters, but it won't strip any non-ascii data. XMLCfg is enought to me, but then you should add note that this unit is depreciated -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] XMLCFG AnsiStringDOMString conversion
W dniu 2010-11-04 17:44, Marco van de Voort pisze: In our previous episode, Dariusz Mazur said: interesting. Such patch will make all existing config files with non-ascii data unreadable. Today also. All nonasci charracter are translate to '?' during reading (implicit conversion widestringansistring). On other side in XML should not be not asci char This is not the same, current all chars in the current codepage (also above 127) will be fine. Only the ones NOT in the current codepage will turn up as '?' If you change to UTF-8, this will change. then I have a question : how to change current code page -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
W dniu 2010-10-22 23:30, Florian Klämpfl pisze: Am 22.10.2010 23:17, schrieb Dariusz Mazur: full source in attachment (should I prepare it different?) The best would be a diff against compiler sources. OK. First I find better computing of hash. My is slight worse than current (but overall faster) Second: when I review assembler list I've notice some strange lines (all optimizations are enabled): Which compiler version? 2.4.x? I think r15502 in trunk should fix this. 2.5.1 but older. Now I test from current. Its better (faster) but I found other strange: first: dec(i) is translate to three lines movl%esi,%eax decl%eax movl%eax,%esi why not simple decl %esi ? When variable is in %ebx things are the same. second if I have: while ii0 do begin ; dec(ii); assembler look: # [121] while ii0 do begin jmp.Lj16 // here add first test of ii .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); movl%esi,%eax decl%eax movl%eax,%esi .Lj16: testl%esi,%esi//-- this can be avoid, because test from DECL jg.Lj15 Is this possible to achieve this optimizations, If yes, can somebody help, from which file I should start -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
W dniu 2010-10-23 23:04, Florian Klämpfl pisze: Second: when I review assembler list I've notice some strange lines (all optimizations are enabled): Which compiler version? 2.4.x? I think r15502 in trunk should fix this. 2.5.1 but older. Now I test from current. Its better (faster) but I found other strange: first: dec(i) is translate to three lines movl%esi,%eax decl%eax movl%eax,%esi why not simple decl %esi ? Yes. I saw this too and I didn't find the cause, especially because I were not able to reproduce it in a small example. attached before uhlm.pas is too long? its form fpHash When variable is in %ebx things are the same. second if I have: while ii0 do begin ; dec(ii); assembler look: # [121] while ii0 do begin jmp.Lj16 // here add first test of ii .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); movl%esi,%eax decl%eax movl%eax,%esi .Lj16: testl%esi,%esi//-- this can be avoid, because test from DECL jg.Lj15 Is this possible to achieve this optimizations, If yes, can somebody help, from which file I should start Replacing the jmp by a test and jz is two-fold: it increases code size (thus higher code cache pollution) and it pollutes the branch prediction unit while an uncoditional jump is very cheap on modern processers. You don't understand me My proposition is moving one instruction, outside loop # [121] while ii0 do begin testl%esi,%esi//-- this should be added, because after .Lj16 test is absent jmp.Lj16 // jmp not change ZF .balign 4,0x90 .Lj15: .Ll8: # [122] result:=LongWord(result *8010817 ) xor (Pw^); .Ll10: # [124] dec(ii); decl%esi .Lj16: jg.Lj15 // ZF is setting by decl (first timie by testl) -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TFPHashList (Was: Alternative parsers)
Benchmarking included 3*10^6 calls to Add and Find methods
with the arguments of various lengths.
Average string length 5 characters:
ShortString: 1.15 s
AnsiString: 1.56 s
Average string length 45 characters:
ShortString: 12.0 s
AnsiString: 3.2 s
I agree that the first case is more relevant for the compiler,
but still you can see that ShortStrings are clearly not always faster.
Sure, see attachment.
Note that I made shortstring-ansistring text replacament
followed by minimal fixed to get working Add and Find methods.
Other methods may be broken as a result.
I've done some some optimizations of tFPHashList and results are (for
10^6 calls average length 30 characters):
from svn: 2.234s
uhla : 2.297
my : 2.044
that is 10% shorter (or even better, because string generation consume
about 1.4s)
full source in attachment (should I prepare it different?)
changes are made in: FPHash and some minor in StrExpand,AddStr, Add
Second: when I review assembler list I've notice some strange lines (all
optimizations are enabled):
# [124] dec(ii);
movl%esi,%eax
decl%eax
movl%eax,%esi
.Lj16:
movl%esi,%eax - this is not necessary
testl%eax,%eax
jg.Lj15
In source this is
while ii0 do begin
..
dec(ii)
end;
Can be added some optimizations to avoid this doubled move.
--
Darek
unit uhlm;
interface
{$mode objfpc}{$h+}{$r+}
uses
contnrs,sysutils,cutils, types;
const
SListIndexError = 'List index exceeds bounds (%d)';
SListCapacityError = 'The maximum list capacity is reached (%d)';
SListCapacityPower2Error = 'The capacity has to be a power of 2, but is set
to %d';
SListCountError = 'List count too large (%d)';
type
EListError = class(Exception);
type
THashItem=record
HashValue : LongWord;
StrIndex : Integer;
NextIndex : Integer;
Data : Pointer;
end;
PHashItem=^THashItem;
const
MaxHashListSize = Maxint div 16;
MaxHashStrSize = Maxint;
MaxHashTableSize = Maxint div 4;
MaxItemsPerHash = 3;
type
PHashItemList = ^THashItemList;
THashItemList = array[0..MaxHashListSize - 1] of THashItem;
PHashTable = ^THashTable;
THashTable = array[0..MaxHashTableSize - 1] of Integer;
TFPHashListM = class(TObject)
private
{ ItemList }
ffcc : integer;
FHashList : PHashItemList;
FCount,
FCapacity : Integer;
FCapacityMask: LongWord;
{ Hash }
FHashTable: PHashTable;
FHashCapacity : Integer;
{ Strings }
FStrs : PChar;
FStrCount,
FStrCapacity : Integer;
function InternalFind(AHash:LongWord;const AName:shortstring;out
PrevIndex:Integer):Integer;
protected
function Get(Index: Integer): Pointer;
procedure Put(Index: Integer; Item: Pointer);
procedure SetCapacity(NewCapacity: Integer);
procedure SetCount(NewCount: Integer);
Procedure RaiseIndexError(Index : Integer);
function AddStr(const s:shortstring): Integer;
procedure AddToHashTable(Index: Integer);inline;
procedure StrExpand;
procedure SetStrCapacity(NewCapacity: Integer);
procedure SetHashCapacity(NewCapacity: Integer);
procedure ReHash;
public
constructor Create;
destructor Destroy; override;
function Add(const AName:shortstring;Item: Pointer): Integer;
procedure Clear;
function NameOfIndex(Index: Integer): ShortString;
function HashOfIndex(Index: Integer): LongWord;
function GetNextCollision(Index: Integer): Integer;
procedure Delete(Index: Integer);
class procedure Error(const Msg: string; Data: PtrInt);
function Expand: TFPHashListM;
function Extract(item: Pointer): Pointer;
function IndexOf(Item: Pointer): Integer;
function Find(const AName:shortstring): Pointer;
function FindIndexOf(const AName:shortstring): Integer;
function FindWithHash(const AName:shortstring;AHash:LongWord): Pointer;
function Rename(const AOldName,ANewName:shortstring): Integer;
function Remove(Item: Pointer): Integer;
procedure Pack;
procedure ShowStatistics;
procedure ForEachCall(proc2call:TListCallback;arg:pointer);
procedure ForEachCall(proc2call:TListStaticCallback;arg:pointer);
property Capacity: Integer read FCapacity write SetCapacity;
property Count: Integer read FCount write SetCount;
property Items[Index: Integer]: Pointer read Get write Put; default;
property List: PHashItemList read FHashList;
property Strs: PChar read FStrs;
end;
implementation
{*
TFPHashListM
*}
function FPHash(const s:shortstring):LongWord;
Var
ii,i : integer;
p: pchar;
pw : ^longword;
begin
{$ifopt Q+}
{$define overflowon}
{$Q-}
{$endif}
pw:=...@s[0];
i:=length(s);
ii:=i shr 2;
i:=i and 3;
[fpc-devel] VAL behavior
Hi
I found different behavior of VAL function under Delphi and FPC
var
i,io : integer
begin
val('9 ',ii,io);
writeln(ii);
writeln(io);
end;
Delphi set ii to 9, FPC set 0 (io is equal 2)
is this bug?
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VAL behavior
W dniu 2010-03-23 20:04, dmitry boyarintsev pisze: On Tue, Mar 23, 2010 at 6:50 PM, Dariusz Mazurdar...@emadar.com wrote: Delphi set ii to 9, FPC set 0 (io is equal 2) is this bug? Don't assume the value of ii (since it's invalid), if io 0 I don't ask about it. Only if this difference is a bug. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] possible 'dynlibs' unit issue
W dniu 2010-01-19 13:53, Michael Van Canneyt pisze:
On Tue, 19 Jan 2010, Daniël Mantione wrote:
Op Tue, 19 Jan 2010, schreef Graeme Geldenhuys:
Michael Van Canneyt wrote:
Why should it be better ? It doesn't really matter anyway.
PtrUInt has a larger range than PtrInt (allowing full access to memory
address range). Plus, I don't think pointers can be negative values.
The problem occurs when doing pointer arithmetic ptrint+integer is
a bug, because it will overflow if the original pointer$800 and
the result pointer=$800. It is especially dangerous in loops like:
q:=p+distance;
while pq do
begin
{...}
inc(p);
end;
I don't want to think how many bugs have been coded this way :)
However, when using pointers as handles it is another matter...
Handles are not to be used in any calculation, so they cannot
overflow. Who cares if you get a negative handle?
That is what I meant. The TLibhandle type is opaque. You're not
supposed to
know that it is a pointer, integer or whatnot. And definitely you
should not
do math on them.
Is this possible to forbid this at compile time?
I thinking about something like this:
operator + (a : tLibHandle; b: integer) res : tLibHandle;
begin
abstract; //compiler can give error at place of invoke
end;
is this possible?
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] possible 'dynlibs' unit issue
W dniu 2010-01-19 19:00, Daniël Mantione pisze: Op Tue, 19 Jan 2010, schreef Dariusz Mazur: Is this possible to forbid this at compile time? An easy solution is to wrap it inside a record. This is good practise as it prevents accidental bugs like accidentally writing parameters in the wrong order when calling a procedure. It's basically the point of type safety. Yes. I use this very often. But it is possible only for new types. When we want to test or protect some sort of operation on huge source its harder. Operator overloading is enough but lack something that detect invoke of this function. And its not only for this solution, appliance is much wider (f.e. generics) -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [arm] tStream.position
Hi there is problem with something like that var ts : tStream; begin ts:=tStream.create; ts.position:=2; // here arm write ERange Error // on trace setPosition // is very big number, like 153000 ts.free; end; platform : ARM with soft float -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on ARM
Michael Schnell pisze: Dariusz Mazur wrote: My application small part of my web based ERP application; From compiler side use: uclibc,... So I suppose this is on Linux, not WinCE ? beautiful !!! Great ! Thanks for letting us know. Did you try to use an IDE such as Lazarus or MSE ? As You see this device has not any display, I'm not interesting any IDE, only webbased or without any human interface (device to control other equipment) . -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC on ARM
Hi Now I finished porting my small app to this arm board: http://www.sklep.propox.com/show.php?g=2118szr=800wys=599p=05ce82c249a24e23bb597b9f80a258da25478 this consist: ARM926-EJ AT91SAM9260 (AT91SAM9G20) 64MB SDRAM 4GB i NAND Flash Ethernet PHY 10/100Mbit My application small part of my web based ERP application; From compiler side use: uclibc, pthreads, Synapse, resource management solved problems dynpthreads should be disable minor changes on uclibc.as rest code is the same like on i386 linux and win32 and all works beautiful !!! -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] change default start function in cprt0.o
Jonas Maebe pisze: On 04 Dec 2009, at 17:51, Dariusz Mazur wrote: but now another problem linker say that system.pp need function _haltproc_eabi which is absent in ucprt.0 That's probably because nobody has maintained the uclibc support since adding EABI support. The ARM/Linux support is very ad hoc: it was added, but afaik there is no real maintainer for it (Florian and I sometimes fix some things, but that's it). uclibc is even less tested or used. We really need someone who is will to maintain that platform, because several people appear to be interested in using it, but few if any in developing and maintaining the necessary compiler or RTL support. I've simple copy haltproc_eabi form cprt0.o and at last everything compiling now i start test on host should I prepare patch do ucprt0.o when all goes OK -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] change default start function in cprt0.o
Florian Klaempfl pisze: Jonas Maebe schrieb: On 04 Dec 2009, at 17:51, Dariusz Mazur wrote: but now another problem linker say that system.pp need function _haltproc_eabi which is absent in ucprt.0 That's probably because nobody has maintained the uclibc support since adding EABI support. The ARM/Linux support is very ad hoc: it was added, but afaik there is no real maintainer for it (Florian and I sometimes fix some things, but that's it). uclibc is even less tested or used. We really need someone who is will to maintain that platform, I still miss a reasonable EABI development system. EABI not, but uClibc can be tested on i386, only lack ucprt0.o in linux/i386 then testing will be easier If its needed, I can do it. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM: problem with uses VFP instructions
Dariusz Mazur pisze: Jonas Maebe pisze: On 02 Dec 2009, at 15:17, Dariusz Mazur wrote: * __VFP_FP__ means that the floating point format in use is that of the ARM VFP unit, which is native-endian IEEE-754. * __MAVERICK__ means that the floating point format is that of the irrus Logic MaverickCrunch http://wiki.debian.org/MaverickCrunch, which is also IEEE-754 and is always little-endian. * __SOFTFP__ means that instead of floating point instructions, library calls are being generated for floating point math operations so that the code will run on a processor without an FPU. __VFP_FP__ and __MAVERICK__ are mutually exclusive. If neither is set, that means the floating point format in use is the old mixed-endian 45670123 format of the FPA unit. Note that __VFP_FP__ does /not/ mean that VFP code generation has been selected. It only speaks of the floating point data format in use and is normally set when softfloat has been selected. The correct test for VFP code generation, for example around asm fragments containing VFP instructions, is My question is: which variant use FPC By default, on ARM/EABI FPC uses native-endian IEEE-754, but uses library calls (to internal code in the RTL) to emulate the floating point operations. So it's a combination of __VFP_FP__ and __SOFTFP__. I found that crti.o linking form toolchain is without VFP, i try to recompile this At last I made it, I have new uclibc library compiled with VFP for others I use OpenWRT, to recompile make menuconfig add in advanced configuration/toolchain/target optimization -mfpu=vfp after make i receive in toolchain path readelf -a crti.o show flags: soft float and VFP -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] change default start function in cprt0.o
Hi next problem with use uclibc cprt0.o need _libc_start_main but inn uclibc _uClibc_main is used how to change it prepare new cprt0.as ? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] change default start function in cprt0.o
Jonas Maebe pisze: On 04 Dec 2009, at 11:00, Dariusz Mazur wrote: next problem with use uclibc cprt0.o need _libc_start_main but inn uclibc _uClibc_main is used how to change it prepare new cprt0.as ? I think the compiler is supposed to use ucprt0.as when you compile against uclibc. Search for uclibc in compiler/systems/t_linux.pas to see how the compiler decides which libc variant you are using. thx to fpc.cfg I;ve added -XR/home/darek/fpcarm/toolchain-arm-uclibc/ it works, but now another problem linker say that system.pp need function _haltproc_eabi which is absent in ucprt.0 -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM: problem with uses VFP instructions
Jonas Maebe pisze: On 02 Dec 2009, at 00:23, Dariusz Mazur wrote: HI I try to crosscompile for arm (uclibc and eabi). Source and listing error below. But when I remove dynlibs form uses section, all goes OK When I check link.res only few things are changed in section input prt0-cprt0.o -crti.o What I should looking for. I don't understand the errors, because FPC does not yet support VFP at all. So those FPC-generated object files cannot contain any VFP code. On ARM systems, the kind of instructions used by an object file is stored in its header by the assembler. Maybe you are using a toolchain that has not been configured for softfloat to cross-compile. i've make some investigation problem start from crti.o linking from achieved toolchain (I use AT91SAM9260) I found something like makro __FPV_FP in source for this library on uclibc.org and explanation on http://wiki.debian.org/ArmEabiPort When porting code to ARM EABI, the following preprocessor macros are interesting: * __VFP_FP__ means that the floating point format in use is that of the ARM VFP unit, which is native-endian IEEE-754. * __MAVERICK__ means that the floating point format is that of the irrus Logic MaverickCrunch http://wiki.debian.org/MaverickCrunch, which is also IEEE-754 and is always little-endian. * __SOFTFP__ means that instead of floating point instructions, library calls are being generated for floating point math operations so that the code will run on a processor without an FPU. __VFP_FP__ and __MAVERICK__ are mutually exclusive. If neither is set, that means the floating point format in use is the old mixed-endian 45670123 format of the FPA unit. Note that __VFP_FP__ does /not/ mean that VFP code generation has been selected. It only speaks of the floating point data format in use and is normally set when softfloat has been selected. The correct test for VFP code generation, for example around asm fragments containing VFP instructions, is My question is: which variant use FPC -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] error when crosscompile for arm
Jonas Maebe pisze:
On 02 Dec 2009, at 00:15, Dariusz Mazur wrote:
Jonas Maebe pisze:
On 30 Nov 2009, at 23:47, Dariusz Mazur wrote:
Is this possible to add special directive, that left the same behavior of comp
under arm?
or any other hack?
Only a hardware hack: solder an x87-fpu on your ARM processor and use that...
This cannot be fixed in software without emulating an x87-fpu (or 128 bit
floats), because a double precision floating point type does not have the
required precision to represent all comp values.
I was thinking, that soft FPU can emulate this,
It could once someone adds float80 support to it. Currently only single and
double are supported.
or compiler can use comp internal as int64 and external as real.
That would result in precision loss.
Why. comp is 8 byte wide, the same as int64,
As I read Delphi help now, comp is internal Intel int64, but is
classified as real, because it is not ordinal type.
From these stage I have one suggestion.
on linux-i368 directive $E claim: switch $E is not supported
I think that's quite self-explanatory.
on linux-arm the same switch cause compiling error (problems with units
generating with different switch ) remark: all compiled with -CfSOFT
Compiling with -Cfsoft and {$E-} will indeed probably causes errors. The
compiler should simply give an error when you try to do that.
Not simpler ignore this?
On other platforms this is not enough, and more switches should be added
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] error when crosscompile for arm
Jonas Maebe pisze:
On 02 Dec 2009, at 16:19, Dariusz Mazur wrote:
Jonas Maebe pisze:
On 02 Dec 2009, at 00:15, Dariusz Mazur wrote:
Jonas Maebe pisze:
or compiler can use comp internal as int64 and external as real.
That would result in precision loss.
Why. comp is 8 byte wide, the same as int64,
The precision loss occurs when treating it external as real, because
a double cannot represent all int64 values (it's also 8 bytes, but
some of those 8 bytes are used to represent an exponent).
As I read Delphi help now, comp is internal Intel int64, but is
classified as real, because it is not ordinal type.
The reason is because x87 fpu supports a signed 64 bit integer type
(which Borland called comp). They introduced that type to allow
people to perform fairly quick 64 bit arithmetic mathematics on the
old Intel 16 bit processors, by making use of the floating point unit.
That's the reason for the strange the definition and the non-portability.
I thinking about treat this, as it is floating point, not as double
it stay integer but it can be use as float (for example str(c:0:0,aa)
where s is comp
the same as Delphi
on linux-arm the same switch cause compiling error (problems with
units generating with different switch ) remark: all compiled with
-CfSOFT
Compiling with -Cfsoft and {$E-} will indeed probably causes errors.
The compiler should simply give an error when you try to do that.
Not simpler ignore this?
It may seem simpler at first sight, but putting intelligence like
that in the compiler only makes the compiler's behaviour more complex
to understand in the long run (if the compiler ignores what I'm doing
here, under what other circumstances will it ignore things?) and more
difficult to maintain.
On other platforms this is not enough, and more switches should be
added
I don't understand what you mean with this. Note that we do not
support floating point emulation on all platforms.
If FPC not support emulation, then $E cant disable this
maybe easer is don't disable at all
(but this is only suggestion, no pressure)
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM: problem with uses VFP instructions
Jonas Maebe pisze: On 02 Dec 2009, at 15:17, Dariusz Mazur wrote: * __VFP_FP__ means that the floating point format in use is that of the ARM VFP unit, which is native-endian IEEE-754. * __MAVERICK__ means that the floating point format is that of the irrus Logic MaverickCrunch http://wiki.debian.org/MaverickCrunch, which is also IEEE-754 and is always little-endian. * __SOFTFP__ means that instead of floating point instructions, library calls are being generated for floating point math operations so that the code will run on a processor without an FPU. __VFP_FP__ and __MAVERICK__ are mutually exclusive. If neither is set, that means the floating point format in use is the old mixed-endian 45670123 format of the FPA unit. Note that __VFP_FP__ does /not/ mean that VFP code generation has been selected. It only speaks of the floating point data format in use and is normally set when softfloat has been selected. The correct test for VFP code generation, for example around asm fragments containing VFP instructions, is My question is: which variant use FPC By default, on ARM/EABI FPC uses native-endian IEEE-754, but uses library calls (to internal code in the RTL) to emulate the floating point operations. So it's a combination of __VFP_FP__ and __SOFTFP__. I found that crti.o linking form toolchain is without VFP, i try to recompile this -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] error when crosscompile for arm
Jonas Maebe pisze: On 30 Nov 2009, at 23:47, Dariusz Mazur wrote: Is this possible to add special directive, that left the same behavior of comp under arm? or any other hack? Only a hardware hack: solder an x87-fpu on your ARM processor and use that... This cannot be fixed in software without emulating an x87-fpu (or 128 bit floats), because a double precision floating point type does not have the required precision to represent all comp values. I was thinking, that soft FPU can emulate this, or compiler can use comp internal as int64 and external as real. But now I remove comp and go one. From these stage I have one suggestion. on linux-i368 directive $E claim: switch $E is not supported on linux-arm the same switch cause compiling error (problems with units generating with different switch ) remark: all compiled with -CfSOFT Darek -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ARM: problem with uses VFP instructions
HI
I try to crosscompile for arm (uclibc and eabi). Source and listing
error below.
But when I remove dynlibs form uses section, all goes OK
When I check link.res only few things are changed in section input
prt0-cprt0.o
-crti.o
What I should looking for.
program hello;
uses
dynlibs,
sysconst,
rtlconsts,
sysutils,
classes;
var
i : double;
begin
i:=int(1.1);
writeln('hello world ',i);
end.
and receive error:
darek2...@darek2008-desktop:~/fpcarm/lib/fpc/2.5.1$ ./ppcrossarm
hello.pas rr
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
/home/darek2008/fpcarm/praca/arm-linux/hello.o uses VFP instructions,
whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file /home/darek2008/fpcarm/praca/arm-linux/hello.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/system.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/system.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/objpas.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/objpas.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/dynlibs.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/dynlibs.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/sysutils.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/sysutils.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/rtlconsts.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/rtlconsts.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/sysconst.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/sysconst.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/unix.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/unix.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/errors.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/errors.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/unixtype.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/unixtype.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/baseunix.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/baseunix.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/unixutil.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/unixutil.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/syscall.o uses VFP instructions, whereas hello
does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/syscall.o
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: ERROR:
./units/arm-linux/rtl/dl.o uses VFP instructions, whereas hello does not
/home/darek2008/fpcarm/arm-linux-uclibc/bin/ld: failed to merge target
specific data of file ./units/arm-linux/rtl/dl.o
./units/arm-linux/rtl/cprt0.o: In function `_start':
(.text+0x4c): undefined reference to `__libc_start_main'
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] error when crosscompile for arm
Hi I receive error while compile for arm selected processor does not support 'ldfd f0,[r11,#-48]' this is from simple function, but when I move them to main unit everything is compiled OK what does it mean? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] error when crosscompile for arm
Jonas Maebe pisze: On 30 Nov 2009, at 17:47, Dariusz Mazur wrote: I receive error while compile for arm selected processor does not support 'ldfd f0,[r11,#-48]' Add -Cfsoft to your compiler options to use softfloat instead of FPA. I've had this option enable this is from simple function, but when I move them to main unit everything is compiled OK what does it mean? I don't know why it doesn't happen in that case. If units I have compiler directive $E- (emulation of FPU) but when I remove it, i have problem with COMP type when var c : comp; begin c:=int(1.1); end; it claim got Double, expected int64 second problem is with str str(c:0:0,ss) is not valid -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] error when crosscompile for arm
this is from simple function, but when I move them to main unit everything is compiled OK what does it mean? I don't know why it doesn't happen in that case. If units I have compiler directive $E- (emulation of FPU) Is this still about moving the function to another unit solving the problem you had, or an unrelated remark? This the same, units has enable $E-, but when I remove it second problem is show. but when I remove it, i have problem with COMP type when var c : comp; begin c:=int(1.1); end; it claim got Double, expected int64 second problem is with str str(c:0:0,ss) is not valid Comp is an x87-specific legacy type. On platforms without x87 support it is emulated using int64 (so there it is an integer type rather than a floating point type). You should not use the comp type if you want portable code. Now I know where is problem. But how solve them. I cant simple remove all comp. I try to move my whole program. it use comp hundreds times. I can't write from ground. Is this possible to add special directive, that left the same behavior of comp under arm? or any other hack? I don't understand what this has to do with what I said above, or with your ldfd-problem though. Please do not reply to some sentences in a previous mail if you want to explain something else, it makes the discussion confusing. Either write a separate mail, or delete the unrelated sentences. Sorry for confusing. For me it is the same problem: FPU but when enable one switch, one bug disappear, but second is show. Thx for explanation and patience. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Source Code Optimization
Maybe it is something interesting http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] tBits
Alexander Klenin pisze: 2009/11/11 Dariusz Mazur dar...@emadar.com: With this I have and question: For me function FindNextRaw should be in protected section But then we cant use them in enumerator, except when something like friend classes can be used in FPC. I only read about this concept, is it possible/plan in FPC. If you place enumerators in the same unit as TBits, they will have access to the properted members of TBits. Ok thx. But should those enumerators exists in classes ? How exclude enumerators for older compilers? What should be done, to submit it to trunk? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] tBits
What should be done, to submit it to trunk? Usually using bug tracker. But submit what? New enumerators for TBits? Is yes then first let someone else decide (like Michael, Florian). Sorry for unclear ask. I don't need submit myself. I want to prepare good patch, which can be submit, but to do this I need know what i'm doing wrong or what should be done more. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [patch] tBits
Hi
Here is patch to tBits ans test program.
Its repair FindnextBit.
I also introduce FindNextRaw,
based on it faster version FindNextBit can be done
I can add:
[code]
function FindFirstBit;
begin
result:=findNextRaw(-1, state);
end;
function FindNextBit;
begin
result:=findNextRaw(findIndex, findState);
end;
[/code]
and can be helpful in enumerator.
With this I have and question:
For me function FindNextRaw should be in protected section
But then we cant use them in enumerator, except when something like
friend classes can be used in FPC.
I only read about this concept, is it possible/plan in FPC.
--
Darek
program tbits1;
// test operator Enumerator support for classes
{$mode objfpc}{$H+}
{$APPTYPE CONSOLE}
uses
unitbits;
var
Bits: TBits;
procedure test1;
begin
Bits := TBits.Create(10);
bits[1]:=true;
bits[6]:=true;
writeln(bits.findFirstBit(true));
writeln(bits.findNextBit);
writeln(bits.findNextBit);
bits.Free;
end;
procedure test2;
var
i : integer;
begin
Bits := TBits.Create(10);
bits[1]:=true;
bits[6]:=true;
i:=-1;
repeat
i:=bits.findNextRaw(i,true);
writeln(i);
until i=-1;
bits.Free;
end;
begin
test1;
test2;
end.
Index: bits.inc
===
--- bits.inc(wersja 14086)
+++ bits.inc(kopia robocza)
@@ -282,6 +282,45 @@
{ and when it is set to False it looks for bits that are turned }
{ off (0). }
+function TBits.FindNextRaw(start : longint;state : boolean) : longint;
+var
+ loop : longint;
+ loop2 : longint;
+ startIndex : longint;
+ stopIndex : longint;
+ compareVal : cardinal;
+begin
+ result := -1; {should only occur if none are set}
+ if state = False then
+ compareVal := $ { looking for off bits }
+ else
+ compareVal := $; { looking for on bits }
+ inc(start);
+ loop := (start) div 32;
+ if loop=fSize then exit;
+ repeat
+ if FBits^[loop] compareVal then begin
+
+ startIndex := loop shl BITSHIFT;
+ stopIndex:= startIndex +MASK+1;
+ if start startIndex then startIndex:=start;
+ if stopIndex(FBSize ) then stopIndex:=fbSize;
+ writeln(startIndex,' ',stopIndex);
+ for loop2 := startIndex to stopIndex -1 do
+ begin
+if get(loop2) = state then
+begin
+ exit(loop2);
+end;
+ end;
+ end;
+ inc(loop);
+ until (loop=FSize);
+
+end;
+
+
+
function TBits.FindFirstBit(state : boolean) : longint;
var
loop : longint;
@@ -323,16 +362,14 @@
function TBits.FindNextBit : longint;
var
loop : longint;
- maxVal : longint;
begin
result := -1; { will occur only if no other bits set to }
{ current findState}
if findIndex -1 then { must have called FindFirstBit first }
begin { or set the start index }
- maxVal := (FSize * 32) - 1;
- for loop := findIndex + 1 to maxVal do
+ for loop := findIndex + 1 to FBSize-1 do
begin
if get(loop) = findState then
begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forin feature with tBits
Alexander Klenin pisze: 2009/11/7 Dariusz Mazur dar...@emadar.com: If try to apply forin feature to tBits. But I have two problems 1. function FindFirstBit has bug [skipped] 2. findfirstbit is not multithread aware (because state is per object, not local) Yes, this is a good example why separate iterators are preferable to the ones built into container. Should I prepare patch? Whats about used names? IMHO your names (EnumSet/EnumClear) are ok. Obviously, the implementation should not call FindFirstBit, but copy it's logic. To avoid code duplication, I think you can to it the other way around -- let FindFirstBit create a enumerator and store it inside the TBits instance. I'm not sure, but if this solution is not multithread aware too? It would be even better to drop FindFirstBit/FindNextBit altogether, but I do not know how large compatibility problem it might cause. [skipped most of code] function tEnumBits.enumSet:tBitEnumerator; begin result:=tBitEnumerator.create(self,true); end; function tEnumBits.enumClear:tBitEnumerator; begin result:=tBitEnumerator.create(self,false); end; operator enumerator (AEnumerator: TBitEnumerator): TBitEnumerator; begin Result := AEnumerator end; IMHO, this code demonstrates an inconvenience of the current for..in implementation. The last operator enumerator declaration is clearly redundant. I have two alternative suggestions here: 1) Let for..in accept the enumerator instead of the container as the second argument. 2) Define the trivial operator enumerator as above for some basic type, e.g. TEnumerator, maybe in Classes.pp or even System unit. After that, one can inherit TBitEnumerator from TEnumerator to avoid the need for operator enumerator declaration. I've thinking about second solution. Now enumerator is passed through operator and its better, when always is the same. For me it should be done in sysutils, similar as Exception -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Micha Nelissen pisze: Michael Van Canneyt wrote: I see little gain in changing while Something(f) do F.Somethingelse This is not quite equal, it's more like: Start(f); while not Last(f) do F.DoWork; In your case, the function 'Something' must know about a generic F. why not f.start; while not f.last do f.doWork; There are also recursive state problems to be thought about. I guess this is why in the STL an iterator is a separate object on the local stack, but able to iterate through (another) object of the defined type. Second problem is multithreading, when we try to iterate concurrent on the same collection. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Paul Ishenin pisze: Marc Weustink wrote: I can see a use for using iterators in a for loop, however they should be declared with some keyword. Something like type TListIterator = iterator(TList, init_func, next_func, check_func) function init_func: Boolean; function next_func: element type function check_func: Boolean; end; begin for element in list using TListIterator do... IMO this is more pascal than using some interface or predefined function names. Good idea. What is iterator internally? Is this an object with the special header? Is it internall the same as: TListIterator = object function init_func(AList: TList): Boolean; function next_func: Pointer; function check_func: Boolean; end; But where is current state of iterator. next_func need to know old state and then easy move to next, but were state is saved. second solution receive old result, find it in collection, decode past state and compute next, but it hurt performance -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Jeff Wormsley pisze: Michael Schnell wrote: Again something inspired by Delphi-Prism ? ( http://prismwiki.codegear.com/en/Lambda_Expressions ) Wow, talk about unreadable code... why all vote about something, that wasn't proposed ? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New feature discussion: LAMBDA
Hi Based on discussion about for in I want to suggest my proposition. When we investigate some code, sometimes we found pattern: Pattern 1: / begin startfun; try ... finally stopfun; end; / end; Pattern 2: for i:= startfun to stopfun do begin end; Pattern 3: startfun; while stopfun do begin ... end; Common for all mentioned patterns are two connected functions, which controlled running of body source. First make all initializations, second helping with iterations and finalizations. My proposition is make possibility of join, those pair to one sentence. All patterns can be change to one common template: if startfun then repeat until stopfun; I You see we need two function with boolean result. Of course possibility of parameters give wide appliance. To preserve pascalish style I propose something like this: tMyObject = class(tObject) function startfun:boolean; function stopfun:boolean; property lambdafun; start startfun stop stopfun; end; and invoke: var t : tMyObject; begin .. t.lambdafun do begin end; end; because on declaration side is similar do properties (also two function) we can use the same syntax. Only keyword start and stop exchange read and write. To using i thought about WITH, but it may confusing bit, thus I propose omit, and only use keyword DO. Why lambda. Because is very similar to constructing no name procedures and use them as normal. We have few mechanism controlling runnig: IF, REPEAT, WHILE, FOR. They work well, but sometimes they are week. For example we don't have enough primitives do build own implementation FORIN method, on iterators also. But in Lisp any mechanism, any sequence of computing collection can be done and source is very readable lisp syntax: (lambda (formal parameters) body) This is not unusual, but we can send this declaration as argument of procedure. Of course syntax like this tlist.foreach( procedure (x : tObject);begin writeln(x) end) is ugly (thought I sow something similar in C++/boost) but when we change it a bit: tlist.foreach(x) do begin writeln(x); end; its not so strange Because my english is very poor I only show some application EXP. mutex (and patterns as RIAA) tMutex = class property makeatomic; start lock stop unlock; end; . begin tMutex.makeatomic do begin ... end; end; EXP: foreach tMyList = class function tMyList.start:boolean; begin current:=first; result:=currentnil; end; function tMyList.stop:boolean; begin current:=next(current); resutl:=currentnil; end; When attributes are added, or exception caching this will be more flexible. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this. But
lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
which is very strange, special syntax, and need to be translate to method, and declaration longer
than one line is awful,
my proposition semantically is between properties (they consist also two function),
aspect programming and lambda
is very easy to translate to ordinal pascal( lambda invoke change to
repeat-while iteration,
similarly as in generics)
has wider application:
from FPC WIKI:
procedure StringLoop(S: String);
var
C: Char;
begin
for C in S do
DoSomething(C);
end;
my prop:
procedure stringloop(s :tMyString);
begin
{with} s.eachword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
end;
of course I can write
procedure stringloop(s :tMyString);
begin
s.firstWord;
try
while s.nexword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
except
s.exceptWord;
end;
end;
which can be equivalent
from compiler side invoke of lambda is translate to proper iteration before
main compilation
from developer side: its easy to use as properties,
fewer bugs caused forget of initialization or finalization, or use incompatible init and step
function in iterators
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: LAMBDA
ik pisze:
Pascal have something close to lambda, and it's nested
functions/procedures
The original idea of lambda is to have sub process that takes
parameters and simple tasks.
You don't understand me. I know sub process, this is nice feature of
pascal, but i talk about something different.
Sometimes we have sub process and want to do with them rather
complicated task.
For example (in Ruby):
def action(base)
expo = lambda { |by_num| base ** by_num}
x = something
a = expo(x)
end
I can do the same with the following:
procedure action(base : integer)
function expo(by_num)
begin
expo := base ** by_num
end;
var x,a : integer;
begin
x := something;
a := expo(x);
...
end;
My example was different. Try to implement my example with the same
readability, error prove,
Of curse it's one usage for it, but most of the real usage of lambda
can be made in pascal today. And please do not take ideas from C++,
it's a language that wrote on it's agenda to implement any possible
technology out there regardless of it's need or usage, and it's
impossible to use that language without some framework or ignoring
this technologies.
I don't draw from C++, which is imperative language , rather try to use
some of the best of functional language.
I don't even know, that it should be name lambda. Its similar to
iterators, but also to aspect. It has the same syntax as properties.
thats all.
2009/10/20 Dariusz Mazur dar...@emadar.com mailto:dar...@emadar.com
Michael Schnell pisze:
Again something inspired by Delphi-Prism ?
( http://prismwiki.codegear.com/en/Lambda_Expressions )
No at all, I don't even see this before. I thing long about this.
But lately I see this in C++ (strange) and Lisp (beautiful)
In Prism have You:
c - c.Name = 'Smith'
which is very strange, special syntax, and need to be translate to
method, and declaration longer than one line is awful,
my proposition semantically is between properties (they consist
also two function), aspect programming and lambda
is very easy to translate to ordinal pascal( lambda invoke change
to repeat-while iteration,
similarly as in generics)
has wider application:
from FPC WIKI:
procedure StringLoop(S: String);
var
C: Char;
begin
for C in S do
DoSomething(C);
end;
my prop:
procedure stringloop(s :tMyString);
begin
{with} s.eachword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
end;
of course I can write
procedure stringloop(s :tMyString);
begin
s.firstWord;
try
while s.nexword do begin
if s.currentword'begin' then
writeln(s.currentword);
end;
except
s.exceptWord;
end; end;
which can be equivalent
from compiler side invoke of lambda is translate to proper
iteration before main compilation
from developer side: its easy to use as properties, fewer bugs
caused forget of initialization or finalization, or use
incompatible init and step
function in iterators
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CGI/Command line/GUI all in one
Horacio Jamilis pisze: Dariusz Mazur escribió: Horacio Jamilis pisze: Dariusz Mazur escribió: This is not problem to have separate executable, only have one source to both GUI. I made program which can work as desktop and as web-based (FCGI or standalone web server) Each form is create dynamical in runtime, source is one, but in compile time: 1 for desktop: clasic units from LCL (or rather VCL, on windows I use Delphi) 2.for web-base different set of units to handle web, but with the same API as VCL Darek How do you do this? I want to do exactly the same... having 2 exe, one for desktop and one for web without doubling the work (from the same sources). I was thinking on using Intraweb (or VCL for the web in delphi)... but, what are you using for the web with FPC? webserver from synapse, but with several modification (current is much faster) own framework as I write upper,it contain replacement for units controls, forms, stdctrl of course only this part which I need, but its work I want to move to FPC from delphi, but I see no viable alternative to Intraweb in FPC (and Lazarus). Indy don't work properly on linux, Intraweb is so complicated and very heavy Do you have any sample source I could see? http://www.emadar.com/fpc/xwebdemo.zip its very simple demo with all libraries but some text are in polish, fell free to ask, i've try to translate or explain I tried to compile the demo project with Delphi 2007 (because I saw a .dpr file)... but it seems that a couple of required files are missing... aka: kom2, kom3 ... and may be others. I really like to see this working... Could you fix te problems or may be send me this files? and the command to compile with fpc? Thanks. I've update xwebdemo, it contains compiled version too if any problems, tell me On FPC all should be OK, maybe except dpr file and synapse (zip does not contain whole) ex: FPC testmobile.dpr -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CGI/Command line/GUI all in one
Horacio Jamilis pisze: Dariusz Mazur escribió: This is not problem to have separate executable, only have one source to both GUI. I made program which can work as desktop and as web-based (FCGI or standalone web server) Each form is create dynamical in runtime, source is one, but in compile time: 1 for desktop: clasic units from LCL (or rather VCL, on windows I use Delphi) 2.for web-base different set of units to handle web, but with the same API as VCL Darek How do you do this? I want to do exactly the same... having 2 exe, one for desktop and one for web without doubling the work (from the same sources). I was thinking on using Intraweb (or VCL for the web in delphi)... but, what are you using for the web with FPC? webserver from synapse, but with several modification (current is much faster) own framework as I write upper,it contain replacement for units controls, forms, stdctrl of course only this part which I need, but its work I want to move to FPC from delphi, but I see no viable alternative to Intraweb in FPC (and Lazarus). Indy don't work properly on linux, Intraweb is so complicated and very heavy Do you have any sample source I could see? http://www.emadar.com/fpc/xwebdemo.zip its very simple demo with all libraries but some text are in polish, fell free to ask, i've try to translate or explain -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CGI/Command line/GUI all in one
Marco van de Voort pisze: In our previous episode, Dariusz Mazur said: I want to move to FPC from delphi, but I see no viable alternative to Intraweb in FPC (and Lazarus). Indy don't work properly on linux, What's the problem? webserver was no stable, maybe something was change, I swich to Synapse two years ago and i think Synapse is faster (I don't make any test, but only about look to source) -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CGI/Command line/GUI all in one
Gilles MARCOU pisze:
Hello,
I'm trying to build an interface for a program so that it could be used
as a command line, a GUI or a CGI. For the CGI, I use powutils 1.7.1,
FPC 2.2.0 and Lazarus 0.9.24. I mean that the same executable should be
used either as a CGI, a command line or a GUI.
Currently I have kept separated in different unit each user interface
(see the code below). But, at execution, if there is an execution error,
it always open message box. Therefore, even in command line, the
software requires GUI libraries be there (GTK for instance) and it
simply does not work as a CGI.
You have to change all automatic initialization of visual components and
make all linking with GUI libraries dynamic. That i no easy.
But you can invoke second executable from this console (distribute 2
file, but always invoke the same)
Do you see a more clever solution? Otherwise, the only solution I see is
to keep all three interfaces in separate executable.
This is not problem to have separate executable, only have one source to
both GUI.
I made program which can work as desktop and as web-based (FCGI or
standalone web server)
Each form is create dynamical in runtime, source is one, but in compile
time:
1 for desktop: clasic units from LCL (or rather VCL, on windows I use
Delphi)
2.for web-base different set of units to handle web, but with the same
API as VCL
Darek
Thanks in advance,
Gilles Marcou
program Predictor;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
//{ you can add units after this },
Classes, sysutils, UnitRunGUI, UnitRunCMD, UnitRunCGI;
type
TRuntype=(CGI,CMD,GUI,UNK);
var
cfg: TStringList;
rt: TRuntype;
begin
cfg:=TStringList.Create;
cfg.LoadFromFile('cfg');
rt:=UNK;
if (cfg[0]='CGI') then
rt:=CGI
else if (cfg[0]='CMD') then
rt:=CMD
else if (cfg[0]='GUI') then
rt:=GUI;
FreeAndNil(cfg);
if (rt=GUI) then
RunGUI
else if (rt=CMD) then
RunCMD
else if (rt=CGI) then
RunCGI;
end.
---
unit UnitRunGUI;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Interfaces, Forms, UnitPredictor;
procedure RunGUI;
implementation
procedure RunGUI;
begin
Application.Initialize;
Application.CreateForm(TFormPredictor, FormPredictor);
Application.Run;
end;
end.
unit UnitRunCGI;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, pwinit, pwmain;
procedure RunCGI;
implementation
procedure RunCGI;
begin
outln('CGI: Not yet supported');
end;
end.
unit UnitRunCMD;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils;
procedure RunCMD;
implementation
procedure RunCMD;
begin
writeln('CMD: Not supported yet');
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML canonical
Sergei Gorelkin pisze:
Dariusz Mazur wrote:
I'd suggest you to find a test suite (some examples are contained
directly in the text of w3.org specification, others may be ripped
from opensource projects that support canonicalization, like
libxml2) and verify your unit against it.
I draw from libxml2. First i resolved problem with namespaces. That
is not so clear in specification. Even simple xml canonization don't
work. Now I can work with more complicate file.
New version should be send here?
I was intending to implement canonicalization in the existing writer
(xmlwrite.pp), but namespace support is required before it can be done.
(namespace support is present in dom and xmlread, but not yet in
xmlwrite).
Actually, the writer is already doing most of the things, including
proper encoding and escaping. The attributes are already sorted by name.
What has to be changed:
1) sorting attributes with respect to namespace
2) write end-tags in full form
3) treat CDATA sections as text
4) don't omit defaulted attributes
5) omit xml declaration and DTD.
6) ...maybe missed something else.
The (1) is most difficult, (2) to (5) are pretty trivial.
So for me it seems a better idea to improve the existing writer rather
than making a new one. I cannot speak on behalf of the whole team,
however. Other opinions are welcome.
I've prepare new version of canonization. Its based on xmlwrite. Point
3,4 are not resolved (I don't it really need) but its trivial.
test against xmllib is not so easy, because we should follow the same
indentation on xmlwrite
It works only with simple xml, but its good enough to make proper XADES
signature
I can submit those unit also, if somebody help me and review it.
--
Darek
{
This file is part of the Free Component Library
XML writing routines
Copyright (c) 1999-2000 by Sebastian Guenther, s...@freepascal.org
Modified in 2006 by Sergei Gorelkin, sergei_gorel...@mail.ru
See the file COPYING.FPC, included in this distribution,
for details about the copyright.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
**}
unit XMLWriteC14;
{$ifdef fpc}
{$MODE objfpc}
{$endif}
{$H+}
interface
uses Classes, DOM;
procedure WriteXMLFileC14(doc: TXMLDocument; const AFileName: String); overload;
procedure WriteXMLFileC14(doc: TXMLDocument; var AFile: Text); overload;
procedure WriteXMLFileC14(doc: TXMLDocument; AStream: TStream); overload;
procedure WriteXMLC14(Element: TDOMNode; const AFileName: String); overload;
procedure WriteXMLC14(Element: TDOMNode; var AFile: Text); overload;
procedure WriteXMLC14(Element: TDOMNode; AStream: TStream); overload;
// ===
implementation
uses SysUtils;
type
TSpecialCharCallback = procedure(c: WideChar) of object;
TXMLWriter = class(TObject)
private
FInsideTextNode: Boolean;
FIndent: WideString;
FIndentCount: Integer;
FBuffer: PChar;
FBufPos: PChar;
FCapacity: Integer;
FLineBreak: string;
nsStack : TStringList;
fNotFirst : boolean;
function nodeIsNS(aNode : tDomNode):boolean;
function NSStackFind(const aName : string):boolean;
procedure wrtChars(Src: PWideChar; Length: Integer);
procedure IncIndent;
procedure DecIndent; {$IFDEF HAS_INLINE} inline; {$ENDIF}
procedure wrtStr(const ws: WideString); {$IFDEF HAS_INLINE} inline; {$ENDIF}
procedure wrtChr(c: WideChar); {$IFDEF HAS_INLINE} inline; {$ENDIF}
procedure wrtIndent; {$IFDEF HAS_INLINE} inline; {$ENDIF}
procedure wrtQuotedLiteral(const ws: WideString);
procedure ConvWrite(const s: WideString; const SpecialChars: TSetOfChar;
const SpecialCharCallback: TSpecialCharCallback);
procedure AttrSpecialCharCallback(c: WideChar);
procedure BuildAttributes(Anode: TDOMNode);
procedure TextNodeSpecialCharCallback(c: WideChar);
protected
procedure Write(const Buffer; Count: Longint); virtual; abstract;
procedure WriteNode(Node: TDOMNode);
procedure VisitDocument(Node: TDOMNode);
procedure VisitElement(Node: TDOMNode);
procedure VisitText(Node: TDOMNode);
procedure VisitCDATA(Node: TDOMNode);
procedure VisitComment(Node: TDOMNode);
procedure VisitFragment(Node: TDOMNode);
procedure VisitAttribute(Node: TDOMNode);
procedure VisitEntityRef(Node: TDOMNode);
procedure VisitDocumentType(Node: TDOMNode);
procedure VisitPI(Node: TDOMNode);
public
constructor Create;
destructor Destroy; override;
end;
TTextXMLWriter = Class(TXMLWriter)
Private
F : ^Text;
Protected
Procedure Write(Const Buffer; Count : Longint);override;
Public
constructor Create(var AFile: Text);
end;
TStreamXMLWriter = Class(TXMLWriter)
Private
Re: [fpc-devel] DOM patch
Michael Van Canneyt pisze:
On Thu, 27 Aug 2009, Michael Van Canneyt wrote:
On Thu, 27 Aug 2009, Dariusz Mazur wrote:
Hi
I use DOM from fcl-xml both for Delphi and FPC development.
I work with older version, till I notice serious bugs. Today i've
upgrade it from current svn. And problem: Delphi don't compile
I've made several changes in dom, xmlutil. Diff attached.
As i expect, bugs in new version disappear.
It's not change much.
Can someone review it?
Reviewed and applied. Thanks !
Hm. Something strange with compilation. I reversed the patch, because
xmlutils.pp does not compile with the patch.
Strange that I didn't notice the first time I called make ?
Could you look at FPC compilation and make a new patch ?
new patch attached.
tested with FPC also, but a cant use testgen
changed xmlconf
1. compilation by Delphi
2. added procedure reload
Darek
--
Darek
Index: xmlwrite.pp
===
--- xmlwrite.pp (wersja 13601)
+++ xmlwrite.pp (kopia robocza)
@@ -17,7 +17,10 @@
unit XMLWrite;
+
+{$ifdef fpc}
{$MODE objfpc}
+{$endif}
{$H+}
interface
Index: dom.pp
===
--- dom.pp (wersja 13601)
+++ dom.pp (kopia robocza)
@@ -32,8 +32,9 @@
unit DOM;
{$ifdef fpc}
-{$MODE objfpc}{$H+}
+{$MODE objfpc}
{$endif}
+{$H+}
interface
@@ -43,6 +44,10 @@
// ---
// DOMException
// ---
+{$ifndef fpc}
+type
+ tFpList = tList;
+{$endif}
const
@@ -101,6 +106,8 @@
TDOMAttrDef = class;
PNodePool = ^TNodePool;
TNodePool = class;
+ TTabNodePool = array[0..0] of TNodePool;
+ PTabNodePool = ^TTabNodePool;
// ---
@@ -430,7 +437,7 @@
FEmptyNode: TDOMElement;
FNodeLists: THashTable;
FMaxPoolSize: Integer;
-FPools: PNodePool;
+FPools: PTabNodePool;
FDocumentURI: DOMString;
function GetDocumentElement: TDOMElement;
function GetDocType: TDOMDocumentType;
@@ -2081,7 +2088,7 @@
FEmptyNode.Free;
inherited Destroy;
for i := 0 to (FMaxPoolSize div sizeof(TNodePool))-1 do
-FPools[i].Free;
+FPools^[i].Free;
FreeMem(FPools);
FNames.Free; // free the nametable after inherited has destroyed
the children
// (because children reference the nametable)
@@ -2099,11 +2106,11 @@
Exit;
end;
- pp := FPools[size div sizeof(TNodePool)];
+ pp := FPools^[size div sizeof(TNodePool)];
if pp = nil then
begin
pp := TNodePool.Create(size);
-FPools[size div sizeof(TNodePool)] := pp;
+FPools^[size div sizeof(TNodePool)] := pp;
end;
Result := pp.AllocNode(AClass);
end;
@@ -3167,24 +3174,24 @@
sz: Integer;
begin
ext := FCurrExtent;
- ptr := Pointer(FCurrBlock) + FElementSize;
+ ptrUInt(ptr) := ptrUInt(FCurrBlock) + FElementSize;
sz := FCurrExtentSize;
while Assigned(ext) do
begin
// call destructors for everyone still there
-ptr_end := Pointer(ext) + sizeof(TExtent) + (sz - 1) * FElementSize;
-while ptr = ptr_end do
+ptrUInt(ptr_end) := ptrUInt(ext) + sizeof(TExtent) + (sz - 1) *
FElementSize;
+while ptrUInt(ptr) = ptrUInt(ptr_end) do
begin
if TDOMNode(ptr).FPool = Self then
TObject(ptr).Destroy;
- Inc(ptr, FElementSize);
+ Inc(ptrUInt(ptr), FElementSize);
end;
// dispose the extent and pass to the next one
next := ext^.Next;
FreeMem(ext);
ext := next;
sz := sz div 2;
-ptr := Pointer(ext) + sizeof(TExtent);
+ptrUInt(ptr) := ptrUInt(ext) + sizeof(TExtent);
end;
inherited Destroy;
end;
@@ -3194,13 +3201,13 @@
ext: PExtent;
begin
Assert((FCurrExtent = nil) or
-(Pointer(FCurrBlock) = Pointer(FCurrExtent) + sizeof(TExtent)));
+(ptrUInt(FCurrBlock) = ptrUInt(FCurrExtent) + sizeof(TExtent)));
Assert(AElemCount 0);
GetMem(ext, sizeof(TExtent) + AElemCount * FElementSize);
ext^.Next := FCurrExtent;
// point to the beginning of the last block of extent
- FCurrBlock := TDOMNode(Pointer(ext) + sizeof(TExtent) + (AElemCount - 1) *
FElementSize);
+ FCurrBlock := TDOMNode(ptrInt(ext) + sizeof(TExtent) + (AElemCount - 1) *
FElementSize);
FCurrExtent := ext;
FCurrExtentSize := AElemCount;
end;
@@ -3214,7 +3221,7 @@
end
else
begin
-if Pointer(FCurrBlock) = Pointer(FCurrExtent) + sizeof(TExtent) then
+if ptrUInt(FCurrBlock) = ptrUInt(FCurrExtent) + sizeof(TExtent) then
AddExtent(FCurrExtentSize * 2);
Result := FCurrBlock;
Dec(PChar(FCurrBlock), FElementSize);
Index: xmlcfg.pp
===
--- xmlcfg.pp (wersja 13601)
+++ xmlcfg.pp (kopia robocza)
@@ -17,8 +17,9 @@
TXMLConfig enables applications to use XML files for storing their
configuration data
Re: [fpc-devel] DOM patch
- Using PtrInt for doing pointer math is discouraged in favor of PtrUInt; I've changed PtrInt do PtrUInt, but its not possible in each place how to resolve tClass= tClass(PtrUInt +ptrInt) FPC claim: combined unsigned and signed make result 64bit, which is incompatible with pointer what is proper way to resolve this -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] web site up-to-date
bugs on: http://www.freepascal.org/develop.var 1. (trunk - currently v2.3.x) should be 2.5.x 2. size of trunk: fpc.zip ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/source/fpc.zip (24 MB). should be 31MB 3.bottom site: Copyright Free Pascal team 1993-2007. should be 2009 -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOM patch
Jonas Maebe pisze: On 28 Aug 2009, at 13:10, Dariusz Mazur wrote: - Using PtrInt for doing pointer math is discouraged in favor of PtrUInt; I've changed PtrInt do PtrUInt, but its not possible in each place how to resolve tClass= tClass(PtrUInt +ptrInt) FPC claim: combined unsigned and signed make result 64bit, which is incompatible with pointer what is proper way to resolve this Cast the ptruint to pointer (although I don't know whether this is Delphi-compatible). I know this, but it look strange FCurrBlock := TDOMNode(pointer(ptrUInt(ext) + sizeof(TExtent) + (AElemCount - 1) * FElementSize)); I can change FElementSize and AElemCount to longword but result sizeof is integer much better look FCurrBlock := TDOMNode(ptrInt(ext) + sizeof(TExtent) + (AElemCount - 1) * FElementSize); or ptrUInt( FCurrBlock) := ptrUInt(ext) + sizeof(TExtent) + (AElemCount - 1) * FElementSize; which is proper? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XML canonical
Hi
this is my first approach to implement canonical transform
fromds:CanonicalizationMethod
Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315/
its used in XADES sign.
can somebody review it, if its interesting
--
Darek
{
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. *
* *
* *
*
* BEGIN LICENSE BLOCK *
The contents of this file are subject to the Mozilla Public License
Version 1.1 (the License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.mozilla.org/MPL/
Software distributed under the License is distributed on an AS IS basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for
the specific language governing rights and limitations under the License.
Alternatively, the contents of this file may be used under the terms of the
GNU General Public License Version 2 (the GPL), in which case
the provisions of the GPL are applicable instead of those above.
If you wish to allow use of your version of this file only under the terms
of the GPL and not to allow others to use your version of this file
under the MPL, indicate your decision by deleting the provisions above and
replace them with the notice and other provisions required by the GPL.
If you do not delete the provisions above, a recipient may use your version
of this file under either the MPL or the GPL.
* END LICENSE BLOCK * }
{ changelog
}
unit xmlc14n;
{$H+}
interface
uses
dom,
sysutils,
classes;
type
TXCanonicalizer = class
private
nsStack : TStringList;
function BuildXmlString(ANode: TDOMNode): utf8String;
function BuildAttributes(ANode: TDOMNode): utf8String;
function BuildPI(ANode: TDOMNode): utf8String;
function NormalizeAttributeValue(AValue: utf8String): utf8String;
function NormalizeText(AText: utf8String): utf8String;
function nodeIsNS(aNode : tDomNode):boolean;
function NSStackFind(aName : string):boolean;
protected
procedure init;
procedure done;
public
function Canonicalize(ARootNode: TDOMNode): utf8string;overload;
function Canonicalize(ADoc: TXMLDocument): utf8string;overload;
end;
implementation
function utf8StringReplace(const S, OldPattern, NewPattern: utf8String):
utf8String;
var
SearchStr, Patt, NewStr: WideString;
Offset: Integer;
begin
SearchStr := S;
Patt := OldPattern;
NewStr := S;
Result := '';
while (SearchStr '') do
begin
Offset := system.Pos(Patt, SearchStr);
if Offset = 0 then
begin
Result := Result + NewStr;
Break;
end;
Result := Result + system.Copy(NewStr, 1, Offset - 1) + NewPattern;
NewStr := system.Copy(NewStr, Offset + Length(OldPattern), MaxInt);
SearchStr := system.Copy(SearchStr, Offset + Length(Patt), MaxInt);
end;
end;
function TXCanonicalizer.NormalizeAttributeValue(AValue: utf8String):
utf8String;
begin
Result := AValue;
Result := utf8StringReplace(Result, '', 'quot;');
Result := utf8StringReplace(Result, #9, #32);
Result := utf8StringReplace(Result, #13#10, #32);
Result := utf8StringReplace(Result, #13, #32);
Result := utf8StringReplace(Result, #10, #32);
end;
function TXCanonicalizer.NormalizeText(AText: utf8String): utf8String;
begin
Result := AText;
Result := utf8StringReplace(Result, #13#10, #10);
Result := utf8StringReplace(Result, #13, #10);
end;
function tXCanonicalizer.BuildPI(Anode: TDOMNode):utf8String;
begin
result:='!'
+TDOMProcessingInstruction(Anode).Target
+' '
+TDOMProcessingInstruction(Anode).Data
+''#10;
end;
function tXCanonicalizer.nodeIsNS(aNode : tDomNode):boolean;
begin
result:= (system.Pos('xmlns', LowerCase(aNode.nodeName)) = 1);
end;
function tXCanonicalizer.nsStackFind(aName : string):boolean;
var
i : integer;
begin
result:=nsStack.Find(aName,i);
if not result then
nsStack.add(aName);
end;
function TXCanonicalizer.BuildAttributes(ANode: TDOMNode): utf8String;
var
i: Integer;
attributes, namespaces: TStringList;
element: TDOMElement;
xNSName: string;
procedure parseNS(aNode : tDomNode);
var
i : integer;
xNSName : string;
begin
if aNode.Attributes=nil then exit;
for i := 0 to aNode.attributes.length - 1 do
begin
if
Re: [fpc-devel] XML canonical
Sergei Gorelkin pisze: Dariusz Mazur wrote: I'd suggest you to find a test suite (some examples are contained directly in the text of w3.org specification, others may be ripped from opensource projects that support canonicalization, like libxml2) and verify your unit against it. I draw from libxml2. First i resolved problem with namespaces. That is not so clear in specification. Even simple xml canonization don't work. Now I can work with more complicate file. New version should be send here? I was intending to implement canonicalization in the existing writer (xmlwrite.pp), but namespace support is required before it can be done. (namespace support is present in dom and xmlread, but not yet in xmlwrite). Actually, the writer is already doing most of the things, including proper encoding and escaping. The attributes are already sorted by name. What has to be changed: 1) sorting attributes with respect to namespace 2) write end-tags in full form 3) treat CDATA sections as text 4) don't omit defaulted attributes 5) omit xml declaration and DTD. 6) ...maybe missed something else. 6.sorting namespaces 7. added default namespace (exists above main node - when we write only part of tree) The (1) is most difficult, (2) to (5) are pretty trivial. So for me it seems a better idea to improve the existing writer rather than making a new one. I cannot speak on behalf of the whole team, however. Other opinions are welcome. Now I see what want. Till now I work on old implementation of xmlwrite (C-style) and not notice that was change. I can try reimplement it based on exists. it seem easy. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DOM patch
Hi
I use DOM from fcl-xml both for Delphi and FPC development.
I work with older version, till I notice serious bugs. Today i've
upgrade it from current svn. And problem: Delphi don't compile
I've made several changes in dom, xmlutil. Diff attached.
As i expect, bugs in new version disappear.
It's not change much.
Can someone review it?
--
Darek
Index: xmlwrite.pp
===
--- xmlwrite.pp (wersja 13601)
+++ xmlwrite.pp (kopia robocza)
@@ -17,9 +17,11 @@
unit XMLWrite;
-{$MODE objfpc}
-{$H+}
+{$ifdef fpc}
+{$MODE objfpc}{$H+}
+{$endif}
+
interface
uses Classes, DOM;
Index: dom.pp
===
--- dom.pp (wersja 13601)
+++ dom.pp (kopia robocza)
@@ -43,6 +43,10 @@
// ---
// DOMException
// ---
+{$ifndef fpc}
+type
+ tFpList = tList;
+{$endif}
const
@@ -101,6 +105,8 @@
TDOMAttrDef = class;
PNodePool = ^TNodePool;
TNodePool = class;
+ TTabNodePool = array[0..0] of TNodePool;
+ PTabNodePool = ^TTabNodePool;
// ---
@@ -430,7 +436,7 @@
FEmptyNode: TDOMElement;
FNodeLists: THashTable;
FMaxPoolSize: Integer;
-FPools: PNodePool;
+FPools: PTabNodePool;
FDocumentURI: DOMString;
function GetDocumentElement: TDOMElement;
function GetDocType: TDOMDocumentType;
@@ -3167,24 +3173,24 @@
sz: Integer;
begin
ext := FCurrExtent;
- ptr := Pointer(FCurrBlock) + FElementSize;
+ ptrInt(ptr) := ptrInt(FCurrBlock) + FElementSize;
sz := FCurrExtentSize;
while Assigned(ext) do
begin
// call destructors for everyone still there
-ptr_end := Pointer(ext) + sizeof(TExtent) + (sz - 1) * FElementSize;
-while ptr = ptr_end do
+ptrInt(ptr_end) := ptrInt(ext) + sizeof(TExtent) + (sz - 1) * FElementSize;
+while ptrInt(ptr) = ptrInt(ptr_end) do
begin
if TDOMNode(ptr).FPool = Self then
TObject(ptr).Destroy;
- Inc(ptr, FElementSize);
+ Inc(ptrInt(ptr), FElementSize);
end;
// dispose the extent and pass to the next one
next := ext^.Next;
FreeMem(ext);
ext := next;
sz := sz div 2;
-ptr := Pointer(ext) + sizeof(TExtent);
+ptrInt(ptr) := ptrInt(ext) + sizeof(TExtent);
end;
inherited Destroy;
end;
@@ -3194,13 +3200,13 @@
ext: PExtent;
begin
Assert((FCurrExtent = nil) or
-(Pointer(FCurrBlock) = Pointer(FCurrExtent) + sizeof(TExtent)));
+(ptrInt(FCurrBlock) = ptrInt(FCurrExtent) + sizeof(TExtent)));
Assert(AElemCount 0);
GetMem(ext, sizeof(TExtent) + AElemCount * FElementSize);
ext^.Next := FCurrExtent;
// point to the beginning of the last block of extent
- FCurrBlock := TDOMNode(Pointer(ext) + sizeof(TExtent) + (AElemCount - 1) *
FElementSize);
+ FCurrBlock := TDOMNode(ptrInt(ext) + sizeof(TExtent) + (AElemCount - 1) *
FElementSize);
FCurrExtent := ext;
FCurrExtentSize := AElemCount;
end;
@@ -3214,7 +3220,7 @@
end
else
begin
-if Pointer(FCurrBlock) = Pointer(FCurrExtent) + sizeof(TExtent) then
+if ptrInt(FCurrBlock) = ptrInt(FCurrExtent) + sizeof(TExtent) then
AddExtent(FCurrExtentSize * 2);
Result := FCurrBlock;
Dec(PChar(FCurrBlock), FElementSize);
Index: xmlutils.pp
===
--- xmlutils.pp (wersja 13601)
+++ xmlutils.pp (kopia robocza)
@@ -14,14 +14,20 @@
**}
unit xmlutils;
-{$mode objfpc}
-{$H+}
+{$ifdef fpc}
+{$MODE objfpc}{$H+}
+{$endif}
interface
uses
SysUtils;
+ {$IFNDEF FPC}
+
+type ptrint=integer;
+{$ENDIF}
+
function IsXmlName(const Value: WideString; Xml11: Boolean = False): Boolean;
overload;
function IsXmlName(Value: PWideChar; Len: Integer; Xml11: Boolean = False):
Boolean; overload;
function IsXmlNames(const Value: WideString; Xml11: Boolean = False): Boolean;
@@ -38,6 +44,7 @@
{ a simple hash table with WideString keys }
type
+ PTabPHashItem = ^TTabPHashItem;
PPHashItem = ^PHashItem;
PHashItem = ^THashItem;
THashItem = record
@@ -46,6 +53,7 @@
Next: PHashItem;
Data: TObject;
end;
+ TTabPHashItem = array[0..0] of pHashItem;
THashForEach = function(Entry: PHashItem; arg: Pointer): Boolean;
@@ -53,7 +61,7 @@
private
FCount: LongWord;
FBucketCount: LongWord;
-FBucket: PPHashItem;
+FBucket: PTabPHashItem;
FOwnsObjects: Boolean;
function Lookup(Key: PWideChar; KeyLength: Integer; var Found: Boolean;
CanCreate: Boolean): PHashItem;
procedure Resize(NewCapacity: LongWord);
@@ -82,12 +90,15 @@
lname: PWideChar;
lnameLen: Integer;
end;
+ PTabExpHashEntry = ^TTabExpHashEntry;
+ tTabExpHashEntry = array[0..0] of TExpHashEntry;
+
TDblHashArray =
[fpc-devel] XML canonical form
Hi Is any way to convert xml to canonical form when DOM is used -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Hi
I include res file to executed file. Res is compiled by brcc32
from RC. Till now everything work OK.
But when i try extract big PNG picture from RES I had wrong size
of file.
File has length 136303.
When I read it from res length is 5321. This seems size of res
is 16 bit.
This is intentional that size of resource is limited ?
Not intentionally, at least not that I am aware of. Maybe there is
a bug ?
I use {$R file.res}
How prepare testcase: should I attach big PNG+RC+RES file?
Yes, but please test with 2.3.1 first. the resource mechanism was
rewritten.
I made some test
FPC 2.3.1 with RC compiled by binutils windres - everything is OK
FPC 2.3.1 with RES compiled by brcc32 - 131kb png is not found
Strange behaviour of brcc32. Does it work with Delphi ?
Yes, I do it every day. But I try it once more from ground.
FPC.2.2.4 with RC compiled by binutils windres -
131kB PNG - size from resource is 5231
50KB PNG - size from resourse is 4294951983 (sic)
FPC.2.2.4 with RC compiled by brcc32 -
131kB PNG - size from resource is 0 (absent)
50KB PNG - size from resourse is 4294951983
I can make and upload more test, but which?
Is there any chance to make patch to FPC 2.2.4 (its stable)
Not likely. The fixes in resources are HUGE, and have not been merged
to 2.2.4 for this reason.
That's not good for me. I don't want change to unstable compiler.
I must do something other.
The problem seems most likely to be in the resource compilers. Neither of
them are maintained by FPC, so we cannot fix that. It would be useful to
see if the brcc32 resource compiler produces a correct .res by trying
to extract it from Delphi.
I don;t understand.
i've compiled RES from RC by brcc32 on windows and copy to linux.
I use several RES with hundred files. Till now i have no problem.
If you don't have Delphi, can you make a sample program that tests it
? Then I will try to compile and run.
OK
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
Vincent Snijders pisze: Graeme Geldenhuys schreef: Dariusz Mazur wrote: I can make and upload more test, but which? Is there any chance to make patch to FPC 2.2.4 (its stable) Not likely. The fixes in resources are HUGE, and have not been merged to 2.2.4 for this reason. That's not good for me. I don't want change to unstable compiler. I must do something other. Alternatively, if an older version of FPC 2.2.x or 2.0.x worked, then maybe you could switch to that instead. Or maybe implement the fix locally in your version of 2.2.5. I have done this for our company as well - created local fixes for the 2.2.x branch which will not be merged with the FPC repository (for whatever reason), and no we also did not want to switch to the unstable 2.3.x branch for production work. If you have a patch to merge the resources support to the fixes_2_2 branch, I am interested too. It is one of the highlights from fpc 2.3 from a Lazarus point of view. Maybe merge all from 2.3.1 Its only 3 patch: 10481,9697,9703 -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Hi
I include res file to executed file. Res is compiled by brcc32
from RC. Till now everything work OK.
But when i try extract big PNG picture from RES I had wrong size
of file.
File has length 136303.
When I read it from res length is 5321. This seems size of res
is 16 bit.
This is intentional that size of resource is limited ?
Not intentionally, at least not that I am aware of. Maybe there is
a bug ?
I use {$R file.res}
How prepare testcase: should I attach big PNG+RC+RES file?
Yes, but please test with 2.3.1 first. the resource mechanism was
rewritten.
I made some test
FPC 2.3.1 with RC compiled by binutils windres - everything is OK
FPC 2.3.1 with RES compiled by brcc32 - 131kb png is not found
Strange behaviour of brcc32. Does it work with Delphi ?
I test it once more, on 2.3.1 all is OK
FPC.2.2.4 with RC compiled by binutils windres -
131kB PNG - size from resource is 5231
50KB PNG - size from resourse is 4294951983 (sic)
FPC.2.2.4 with RC compiled by brcc32 -
131kB PNG - size from resource is 0 (absent)
50KB PNG - size from resourse is 4294951983
I can make and upload more test, but which?
Is there any chance to make patch to FPC 2.2.4 (its stable)
Not likely. The fixes in resources are HUGE, and have not been merged
to 2.2.4 for this reason.
The problem seems most likely to be in the resource compilers. Neither of
them are maintained by FPC, so we cannot fix that. It would be useful to
see if the brcc32 resource compiler produces a correct .res by trying
to extract it from Delphi.
If you don't have Delphi, can you make a sample program that tests it
? Then I will try to compile and run.
on mantis 14122 test program is added
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] compile resource
is possible to change which program is used to compile resource? is old and new version fpcres, FPC 2.2.4 should use old, FPC 2.3.1 new how achieve this ? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] big resource
Hi I include res file to executed file. Res is compiled by brcc32 from RC. Till now everything work OK. But when i try extract big PNG picture from RES I had wrong size of file. File has length 136303. When I read it from res length is 5321. This seems size of res is 16 bit. This is intentional that size of resource is limited ? I use FPC 2.2.2 under Linux. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Hi
I include res file to executed file. Res is compiled by brcc32 from
RC. Till now everything work OK.
But when i try extract big PNG picture from RES I had wrong size of
file.
File has length 136303.
When I read it from res length is 5321. This seems size of res is
16 bit.
This is intentional that size of resource is limited ?
Not intentionally, at least not that I am aware of. Maybe there is a
bug ?
I use {$R file.res}
How prepare testcase: should I attach big PNG+RC+RES file?
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Hi
I include res file to executed file. Res is compiled by brcc32
from RC. Till now everything work OK.
But when i try extract big PNG picture from RES I had wrong size of
file.
File has length 136303.
When I read it from res length is 5321. This seems size of res
is 16 bit.
This is intentional that size of resource is limited ?
Not intentionally, at least not that I am aware of. Maybe there is a
bug ?
I use {$R file.res}
How prepare testcase: should I attach big PNG+RC+RES file?
Yes, but please test with 2.3.1 first. the resource mechanism was
rewritten.
I made some test
FPC 2.3.1 with RC compiled by binutils windres - everything is OK
FPC 2.3.1 with RES compiled by brcc32 - 131kb png is not found
FPC.2.2.4 with RC compiled by binutils windres -
131kB PNG - size from resource is 5231
50KB PNG - size from resourse is 4294951983 (sic)
FPC.2.2.4 with RC compiled by brcc32 -
131kB PNG - size from resource is 0 (absent)
50KB PNG - size from resourse is 4294951983
I can make and upload more test, but which?
Is there any chance to make patch to FPC 2.2.4 (its stable)
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] path for *.res file
Jonas Maebe pisze: On 23 May 2009, at 11:05, Vincent Snijders wrote: Can't the searching be extended to the unit directory. It would make the file C:\fpc\2.2.4\units\i386-win32\fcl-base\fclel.res really useful, now have to copy it to my program dir to be able to use deamonapp unit. WDDD? (What Does Delphi Do) If Delphi also somehow has support for resource search paths (via the unit search path or otherwise), it doesn't make sense to implement a different solution. (since in that case someone will probably file a bug report at some point asking for also supporting it in a Delphi-compatible way). I have all *.res files in one separate directory in Delphi (via search path). Now I try to use *.res in Linux. Everything goes fine, FPC can handle ordinary *.res, although *.rc has to be compiled by brcc32 -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] path for *.res file
Hi How to tell compiler where are *.res files. I've try -Fu, -Fi, -Fo directives in fpc.cfg but always path of main source is used. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] runtime error 216 on nested procedures
Hi
I have problem with this small program below. I've compiled if on
Linux/i386 FPC 2.2.2
Every time of run program halt with runtime. I've test it with short and
ansistring. Result the same.
But when I uncomment line with test2 everything goes OK.
Is something wrong with program? Can someone test it on newer version FPC?
program testwhile;
{$mode objfpc}{$H+}
function lineHtml( sa : string):string;
var
xPoz : integer;
xp,xk : integer;
function nextToken(var aPocz: integer;var aKon :integer):string;
begin
result:='';
aPocz:=xPoz+1;
aKon:=0;
try
while xpoz length(sa) do begin
inc(xpoz);
case sa[xpoz] of
'|' :begin
exit;
end;
else
end;
result:=result+sa[xpoz];
inc(aKon);
end;
finally
writeln('test ',result);
aKon:=aPocz+aKon;
//writeln('test2 ',result);
end;
end;
begin
xpoz:=0;
result:='';
repeat
nextToken(xp,xk);
until xpoz=length(sa);
end;
begin
writeln(lineHTML('| 1 | 2 | 3'));
end.
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] test fpcres
Hi
I've check tests for Test suite results for test file
test/units/system/tres2.pp
but I nottice that different fpcres is use to compile
in trunk is ver 2.0{ Note: This program is not the old fpcres by
Simon Kissel }
but is use old :
Log of 35027:
Error: Unknown command-line parameter : -a
fpcres - Free Pascal Resource to ELF object compiler
Part of the Free Pascal and CrossFPC distributions
Copyright (C) 2005 Simon Kissel
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] tNode.isequal optimization
Hi
I've read some code of compiler (try to understand how it work)
and I notice, that tNode.isequal is invoked very often but has not
optimal (by me) implementation
my proposition is (one assigned less):
function tnode.isequal(p : tnode) : boolean;
begin
if assigned(self) then begin
result:=(assigned(p) and
(p.classtype=classtype) and
(p.nodetype=nodetype) and
(flags*flagsequal=p.flags*flagsequal) and
docompare(p));
end else
result:=not assigned(p);
end;
(**original*
isequal:= (not assigned(self) and not assigned(p)) or
(assigned(self) and assigned(p) and
{ optimized subclasses have the same nodetype as their}
{ superclass (for compatibility), so also check the classtype
(JM) }
(p.classtype=classtype) and
(p.nodetype=nodetype) and
(flags*flagsequal=p.flags*flagsequal) and
docompare(p));
*)
and second:
make isequal inlined, then in function
function tunarynode.docompare(p : tnode) : boolean;
begin
docompare:=(inherited docompare(p) and
(not assigned(left) or left.isequal(tunarynode(p).left))
);
end;
compiler can fold two equal node : not assigned(left) or
((assigned(p) and
{ optimized subclasses have the same nodetype as their}
{ superclass (for compatibility), so also check the classtype
(JM) }
(p.classtype=classtype) and
(p.nodetype=nodetype) and
(flags*flagsequal=p.flags*flagsequal) and
docompare(p));
Will those optimization give better code?
Can compiler remove unnecessary nodes in boolean operation after inline
unfolding?
--
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SSE in FPC
Jonas Maebe pisze: Of course tSSEVector should be declared in System unit. Then any one can use SSE intentionally Why can't you now? It's not like multiplication has any other meaning for arrays. And declaring magic compiler types in the system unit is something that should be avoided as much as possible (it makes both the compiler and rtl harder to adapt and understand). Of course, but SIMD is thing, which has more and more impact to performance. And compiler should respect it (and do this, as Florian said). But till now nobody know, where compiler use SSE instruction. In my mind, to achieve this is declare some primitives represents SSE types. On one side there are magic compiler types but on second there exists in real world (most of used CPU has them). And it will be harmless, because its not change in language (we can use record, array) and is easy implement needed primitives in pure pascal. Its very similar to IEEE-754: on platform where FPU not exists all function are implemented by hand. -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SSE in FPC
Florian Klaempfl pisze: Dariusz Mazur schrieb: Jonas Maebe pisze: Of course tSSEVector should be declared in System unit. Then any one can use SSE intentionally Why can't you now? It's not like multiplication has any other meaning for arrays. And declaring magic compiler types in the system unit is something that should be avoided as much as possible (it makes both the compiler and rtl harder to adapt and understand). Of course, but SIMD is thing, which has more and more impact to performance. And compiler should respect it (and do this, as Florian said). But till now nobody know, where compiler use SSE instruction. Of course one knows. For array operations as shown SSE/SSE2 is used if enabled. ___ Ok. I only want to discover how to use it. if I write type tSSEVector = array[0..1] of double var d1 : tSSeVector; d2 : array[0..1]of tSSEVector; begin d1:=d2[0]*d2[1]; end; will be work too? Or something like this: function f ; var d1,d2,d3 : array[0..4] of integer; begin d1:=d2*d3; end; -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SSE in FPC
Florian Klaempfl pisze: Dariusz Mazur schrieb: Florian Klaempfl pisze: Dariusz Mazur schrieb: Jonas Maebe pisze: Of course tSSEVector should be declared in System unit. Then any one can use SSE intentionally Why can't you now? It's not like multiplication has any other meaning for arrays. And declaring magic compiler types in the system unit is something that should be avoided as much as possible (it makes both the compiler and rtl harder to adapt and understand). Of course, but SIMD is thing, which has more and more impact to performance. And compiler should respect it (and do this, as Florian said). But till now nobody know, where compiler use SSE instruction. Of course one knows. For array operations as shown SSE/SSE2 is used if enabled. ___ Ok. I only want to discover how to use it. if I write type tSSEVector = array[0..1] of double var d1 : tSSeVector; d2 : array[0..1]of tSSEVector; begin d1:=d2[0]*d2[1]; end; will be work too? Yes. Thanks. Now I understand. Or something like this: function f ; var d1,d2,d3 : array[0..4] of integer; begin d1:=d2*d3; end; No. Not yet implemented iirc. But will be in the same manner? -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SSE in FPC
Florian Klaempfl pisze:
Jonas Maebe schrieb:
On 29 Nov 2008, at 11:11, Felipe Monteiro de Carvalho wrote:
You can tell FPC to do the SSE code for you:
-Cfx Select fpu instruction set to use, see fpc -i for
possible values
That only applies to (scalar) FPU operations at this time. It won't do
any (auto or other) vectorisation.
With -Sv -Cfsse2 you can compile things like
I know this, but its hard to discover where and when is is used. Often
is good, when compiler make optimization itself, but some times is
better tell them about possible vectorization.
function f : double;
var
d1,d2,d3 : array[0..1] of double;
begin
d1:=d2*d3;
end;
I would expect some thing like this
type
tSSEvector= packed record of
a,b : double;
end;
{ or }
tSSEvector= array[0..1] of double;
function f : double;
var
d1,d2,d3 : tSSEVector;
begin
d1:=d2*d3;
end;
Of course tSSEVector should be declared in System unit.
Then any one can use SSE intentionally.
However, it's not well tested.
Is there a list of SSE function, which can FPC use?
Darek
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SSE in FPC
Mattias Gaertner pisze: On Fri, 28 Nov 2008 21:25:16 +0100 darekm [EMAIL PROTECTED] wrote: Hi Are in FPC some instruction set contains streaming SIMD (SSE) like in GCC: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/X86-Built_002din-Functions.html or in Microsoft Visual http://msdn.microsoft.com/en-us/library/kcwz153a(VS.80).aspx Use the mmx unit to discover what mmx/sse instruction set is supported by your cpu. You can use mmx/sse commands directly in the asm blocks and FPC automatically uses MMX/SSE instructions for your pascal code if you allow it (specify CPU type). In my experiments FPC often created faster code itself. So don't expect much speed gain when using SSE instructions directly. MMX can operate on 2 longint simultaneous and SSE on 4, FPC often sometime make optimization to SSE, thus is faster. I don't want write SSE instruction by hand, but would by nice to to tell to compiler, where those optimization should be made (if its possible) Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] membar instruction
Hi is there in FPC a membar instruction, like #StoreLoad macro or smp_mb(); and second need instruction is NOOP Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] membar instruction
Micha Nelissen pisze: Dariusz Mazur wrote: Hi is there in FPC a membar instruction, like #StoreLoad macro or smp_mb(); ReadBarrier, ReadDependencyBarrier, ReadWriteBarrier, WriteBarrier; in system unit. thx and second need instruction is NOOP Don't know about this one, can't you use a do nothing loop? in spin-lock there is NOOP used, I think that is instruction, that every processor do nothing but not avoid (duration is very small but not zero) Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] membar instruction
Micha Nelissen pisze: Dariusz Mazur wrote: Don't know about this one, can't you use a do nothing loop? in spin-lock there is NOOP used, I think that is instruction, that every processor do nothing but not avoid (duration is very small but not zero) Why do you use a NOP in a spin-lock? its only exaple form sparc manual, I need (I want to test) it to in my FIFO algo. form SPARCV9.PDF: LockWithLDSTUB(lock) retry: ldstub [lock],%l0 tst %l0 be out nop loop: ldub [lock],%l0 tst %l0 bne loop nop ba,a retry out: membar #LoadLoad | #LoadStore UnLockWithLDSTUB(lock) membar #StoreStore !RMO and PSO only membar #LoadStore !RMO only stub %g0,[lock] Example 7---Lock and Unlock Using LDSTUB Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LockFree Queue algorithm
Michael Schnell pisze: FUTEX is based on atomic operation, the same as I used. but with lockfree algorithms You don't protect access at all. I understand this, but I'm nut sure that this really is advantageous. Any atomic operation in a multicore system with a cache for each core imposes a delay for cache synchronization. Any implementation of thread synchronization need care of cache. FUTEX, which rely on atomic primitives can't be faster than primitives alone. In lockfree algorithms we don't block data structures at all. In any time others threads can process data. Many of researches claim that lockfree algorithms are faster, specially with many concurrent threads. Thus as little as possible lock operations should be issued. 99,99% of the calls will not see another processor or thread concurrently working on the FiFo data. You have to prevent data loss, when You have hazard with concurrent process see: http://en.wikipedia.org/wiki/Concurrency_control And when You block access do data, others thread stop. The implementation similar to Futex in the no blocked case needs one lock operation on entry and one on exit. Thus using a thing similar to FUTEX needs some 2,0001 locked operations per call. \ I don;t understand this Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LockFree Queue algorithm
Florian Klaempfl pisze: DarekM schrieb: Florian Klaempfl pisze: An if is unimportant, more important is the number of locked operations, especially on multi core systems they might eat hundreds of clock cycles. There are atomic operations, the should not eat much more than ordinal INC or ADD, If course they are. They require no more a bus lock as in 486 times but a synchronization of all caches for this particular memory location. We don't need wait to synchronize caches. It will be done by hardware. And i think synchronize cache with ram don't eat hundreads clock cycles. And CMPXCHG has automatic locking asserted, as normal instruction can't persist so long (Intel don't mention about this) This is also use to implement semaphores (suggest from Intel) , thus should be save and fast. Form intel about caching: http://www.intel.com/design/processor/manuals/253668.pdf Intel Architecture Compatibility Beginning with the Pentium Pro processor, when the LOCK prefix is prefixed to an instruction and the memory area being accessed is cached internally in the processor, the LOCK# signal is generally not asserted. Instead, only the processors cache is locked. Here, the processors cache coherency mechanism insures that the operation is carried out atomically with regards to memory. Refer to Section 7.1.4., Effects of a LOCK Operation on Internal Processor Caches in Chapter 7, Multiple-Processor Management of the Intel Architecture Software Developers Manual, Volume 3, the for more information on locking of caches. Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
