Re[2]: [fpc-devel] Proposal: Enhanced replacement for assignment operators
Hello Adem, Friday, August 6, 2010, 6:48:22 PM, you wrote: A> IOW, write a small/simple utility that converts a given source to/from A> those shorthand operators to/from their long form. A> If there was such a thing and if it produced code that compiled to give A> identical results, I would have no problems with the proposal. Sone questions, what's the result of: a:=2; a*=a++; and: a:=1; a:=a++1; Algebra says one thing, and C a different one. Are ++ operators right to left ? And how about non commutative operators ? a:=1; a:=2 div a; How to write it shorter ? a*=b - 2; How is this resolved ? a:=a*b-2 or a:=a*(b-2) ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LocalReferenceFixup
Hello FPC, I find a problem that I'm unable to resolve, with my limited skills. In TReader when a property is a TClass it is being added to be resolved after all components are loaded, but the "Loaded" call is performed before this fixup, so when a component receive the "Loaded" signal some fields are still not completly filled in. This is terrible in the SQLQuery (from Lazarus) as if you left anyone "Active" it always complaint in runtime with "Database not set". :( -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello Martin, Tuesday, October 5, 2010, 9:56:41 AM, you wrote: >> I find a problem that I'm unable to resolve, with my limited skills. >> In TReader when a property is a TClass it is being added to be >> resolved after all components are loaded, but the "Loaded" call is >> performed before this fixup, so when a component receive the "Loaded" >> signal some fields are still not completly filled in. MS> Use MS> " MS> procedure BeginGlobalLoading; MS> procedure NotifyGlobalLoading; MS> procedure EndGlobalLoading; MS> " I see, but there is still a problem, I think. Let me explain: 1) Component is being read, it reads Active property, if set and csLoading then the "active" is postponed to "afterload". 2) The "Database" property is being read, but as it is a TClass it is added to LocalFixups. 3) The remaining properties are beign read. 4) Component is notified with "Loaded" signal, so it tries to active itself, but database is not set. 5) Fixups are performed. 6) Component is notified again with "Loaded" signal. I do not know how to instruct the component to skip the first "Loaded" signal and wait for the next one, specially because if "Database" is not set (trully error) the second "Loaded" signal will not be fired. Maybe a component state like "csFixupsPending" ? I do not have too much experience with components, but calling "Loaded" several times does not look very fine. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[3]: [fpc-devel] LocalReferenceFixup
Hello FPC,
Tuesday, October 5, 2010, 1:10:43 PM, you wrote:
>> I do not have too much experience with components, but calling
>> "Loaded" several times does not look very fine.
MVC> To the best of my knowledge: it should be called once only, after the
fixups.
MVC> If it isn't so, this is a bug.
Extracted from "reader.inc", comments below...
--
[...]
procedure TReader.FixupReferences;
var
i: Integer;
begin
DoFixupReferences;
GlobalFixupReferences;
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[I]).Loaded;
end;
[...]
function TReader.ReadRootComponent(ARoot: TComponent): TComponent;
[...]
if Assigned(GlobalLoaded) then
FLoaded := GlobalLoaded
else
FLoaded := TFpList.Create;
try
if FLoaded.IndexOf(FRoot) < 0 then
FLoaded.Add(FRoot);
FOwner := FRoot;
FRoot.FComponentState := FRoot.FComponentState + [csLoading, csReading];
FRoot.ReadState(Self);
Exclude(FRoot.FComponentState, csReading);
if not Assigned(GlobalLoaded) then begin
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[i]).Loaded;//
end;
finally
if not Assigned(GlobalLoaded) then
FLoaded.Free;
FLoaded := nil;
end;
GlobalFixupReferences;
[...]
end;
procedure TReader.ReadData(Instance: TComponent);
[...]
{ Fixup references if necessary (normally only if this is the root) }
If (Instance=FRoot) then
DoFixupReferences;
end;
[...]
--
As you can see the "Loaded" event is called (marked with some //-)
before calling "GlobalFixupReferences", I'll try to add some writeln's
here and there to catch the event sequence and post it here for
further comments.
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC,
Tuesday, October 5, 2010, 4:08:08 PM, you wrote:
>> As you can see the "Loaded" event is called (marked with some //-)
>> before calling "GlobalFixupReferences",
MS> Not if GlobalLoaded is set.
Yes, but it is not set, because BeginGlobalLoading is not called at
all from any point in the code, nor in fpc/rtl nor in Lazarus lcl, nor
in Lazarus IDE, but the IDE is not the important thing as the main
problem is at runtime. Only LNet httpsvlt is calling the
"BeginGlobalLoading" unless some other call it using some kind of
opaque pointer :-?
-
F:\Lazarus>find "begingloballoading" *.pas;*.pp;*.inc /s
0 lines in 0 files
F:\Lazarus>\fpc\svn\
F:\fpc\svn>find "begingloballoading" *.pas;*.pp;*.inc /s
F:\fpc\svn\packages\fcl-net\src\httpsvlt.pp
BeginGlobalLoading;
F:\fpc\svn\rtl\objpas\classes\classes.inc
procedure BeginGlobalLoading;
{ Free the memory occupied by BeginGlobalLoading }
F:\fpc\svn\rtl\objpas\classes\classesh.inc
procedure BeginGlobalLoading;
4 lines in 3 files
-
Is each component which must call "BeginGlobalLoading" ? or is the
read logic which must decide when activate the globalloading ?
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Wednesday, October 6, 2010, 8:37:44 AM, you wrote: >> Yes, but it is not set, because BeginGlobalLoading is not called at [...] MS> Avoid circular component references in the forms and adjust the creation order MS> that the referencing forms are created later or use [...] MS> Lazarus: MS> " MS> begingloballoading; MS> [...] create the forms MS> notifygloballoading; MS> endgloballoading; MS> " MS> (not tested). I think I can see your point, but from the "end user" point of view this is not a possibility. How to tell to the user, "Remeber you must call beginglobal... and notifyglobal... and finally endglobal... when you create forms with components that need a global loading link reference fixup" :-? Moreover user can not take care of creation order, it is not deterministic (AFAIK), there is no way to change it in Lazarus and finally it defeats the drag/drop/design paradigm. I have a form with 25 SQLQuery, 23 of them are chained in some way, if I need a new one at the beginning I must delete 23, add the new one, create or paste the 23 again and relink manually again ? So the final question, should this moved from fpc-devel to Lazarus mailing list ? Is it not considered a bug in the TReader ? Thank you. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Thursday, October 7, 2010, 8:27:23 AM, you wrote: MS> Maybe you mix up component creation order and form/datamodule creation order? MS> I wrote about form/datamodule creation order. The datamodule is created just in program load, before any dependent component is created, so my execution layout is: 1) Main form create (only a bunch of visual options). 2) Datamodules are being created and will keep loaded up to main form destroy. 3) When user selects an option in main form, the new form, with some SQLQuery components inside linked with the already loaded datamodule(s), is being created and the problem happends. MS> MSEide does not create the code for loading additional forms and datamodules MS> exactly because it is necessary that the user knows what is going on there. MS> Please have a look into the program file of your application. I repeat: MS> If there are interlinked forms/datamodules either: MS> - Avoid circular component references. MS> - Create the referencing forms/datamodules after the referenced MS> forms/datamodules. I'm not using MSEide, but of course all referenced objects (databases in this case) are being created before the conflictive forms/components. MS> Or: MS> - Call msebegingloballoading. MS> - Create the forms/datamodules. MS> - Create mseendgloballoading. I'll check this approach, but just to circunvent the problem. A different thing is that maybe the bug/problem is in SQLQuery, in TReader, in Lazarus logic or in any other piece of code. MS> A Lazarus adept may write the necessary steps for Lazarus. MS> If you get the exception in a single form without external component MS> references, that would be another story... I'm not sure 100%, changed the database connections to datamodules to keep forms a bit cleaner, but I'm quite sure that the same problem happends using a single form with all needed components in the form (as in the past). As you are the only one replaying (a lot of thanks) this makes me think that other developers think that this behavior is OK in TReader, so I'll try to post a simple form code in the Lazarus list and ask for feedback about how it should work. Thank you again for your support. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Thursday, October 7, 2010, 8:30:06 PM, you wrote: MS> Aha. In MSEgui application.createform()/createdatamodule() must be called in MS> order to allow component linking with already loaded modules, t*form.create() MS> is not enough. I don't know how this works in Lazarus. Thank you, I'll try to gather more information from Lazarus list, but if that's the case it completly defeats the advantages of a datamodule and/or the presence of a published Active property in the SQLQuery (as it is only valid if it is false at runtime) :-? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Thursday, October 7, 2010, 9:21:18 PM, you wrote: >> Thank you, I'll try to gather more information from Lazarus list, but >> if that's the case it completly defeats the advantages of a datamodule >> and/or the presence of a published Active property in the SQLQuery (as >> it is only valid if it is false at runtime) :-? MS> No, no, in MSEgui it works OK if you call MS> application.createform(t*form,*forminstance); MS> instead of MS> *forminstance:= t*form.create(); MS> I assume in Lazarus it works too. Hm... I was not aware that both modes does not end in the same functionality... (I allways use "n:=TNewForm.Create(Self)") I'll check it. Thank you again. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Friday, October 8, 2010, 8:35:44 AM, you wrote: >> Aha. In MSEgui application.createform()/createdatamodule() must be called in >> order to allow component linking with already loaded modules, t*form.create() >> is not enough. I don't know how this works in Lazarus. MG> In Lazarus both use the same loading mechanism. Referenced MG> datamodules are automatically found if they already exist. MG> The main difference is that CreateForm sets the variable (e.g. MG> Form1) before it creates and loads the form, while MG> Form1:=TForm1.Create(nil) sets Form1 after creation and loading. MG> It is up to the programmer to create the forms and datamodules in the MG> right order. If you have circle dependencies, follow Martin's advice MG> and enclose the creation of datamodule and forms in MG> Begin/Notify/EndGlobalLoading. I'm not aware about any cycle dependency, but I'm not completly sure as I do not know which kind of dependency (from the technical point of view I think) you are talking about, so I'll explain a layuot to try to narrow the source of the problem (my design or library design): I have a very simple application, 2 forms and 1 datamodule. The first form is a simple "select your option" which will load all forms on demand. When this main form is loaded the datamodule is being created also, but not the second form. Datamodule -- In datamodule I have 1 firebird connection and 1 firebird transaction. The connection is at design time linked with the transaction via property and proper connect data is filled in. Secondary form -- It have a simple SQLQuery, linked with the firebird connection in the datamodule. Transaction property is automagically filled with the firebird connection transaction. The "Active" property is set to true and at design time if I drop a grid I can see that data is being retrieved. Relationship MainSecond form Datamodule +--+ +--++---+ | | | SQLQuery |+---> SQLConnection --+ |Button-->|| || | | | +--+ ++--+---> Transaction <---+ +---+ Creation order -- 1) Create main form 2) Create data module 3) Wait in main form for user input 4) Create second form I had put some writeln in the source code at the property sets of active and database of SQLQuery and the expected sequece is: -- qryGroupClientsWatch set active to: -1 qryGroupClientsWatch set to database qryGroupClientsWatch set active to: -1 -- First line receives the "Active:=true", but as csLoading is present it sets a flag to activate after complete loading, second line sets the database property and the third line should came from the "Loaded" event which checks the flag and if not csLoading is present try to open the dataset. This layout must work. But the layout that I receive is: -- qryGroupClientsWatch set active to: -1 qryGroupClientsWatch set active to: -1 -- First line is the "Active:=true", as csLoading is present the activate is delayed. The reader reads the database property, as it is a tkClass it add it to LocalReferenceFixups and do not set the property (so no call to property set), and them the "Loaded" event is fired and as csLoading is not present it tries to open the dataset raising the "database not set" exception. I hope I had explained it in detail. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Friday, October 8, 2010, 1:41:39 PM, you wrote: >> Creation order >> -- >> 1) Create main form MS> application.createform() or t*form.create() >> 2) Create data module MS> application.createdatamodule(); >> 3) Wait in main form for user input >> 4) Create second form MS> application.createform() or t*form.create() MS> Such a scenario works in MSEgui. Application.Initialize; Application.CreateForm(TfrmWorkbench, frmWorkbench); Application.CreateForm(TdmCharting, dmCharting); Application.Run; procedure TfrmWorkbench.BitBtn5Click(Sender: TObject); var r: TfrmReportByFile; begin Application.CreateForm(TfrmReportByFile,r); r.Show; end; Does not work in Lazarus almost up to date SVN, and fpc 2.5.1 July 2010 But if my memory serves me, it does not work at least since Lazarus 0.9.26 and the related fpc version. I had not reported it before because I think that the problem was the missing datamodules, so I converted everything to use datamodules, but the problem remains. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Monday, October 11, 2010, 9:07:44 AM, you wrote: >> Attached is the example. One form that load a "menu" which opens a new >> form which display a table in a grid. You will need to change the >> password setup, and maybe database (I'm using aliases instead full >> path), and of course the sql line. >> Example is an small Lazarus project. MS> I converted the example to MSEgui, works OK. So or the problem is in LCL or I'm suffering some kind of poltergeist. Thank you taking the time to perform the test. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Two trivial patches
Hello FPC, There are two more or less trivial patches in the bug tracker since august against database. The first one is completly trivial: [Patch] Missing one ftFixedChar and ftDateTime in "memds" http://bugs.freepascal.org/view.php?id=17308 The next one is trivial but it may require a confirmation by Joost: Dataset SQLQuery crash on "IndexFieldNames" http://bugs.freepascal.org/view.php?id=15460 [Last comment] The issue is not completly fixed, I think the "setrecno" should use the active index also in the same way as the getrecno. May anyone consider review them ? Thank you. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] bug in fpdoc HTML output - double spacing
Hello FPC, Monday, November 8, 2010, 10:57:00 AM, you wrote: >>I don't know HTML well enough to know what all the stuff in DTD files mean >>or do, but I gather having it listed in the generated HTML is important? AC> Well, DTD is one W3C recommendation, specifies the rules for correct AC> rendering AC> for all browsers. Standards are important, so I think that DTD declaration AC> should be AC> left. The "double" lines effect is due the presence of tags in table cells. A tag implies a carriage return so changing tag by a tag "solves" the double line effect. I do not know if tag is mandatory somehow in the generated tables :-? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] constref in Windows
Hello FPC,
In fpc 2.5.1 trunk today the QueryInterface in rtl\inc\objpash.inc is
defined as:
IUnknown = interface
['{---C000-0046}']
function QueryInterface({$IFDEF FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF}
iid : tguid;out obj) : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _AddRef : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
function _Release : longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
end;
IInterface = IUnknown;
Which after the resolved ifdefs it is compiled in Windows as:
IUnknown = interface
['{---C000-0046}']
function QueryInterface(constref iid : tguid;out obj) : longint; stdcall;
function _AddRef : longint; stdcall;
function _Release : longint; stdcall;
end;
IInterface = IUnknown;
Which breaks the compilation of source code like Zeos which expect the
"iid: tguid" to be const, not constref.
I'm aware about the changes done to be XPCOM compatible, but at the
price of "breaking" all existing COM code ? OK, the break is quite
easy to solve, just replace const by contref, but the question is...
Is needed to change it to constref in Windows platform too ?
I know Joost do the changes, but I think direct email is not a good
choice unless no answer in list of course.
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] constref in Windows
Hello Joost, Friday, November 19, 2010, 1:02:59 PM, you wrote: JvdS> Well, this issue leaded to a large discussion elsewhere. I was wondering JvdS> when someone else would even notice this incompatibility. A lot of JvdS> alternatives have been discussed, but I coud not find any which is less JvdS> intrusive. I had followed the discussion in the public lists but not in the development internal lists. JvdS> In an nutshell: the behavior of 'const' parameters is undefined. When JvdS> using cdecl the 'const' keyword is simply ignored. But we do need to JvdS> pass the GUID by reference. I'm aware... JvdS> There are two options: JvdS> 1: Change the behavior of const-parameters. That can lead to JvdS> unpredictable problems which are not noticed by the compiler. It could JvdS> be an option to use some setting to define the behavior of 'const', but JvdS> in that case that setting have to be set for all units that do a call to JvdS> QueryInterface. (ie: all code using interfaces, so it means this setting JvdS> has to be set everywhere where COM code is used) Currently Win32 (only win32) could work with const in that interface, taking in account that any other interface functions in IUnknown descendents will be mostly typed with const instead constref, so people with interfaces will inadvertly have const everywhere but QueryInterface. Anyway, continue reading... JvdS> 2: Change the definition to constref, so the compiler will complain if a JvdS> user override the QueryInterface's definition, and can adapt the code. This is the best, of course, but is there any possibility to fine tune the message error in that case to offer the solution to the programmer directly ? Can a special error message be emited for this error in QueryInterface ? JvdS> Notice that until now I've only heard of code which overrides JvdS> QueryInterface in the Free Pascal code itself, in the Lazarus code, ZEOS JvdS> and the code from one commercial developer who also works on JvdS> Lazarus/Free Pascal. JvdS> It is an incompatibility, yes. But I think it's not too intrusive and I JvdS> see no alternatives... No, not intrusive, but very hard to find the solution for average joe, in fact I had solved it in my Zeos just after seen the "error" but most people are not aware of the change. I'm looking for a help in solution, not an interface change. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 9:45:47 AM, you wrote: L> 2. Is it wrong in implementation of TSQLConnectors, which write data L> into record buffer (of TStringField) and do not convert them always into L> UTF-8 ? Do you set the CHARSET field in your TSQLConnector to UTF-8 ? Do you define the right code page in each field of your database ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 11:02:00 AM, you wrote: >> L> 2. Is it wrong in implementation of TSQLConnectors, which write data >> L> into record buffer (of TStringField) and do not convert them always into >> L> UTF-8 ? >> Do you set the CHARSET field in your TSQLConnector to UTF-8 ? L> not all connectors supports CharSet property. When I look into sources L> only MySQL and IB support them (SQLite always return UTF-8 encoded ... L> ODBC, Postgre and Oracle ignore it) So partially it is a lack of support in TSQLConnector. Also UTF-8 in Firebird does not work as expected due a design decision (I think). L> Yes, this is not primary question of database side, Oh yes it is! If you miss any of the three steps, it will fail: 1) Database field 2) SQLConnector and Client DLL/so 3) GUI L> but db client library api, which is used by SQLConnector to L> retrieve data. How an UTF8 SQLConnector can retrieve UTF8 data from a field defined as binary ? Client libraries have all the needed resources to handle the database, a different thing is that SQLConnector implements them and/or do it right. L> For example in ODBC we use SQLGetData in LoadField L> method to retrieve data from odbc interface. And for example in L> case of MS SQL Server character data are retrieved in current ANSI L> code page (in Windows of course, may be that for example in *nix L> data are retrieved in UTF-8 naturaly) . Via ODBC ? L> (AFAIK there is no universal way how to explicitly request L> character encoding from ODBC interface) But that's a problem of ODBC, but: http://web.datadirect.com/resources/odbc/unicode/unix.html L> So it is true, that every sql connector is mandatory write character L> data in UTF-8 ? No. It is mandatory that you send/receive UTF8 to/from GUI LCL elements. In case you are using a DBF, in example which does not have encoding information, you can use the transliterate facility of dataset, but it is a bit awful. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] String and UnicodeString and UTF8Stringt
Hello FPC, Wednesday, January 12, 2011, 2:59:53 PM, you wrote: >> L> but db client library api, which is used by SQLConnector to >> L> retrieve data. >> How an UTF8 SQLConnector can retrieve UTF8 data from a field defined >> as binary ? L> It cann't . L> Here I am speaking about TStringField, which is IMHO designed for L> character data, for binary data is designed TBinaryField And a binary field is an string without encoding, collate and other text explicit attributes. >> But that's a problem of ODBC, but: >> http://web.datadirect.com/resources/odbc/unicode/unix.html L> Yes in UNIX world it may be so (I do not know), L> but in Windows ODBC we have no such possibility AFAIK Quote from Microsoft: "The ODBC 3.5 (or higher) Driver Manager supports both ANSI and Unicode versions of all functions that accept pointers to character strings or SQLPOINTER in their arguments. The Unicode functions are implemented as functions (with a suffix of W), not as macros. The ANSI functions (which can be called with or without a suffix of A) are identical to the current ODBC API functions." ODBC 3.5 was launched around 2000-2001. L> So it can be UTF-8, UTF-16 or UTF-32 ... in all cases we must allocate L> space 4*[max.number of characters in field], right ? L> So in what encoding are string data stored now in TStringField ? In the same format the database bring them to it. Database returns a bunch of bytes and a description of that bytes. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] TStringField, String and UnicodeString and UTF8String
Hello FPC, Thursday, January 13, 2011, 10:03:02 AM, you wrote: >> ODBC 3.5 was launched around 2000-2001. L> But this approach will require changes in packages/odbc/src/odbcsql.inc L> like, does not ?: L> -pointer(SQLGetData) := L> GetProcedureAddress(ODBCLibraryHandle,'SQLGetData'); L> +pointer(SQLGetData) := L> GetProcedureAddress(ODBCLibraryHandle,'SQLGetDataW'); L> And I do not know how it affect compatibility for example in UNIX or if L> all ODBC drivers support this functionality. Most probably it needs a "flag" to indicate that the ODBC must work in Unicode, and then dynamic link to *W functions if this flag is set. I think ODBC drivers since 2002+/- should have this set of APIs, but I had never used ODBC in my life... :) L> But also in this case we will get UTF-16 widestrings (in Windows) not L> UTF-8, does not ? That's not important, you get unicode in the specified by the API format, then SQLConnector fills information in the expected target format (WideString, UTF8String over AnsiString, Raw bytes...). -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] TStringField, String and UnicodeString and UTF8String
Hello FPC, Thursday, January 13, 2011, 1:01:57 PM, you wrote: L> Also it seems to me, that when you call ANSI version of ODBC API L> functions, then you receive data in ANSI encoding. L> If it is so, then it is always safe use ansitoutf8() (or UTF8Encode()) L> on receved data. No, because ANSI is not UTF-* so any char outside of your ANSI codepage will be discarded or generate and exception, or whatever the developer decides (driver developer). L> In Windows we get UTF-16, in Linux/UNIX we get UTF-8 If you use ANSI calls in linux you will receive UTF8 because in most linux the ANSI page is UTF8. If you call the *W APIs you MUST receive WideString or PWideCharArray or alike, or the API will not work. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] TStringField, String and UnicodeString and UTF8String
Hello FPC,
Thursday, January 13, 2011, 2:58:30 PM, you wrote:
JvdS> Then that option has to be added. I think it's already possible but you
JvdS> simply don't know how. (Sql-Server is ODBC only, so that one is fixed.
JvdS> For firebird there's a 'serverencoding' parameter, or something like
JvdS> that. Postgres also has some setting.
Are you aware about the Firebird Field(UTF8) and SQLConnection
CharSet(UTF8) problem ?
Table X
---
FieldTestName Varchar(5) UTF8
IBConnection
---
CharSet = UTF8
//Source code file is UTF8 encoded.
DataSource.FieldByName('FieldTestName').AsString='Ñ';
This raises an exception because the string is 10 bytes and the field
only allow 5 chars.
I think I had read this comment many months ago and answered as "won'n
fix" for Interbase compatibility. Am I wrong ?
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[4]: [fpc-devel] TStringField, String and UnicodeString and UTF8String
Hello FPC, Thursday, January 13, 2011, 4:24:31 PM, you wrote: >> Are you aware about the Firebird Field(UTF8) and SQLConnection >> CharSet(UTF8) problem ? JvdS> See my mail to Lacak about the two options to solve this. I think the problem is different and can be solved without any compatibility problem or at least easily detectable. Anyway I'll write a possible patch and this way test if that's a viable solution and if it "works" send for evaluation. Thank you. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] FPC for minimal Win-32
Hello FPC, Thursday, March 24, 2011, 9:10:10 PM, you wrote: SB> You don't need to rebuild FPC itself, but you need to modify the RTL. SB> Three functions from oleaut32 are included for Windows compatible SB> widestring management. As FPC has a fallback mechanism you can disable that. Or simply create a dummy "oleaut32.dll" which exports the same functions prototypes without doing nothing (empty functions) and drop that DLL in the same folder as the exe. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] FPC for minimal Win-32
Hello FPC, Thursday, March 24, 2011, 10:19:09 PM, you wrote: >> Or simply create a dummy "oleaut32.dll" which exports the same >> functions prototypes without doing nothing (empty functions) and drop >> that DLL in the same folder as the exe. SB> But then you must not use FPC for that DLL as the oleaut32 functions are SB> used in DLLs as well. Instead modify RTL to not import that functions, provide a simple empty stub in a "local" DLL to keep the dll loader happy and disable unicode. Maybe I'm dropping something in the path and this approach is not good. SB> Also if you follow this approach it might be safer to stay far away from SB> any function that takes a WideString (UnicodeString might work though). The worst thing could be a "no answer" function, or implement a very basic non complian unicode operations (I had not checked what oleaut32.dll functions perform). -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CompareMem slower in FPC 2.4.4
Hello FPC, Wednesday, June 1, 2011, 10:07:18 PM, you wrote: MK> In my tests, FPC 2.4.4 has much slower CompareMem than FPC 2.4.2, at MK> least for some cases: The difference is that CompareMem takes the same time to check a memory block if the elements are equal or different, while the pascal code aborts inmediatly after first difference. I had performed a fast test filling 2 megabytes of memory, the first with value "1" and the second with value "2". Performing the test 10 millions times takes 610 milliseconds. In the second test fill both arrays with same value, and CompareMem takes 610 milliseconds. After some tests (not very professional) CompareMem takes much more advantage if the amount of bytes to be compared are more than 32-38, so the best performance I get is using this function: function XCompareByte(const p1,p2,Length: sizeInt): SizeInt; var j: SizeInt; PB1: PBYTE absolute p1; PB2: PBYTE absolute p2; begin if Length<=38 then begin for j := 0 to Length-1 do begin if pb1[j]<>PB2[j] then begin Result:=BYTE(PB1[j]-PB2[j]); exit; end; end; Result:=0; end else begin Result:=CompareByte(p1,p2,Length); end; end; In my computer Intel 9300 QCore WindowsXP this function get the best of the two worlds, fast comparison escape for different memory blocks, fast compare for small blocks and the "rep cmpsl" for larger blocks, performance that can not be achieved with the pascal loop. The comparison penalty if rapidly payed with the fast escape in case of differeces in the very first bytes. I'm quite sure the magic number is 32 not 38, but in my case I get better performance with 38. Simple test code: procedure Comparememtest; const COMPARELENGTH=1000; var p1,p2: PBYTE; j: integer; ST,ET: TTimeStamp; begin GetMem(p1,100); for j := 0 to 100-1 do begin p1[j]:=0; end; GetMem(p2,100); for j := 0 to 100-1 do begin p2[j]:=0; end; ST:=DateTimeToTimeStamp(Now); for j := 0 to 1000 do begin XCompareByte(SizeInt(p1),SizeInt(p2),COMPARELENGTH); end; ET:=DateTimeToTimeStamp(Now); self.Caption:=inttostr(ET.Time-ST.Time); FreeMem(p1); FreeMem(p2); end; Times table: PlainCompare CompareByteXCompareByte --- Equal arrays 1000 elements 16250 ms 625 ms 656 ms Diff. arrays 1000 elements 62 ms 640 ms 656 ms Equal arrays 32 elements 547 ms 625 ms 547 ms Diff. arrays 32 elements62 ms 640 ms 62 ms -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CompareMem slower in FPC 2.4.4
Hello FPC, Wednesday, June 1, 2011, 10:07:18 PM, you wrote: MK> In my tests, FPC 2.4.4 has much slower CompareMem than FPC 2.4.2, at MK> least for some cases: Please take care with my last email, it has a bug that result in wrong speed tests, anyway after fixing the bug, the "magic" number for plain compare is around 28-32, so for blocks of 28-32 or less bytes, a plain compare is much faster than CompareMem even when the memory blocks are identical. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] CompareMem slower in FPC 2.4.4
Hello FPC, Thursday, June 2, 2011, 7:03:10 PM, you wrote: FK> Am 02.06.2011 18:45, schrieb José Mejuto: >> Hello FPC, >> >> PlainCompare CompareByteXCompareByte >> --- >> Equal arrays 1000 elements 16250 ms 625 ms 656 ms >> Diff. arrays 1000 elements 62 ms 640 ms 656 ms >> >> Equal arrays 32 elements 547 ms 625 ms 547 ms >> Diff. arrays 32 elements62 ms 640 ms 62 ms >> FK> I improved the original CompareByte, please tell me how it works for you. Much better now when arrays are identical it scales well... Identical arrays Comparemem 4 : 203 XCompareMem 4: 109 CompareMemNew 4 : 94 Comparemem 32: 453 XCompareMem 32 : 547 CompareMemNew 32 : 438 Comparemem 200 : 1125 XCompareMem 200 : 1156 CompareMemNew 200: 1125 Different arrays at first position -- Comparemem 4 : 293 XCompareMem 4: 51 CompareMemNew 4 : 59 Comparemem 32: 596 XCompareMem 32 : 51 CompareMemNew 32 : 59 Comparemem 200 : 593 XCompareMem 200 : 625 CompareMemNew 200: 609 -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] CompareMem slower in FPC 2.4.4
Hello FPC, Thursday, June 2, 2011, 7:03:10 PM, you wrote: >> PlainCompare CompareByteXCompareByte >> --- >> Equal arrays 1000 elements 16250 ms 625 ms 656 ms >> Diff. arrays 1000 elements 62 ms 640 ms 656 ms >> >> Equal arrays 32 elements 547 ms 625 ms 547 ms >> Diff. arrays 32 elements62 ms 640 ms 62 ms >> FK> I improved the original CompareByte, please tell me how it works for you. After a brief test, the same happends with FillByte for blocks of 24 bytes or less, probably 32 when coded in ASM. FillByte FillByte 4 : 371 XFillByte 4 : 68 FillByte 16 : 235 XFillByte 16 : 172 FillByte 24 : 235 XFillByte 24 : 228 FillByte 32 : 235 XFillByte 32 : 292 -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Record assign improve
Hello FPC, Based in the optimizations to CompareByte and FillChar, I get a suspect about record assignment when records are not very big, so write some test code to verify it, and yes, I think code generator should be changed in some way to get advantage in case of "small" records < 96 bytes. This are the test times: Rounds: 10 Array fast (96) : 2110 Rounds: 10 Array slow (96) : 2265 Rounds: 10 Array fast (64) : 1391 Rounds: 10 Array slow (64) : 1969 Rounds: 10 Array fast (32) : 640 Rounds: 10 Array slow (32) : 1641 Rounds: 10 Array fast (16) : 328 Rounds: 10 Array slow (16) : 1641 The code basically have a record with a series of integer fields and try to copy the record several million times. When the record is 8 bytes long, it generates fast code, but when record size is 16 the code generator jumps to use the "rep movsl" which seems to be ineficient for such small records. 16 and 32 bytes records takes almost the same time to be copied, while the the "by members" copy is between 3 and 5 times faster. Fast and slow "16" records: TRFast=record r1: record a: integer; b: integer; end; r2: record c: integer; d: integer; end; end; TRSlow=record a: integer; b: integer; c: integer; d: integer; end; Loop test code: for k := 1 to TESTELEMENTS-1 do begin ArFast[0].r1:=ArFast[k].r1; ArFast[0].r2:=ArFast[k].r2; end; for k := 1 to TESTELEMENTS-1 do begin ArSlow[0]:=ArSlow[k]; end; Complete test functions are attached. Thinking in the amount of 32 byte records that can be found in a program this optimization can take a good speed advantage. -- Best regards, José arraytest.pas Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Record assign improve
Hello FPC, I forget to say that my machine test is a Intel Q9300 4Core, running WinXP SP3 32 bits. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: wrong detection of inUnix ?? [Re: [fpc-devel] fcl-WEB build broken]
Hello FPC, Saturday, June 11, 2011, 10:48:31 AM, you wrote: MvdV> In our previous episode, Michael Van Canneyt said: >> > The windows shell also accepts / as pathseparator. >> >> Not here it doesn't. Just tested: >> >> C:\Documents and Settings\Administrator>cd c:/programs >> C:\Documents and Settings\Administrator >> >> C:\Documents and Settings\Administrator>cd c:\programs >> >> C:\Programs> MvdV> After retest it seems only to ignore it indeed. Try going to the root and MvdV> then do '/' is used as path separator, but not as path root indicator, so '/' can only be used with relative paths: cd \/Programs (go to root, then programs) cd /p1/p2/p3 (enter in p1, then p2, then p3) cd /../../.. (up 3 directories) -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] volatile variables
Hello FPC, Tuesday, June 28, 2011, 3:39:29 PM, you wrote: AB> Sort of right. 6 core system. Core 1 locks code block. Code block AB> should still use interlocked statements to make memory assignments so AB> that when Core 1 releases lock - Core 2 can have a real-time image of AB> variable. Otherwise Core 2 may see a stale copy of the variable. Core 2 should only access those variables using the same lock (critical section) as core 1 or data integrity is not garanteed. Critical sections garantee a full fence, pipe lines as invalidated. The only possible problem is the variable caching in a register, but as stated here the call to the function that perform the critical section forces fpc to store the variables in a register to its memory address and the critical section activity forces the fence ensuring all cores see the same data at the same time. You can not protect a code with a critical section and access the data without using the same critical section, so you can not protect code with a critical section and operate over the data in other thread with interlock operations. This is not threading 101, do not ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safely shareable objects
Hello FPC, Thursday, June 30, 2011, 4:07:22 PM, you wrote: HPD> Now we can assume that IShareable objects/references can be used all HPD> over the code, with no further precautions in explicit code required, HPD> that the use of the object *and* its content is always synchronized and HPD> sequentialized properly. Specific interfaces can be derived from HPD> IShareable, e.g. IShareableList, HPD> IShareableParamsAndResult. So you mean that something like: IMyObject inherited from IShareable the compiler must add stub code on each function/procedure/property to lock the interface ? So a function like: function iMyObject.Increment(a: integer): integer; begin a:=a+1; end; must be "silently modified" by the compiler to something like: function iMyObject.Increment(a: integer): integer; begin IObjectCritical.Enter; try a:=a+1; finally IObjectCritical.Leave; end; end; ? To me it looks extremelly overkill. If you think in the other approach, so when interface count is higher than one enter the critical section, it could not be done IMHO because when refcount reach 2 it could happend in thread 2 while thread 1 is inside a procedure of the object which could lead to unexpected results. Maybe I missed something ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Safely shareable objects
Hello FPC, Thursday, June 30, 2011, 9:42:36 PM, you wrote: HPD> José Mejuto schrieb: >> So you mean that something like: >> >> IMyObject inherited from IShareable the compiler must add stub code on >> each function/procedure/property to lock the interface ? HPD> No. The object is locked as long the code holds the reference to it. In that case read my note at the end of the e-mail, I think it could not be done in that way. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] SMP > 2 core Cache issue with Posix threads
Hello FPC,
Friday, July 1, 2011, 6:44:44 PM, you wrote:
HPD> This scenario was reflected in my example (bi-linked list update).
HPD> The very last sentence deserves clarification. When not *all*
HPD> assignments are protected by a CS, the use of Interlocked assignments
HPD> only can improve cache coherence, but it IMO *can not* prevent (logical)
HPD> race conditions. IMO Andrew observed just such race conditions,
HPD> resulting from a mix of sequential writes from multiple threads.
When not all assignements/reads are not protected by a CS (or similar)
there is not a problem of coherence, there is a logical problem. In
that case the use of interlocked operations only add overhead without
adding any kind of security/stability.
You can write lock free algorithms with interlocked operations, but
you can not write any other kind of procedures, usually more complex,
without a CS.
Tiny example:
Core/Thread 1:
while true do begin
Critical.Enter;
a:=b;
b:=b+1;
if a=b then Raise Exception.Create('KBOOM!');
Critical.Leave;
end;
Core/Thread 2:
---
while true do begin
InterlockedDecrement(b);
end;
This code will crash at a given time, maybe 1 millisecond, maybe 2
days, but it will crash.
Cache coherence is maintained by the hardware, interlocked only
provide atomicity. How the atomicity is provided is beyond the scope
of pascal and even the OS.
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Const optimization is a serious bug
Hello FPC, Tuesday, July 5, 2011, 6:44:24 PM, you wrote: JM> Since the behaviour of "const" for automated types is JM> explicitly defined by Borland as not causing any changes in JM> reference counting (see the note at the bottom of JM> http://docwiki.embarcadero.com/RADStudio/en/Using_Reference_Counting JM> ), I think Martin/Florian's proposal to add the ability for adding JM> extra compiler checks is best. It's similar to how range and JM> overflow checking are optional. But adding a checksum over allocated data or only over control data ? This changes should be detected ? var a: ansistring; procedure DoSomehting(const v: ansistring); begin a[1]:='a'; end; begin a:='b'; DoSomething(a); end. Maybe "simply" add a constRefCount field which is only used with the check automagic types turned on ? Anyway the worst behaviour is refcount related do not ? If refcount should be updated and the variable have a constRefCount>0 then something went wrong. Also this mode should not impose a serious performance penalty. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] negative TDateTime values and MinDateTime
Hello FPC, Thursday, August 4, 2011, 10:11:16 AM, you wrote: GG> On 4 August 2011 09:58, Felipe Monteiro de Carvalho wrote: >> >> I've never heard that our DateTime routines support other calendars. >> My guess is that they simply don't. GG> Even so, does that mean we can't write software with FPC for use by GG> Historian's where they might catalog artifacts with a date less that GG> Year 100? I haven't tested, but if so, that's terrible. You need to use a dates library, usual simple date libraries like the fpc/delphi rtl are plain wrong for gregorian calendar prior 1582, so dates before (like the 100) mindate limit is meaningless. Just the october 5 1582 does not exists. Even in gregorian calendar if you live in Turkey the mindate value should be 1/1/1926. Dates and unicode suffers the same localization problems. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Problem with Now() and time changed by ntpd
Hello zeljko, Monday, October 31, 2011, 8:58:14 PM, you wrote: z> Don't know what to do ... I must fix this asap somehow ... even with using my z> own Now() implementation by calling libc ... don't know ... this pissed me off z> totally. Is the UTC time reliable (the value that you can get) ? If it is just calculate your local time from UTC instead using Now(). -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Problem with Now() and time changed by ntpd
Hello zeljko, Tuesday, November 1, 2011, 2:07:50 PM, you wrote: >> 1. First off, we must correctly take into account DST. That should fix >> Zejlko's problem. z> Am I the only one who produces 24/7 services with fpc in the world (and z> around) ? ;) For sure no :) I found that problem 2 years ago, but not exactly related to real time, but to stored local times that must be processed across time zones, so I wrote PascalTZ http://wiki.lazarus.freepascal.org/PascalTZ -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Cant' compile trunk
Hello FPC, Tuesday, December 27, 2011, 5:21:24 PM, you wrote: >> I was trying to fix the makefile but me and makefiles are not good >> friends :) mvwb> Should be fixed in rev. 19895. mvwb> As a workaround, compile *and install* the latest version of the packages. Thank you... workaround noted to another case. 19895 compiles fine. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Cant' compile trunk
Hello FPC, I can't compile trunk: [...] make[1]: Entering directory `F:/fpc/svn/utils/importtl' F:/fpc/fpc/2.4.4/bin/i386-win32/ppc386.exe -Fu../../rtl/units/i386-win32 -FE. -FUunits/i386-win32 -di386 importtl.pas Free Pascal Compiler version 2.4.4 [2011/12/16] for i386 Copyright (c) 1993-2010 by Florian Klaempfl Target OS: Win32 for i386 Compiling importtl.pas Fatal: Can't find unit typelib used by importtl Fatal: Compilation aborted make[1]: *** [importtl.exe] Error 1 make[1]: Leaving directory `F:/fpc/svn/utils/importtl' make: *** [importtl_all] Error 2 I was trying to fix the makefile but me and makefiles are not good friends :) -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Misterious error
Hello FPC, I'm now running: Lazarus 0.9.31 r34428 FPC 2.7.1 i386-win32-win32/win64 r19895 With this setup something strange is happening in a project of mine, when I close the project a SIGSEGV happends in the win32callback.inc of LCL without callback stack trace and with all local variables using a base pointer of nil (gdb messages like 'window unable to read address 0x8'). This seems to have nothing in relation with fpc itself, but as soon as I do any string operation inside the procedure everything starts to work as it should. In my first test I wrote a simple "writeln(integer(@window))" before the line that crashes everything, but before the crash, the value of @window is normal. Then I try to write 2 values so use "writeln(strtoint(window)+' '+strtoint(msg))' and suddenly everything starts to work. I know that such operation can change the code generation and hide an error, so I simple declare a "var" section like: var s: string; begin and remove the writeln so the only change to the code is the variable declaration and now it works. Does anybody have an idea how can I debug this problem ? Assembler code looks the same in both cases. To me it looks like the code is trying to free some strings or interfaces but at a point where the manager of automated types has been "disabled" so the declaration of a new ansistring "reconnects" it. Maybe it is a crazy idea but is the only one that I have now. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello Jonas, Wednesday, December 28, 2011, 2:43:16 PM, you wrote: >> To me it looks like the code is trying to free some strings or >> interfaces but at a point where the manager of automated types has >> been "disabled" so the declaration of a new ansistring "reconnects" >> it. Maybe it is a crazy idea but is the only one that I have now. JM> The most likely problem is memory corruption by your program. JM> Compiling the program with range checking (-Cr) and dynamic class JM> type checking (-CR) can help with finding the cause. You can try JM> using heaptrc or Dr Memory (http://dynamorio.org/drmemory.html -- JM> in case you use this one, adding the cmem unit to your program may JM> give more accurate diagnostics). I had done all the tests and in fact many more, and start to manually bisect fpc to find the revision that breaks my code as 2.4.2, 2.4.4 and 2.6.0rc1 work fine. After 2 days and around 40 fpc and LCL clean compiles :) I had found that the revision 19668 breaks the code. I was unable to synthesize a test case that shows the problem, so only my code is raising the problem constantly after that revision. When exception is raised ebp is equal to zero and as r19668 is related to exceptions handling it makes me think again in wrongly handled automated types in some situations, in my case I suspect in interfaces. To compile 19667 and 19668 I had to manually apply revisions 19699 and 19670 which only affects fpdoc compilation. How can I help more to catch the problem ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello Jonas, Wednesday, December 28, 2011, 2:43:16 PM, you wrote: JM> The most likely problem is memory corruption by your program. [...] JM> give more accurate diagnostics). A bit more information: Environment is win32. The line that raises the exception is in win32callback.inc 2474: --- if (Msg=WM_CHAR) and (WParam=VK_RETURN) and ((lWinControl is TCustomCombobox) or ((lWinControl is TCustomEdit) and not (lWinControl is TCustomMemo )) ) then // this thing will beep, don't call defaultWindowProc else PLMsg^.Result := CallDefaultWindowProc(Window, Msg, WParam, LParam); --- The CallDefaultWindowProc. If I change the line to: try PLMsg^.Result := CallDefaultWindowProc(Window, Msg, WParam, LParam); finally end; The problem dissapears. * In the same function, if I declare an ansistring type, just the declare only, it works. * If the "CallDefaultWindowProc" declaration is changed to stdcall it also works fine. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC,
Saturday, December 31, 2011, 3:39:59 PM, you wrote:
SG> r19668 affects codegeneration of constructors and custom enumerators, and
fixes
SG> http://bugs.freepascal.org/view.php?id=20827
SG> The reported location of crash in your case is likely
SG> unrelated to the actual location of problem.
SG> At least, function WindowProc from win32callback.inc is not
SG> affected by r19668, as it isn't a
SG> constructor and doesn't involve exception handling in unmodified form.
SG> If your code contains constructors which use interfaces, I'd
SG> suggest them as the place to look at or
SG> try to modify.
Reverting this change in r19668, line 700:
begin
{ Constructors need the destroy-on-exception code even if they don't
use managed variables/temps. }
//if (cs_implicit_exceptions in current_settings.moduleswitches) and
// (is_class(procdef.struct) and
(procdef.proctypeoption=potype_constructor)) then
// maybe_add_constructor_wrapper(code,true)
//else
maybe_add_constructor_wrapper(code,false);
addstatement(newstatement,loadpara_asmnode);
Makes everything work fine again. The if..else was added by you in
19668. Maybe a forgotten situation to generate stackframe ?
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Saturday, December 31, 2011, 5:07:42 PM, you wrote: >> //if (cs_implicit_exceptions in >> current_settings.moduleswitches) and >> // (is_class(procdef.struct) and >> (procdef.proctypeoption=potype_constructor)) then >> // maybe_add_constructor_wrapper(code,true) >> //else >>maybe_add_constructor_wrapper(code,false); >> Makes everything work fine again. The if..else was added by you in >> 19668. Maybe a forgotten situation to generate stackframe ? >> SG> Plain removal of this if..else breaks a couple of tests in SG> the testsuite. But the information you SG> provided gives some pointers to look at. At least, adding a SG> check that constructor without SG> pi_needs_implicit_finally flag doesn't have any implicit SG> finalization code either will help SG> detecting the actual place of trouble. SG> I'll review it. I'll be very happy in test any change you may want to try before commit to SVN. This kind of problems seems to be very difficult to catch, so I'll try to not change my codebase while you investigate in order to be able to raise the error as needed. Another hint, my problem appears at close time and only if a debugger is present. If no debugger the operative system eats the error and nothing is reported. Happy 2012. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Monday, January 2, 2012, 9:27:50 PM, you wrote: >> The solution to optimize the unnecessary finally blocks without >> breaking exit behavior is still to >> be found. SG> More sophisticated patch applied in r19955. If you can test SG> your project with it, that would be just SG> great. I had updated to 19958 and it still fails with the same SIGSEGV. Again adding the try..finally..end in the function cures the problem. [Updating to 19959 to test as my code uses Variants...Done] No sorry, still the same SIGSEGV :( Do you know which kind of code I must look for to isolate the problem ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Tuesday, January 3, 2012, 10:01:54 PM, you wrote: >> Do you know which kind of code I must look for to isolate the problem >> ? SG> I'd suggest looking at the constructors containing an 'exit' statement, SG> but I'm not entirely sure. SG> Does restoring removed line 287 of psub.pas remove the segfault? SG> (The line was: SG>include(current_procinfo.flags,pi_needs_implicit_finally); ) No, it does not :( The problem seems to happend in a destroy process, but as it only happends on close window, and in the close process a lot of objects and interfaces are destroyed I can not track each one :( I'll try to create a minimun project that fails, it would need a firebird and zeoslib. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Misterious error
Hello FPC, Wednesday, January 4, 2012, 3:12:55 PM, you wrote: SG> I was hoping otherwise... Actually it is very strange that SG> reverting changes at line 700 (which you SG> mentioned earlier) removes the crash, while reverting line SG> 287 does not, because removing SG> pi_needs_implicit_finally flag is the condition under which SG> code at line 700 could ever execute. I'll retest everything again with clear compiles to be sure... SG> This is of course the best thing to do. SG> However, you can as well try the attached simple patch. It SG> prevents temps referenced from 'finally' SG> blocks from being placed to registers. If it still crashes I'll apply the patch and retest again. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Manual reload of a DLL snapshot (with relocations) causes multiple AV
Hello FPC, Friday, January 6, 2012, 3:07:31 PM, you wrote: GP> The task I'm working on is somewhat unorthodox, but I'd like to get some comments anyway. [...] GP> I'm writing "semi-stealth" DLL which is one loaded by the GP> process (and visible by others) while not residing on disk as a GP> file. This is done by the following method: Why you do not load the DLL from memory ? There is code to load and relocate it as it is being done by the Windows OS. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] New functions for time zone
Hello FPC, Wednesday, July 11, 2012, 3:09:41 PM, you wrote: MVC> There are 2 sides to this medal. The function returns a number of timezones; MVC> This is usually expressed as a number of hours and minutes (the OS returns MVC> it so). The result is in 'natural' units. MVC> Returning it as a timestamp - while useful by itself - seems rather odd. Returning it as a timestamp is nonsense, instead return a double representing the day fraction, so 2 hours = 2 / 86400. MVC> I'm also not quite sure what should be returned for MVC> negative values of the timezone info. MVC> 'today 23:00' or "Yesterday 23:00" MVC> I think it should remain as it is, but if you want, we can create an extra MVC> function 'LocalTimeOffset' in DateUtils that returns the same thing as a MVC> TDateTime. This new function can then be used in conversion routines. Anyway the functions are nonsense as they accept a parameter for date to be converted, and as noted in the bug report the functions must only work over Now or NowUTC (or alike). IMHO is quite dangerous to keep this functions as they are now in the base units, as the names suggest that they will correctly convert any time UTC to a local time or viceversa, so at least rename the function "GetLocalTimeOffset" to "GetCurrentLocalTimeOffset" to note the "current" verb. In the other hand this functions are not for local<->universal time conversions, they displace times, calculate offsets and apply them, in fact one function changing the sign of the offset will give the same result as the other function. As usual, this is just my opinion only... -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[3]: [fpc-devel] New functions for time zone
Hello FPC, Wednesday, July 11, 2012, 4:38:19 PM, you wrote: >> Anyway the functions are nonsense as they accept a parameter for date >> to be converted. MVC> Not if they have the TZOffset parameter as well. MVC> Without this information they are indeed nonsense. MVC> That is why I added the parameter. Well, I undertand it, I was only trying to note that this code: A:=Now; B:=GetLocalTimeOffSet; C:=LocalTimeToUniversal(A,B); Will not return correct result in some mini-mili-microseconds slices two times a year, and as more time passes between the assignements of A and B (using a time field in databases, it could be days, years, months...) the chances of a wrong conversion will raise a lot. MVC> If someone does not supply it, the current one will be taken; MVC> it is simply meant for current time operations. MVC> The behaviour will be documented, and there will be a MVC> remark about the TZ info being time dependent. MVC> If someone doesn't know what he is doing, that's his problem. Sure :) I had bitten that stone in the past ;) -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[4]: [fpc-devel] New functions for time zone
Hello FPC, Wednesday, July 11, 2012, 5:41:45 PM, you wrote: >> A:=Now; >> B:=GetLocalTimeOffSet; >> C:=LocalTimeToUniversal(A,B); >> Will not return correct result in some mini-mili-microseconds slices >> two times a year, and as more time passes between the assignements of >> A and B (using a time field in databases, it could be days, years, >> months...) the chances of a wrong conversion will raise a lot. MVC> This is correct, but unavoidable without a huge MVC> implementation like TZPascal... That's completly overkill. MVC> Even 'Now' itself is not 100% correct, since lots of computations are still MVC> done after the time was gotten from the OS... I think thew word here is "precise", now is not 100% precise, but it is correct as it can describe a given moment in time, you know, the most precise clock is the stopped one, it returns a 100% accurate time 2 times each day :) -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] HPack for HTTP2
Hello, Added entry in the bug tracker for HPack implementation for http2. http://bugs.freepascal.org/view.php?id=30058 If somebody whats to add it somewhere in fpc/fcl code base. It is based in Twitter's HPack Java implementation. It includes fpcunit test file and sample files. There are still a bit of changes needed in the DynamicTable handling to gain a bit of speed, but corrently it seems to be valid for production code. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error
El 29/06/2016 a las 22:35, vfclists . escribió: Does this have to do with some questionable Microsoft formulae which prompted this query - http://stackoverflow.com/questions/2779948/subroutine-to-apply-daylight-bias-to-display-time-in-local-dst Hello, Only Now() can be converted to UTC using that formula, and only UTC Now can be converted back to your local zone time, any other time/date conversions could be wrong because you do not know how to convert from UTC to Accra (stackoverflow thread) unless your system is located in Accra, and as noted only "NOW()" values are valid. For inter-zone-across-history time conversions another routines and "databases" must be used. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of AutoEdit property of StringGrid
El 18/07/2016 a las 16:42, Чернов Дмитрий escribió: Thanks for answer, but I'm familiar enough with FPC/Lazarus, so I know about editors in grids. My question is about necessity of AutoEdit property in the presence of goAlwaysShowEditor option. Hello, The goAlwaysShowEditor shows the editor but I think in read only mode, you can not edit, or should not be able to. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TBufferedFileStream
Hello, Added to the bugtracker implementation of TBufferedFileStream, there is one compatibility issue note in the bug entry. http://bugs.freepascal.org/view.php?id=30549 -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBufferedFileStream
El 03/09/2016 a las 22:15, Michael Van Canneyt escribió: Added to the bugtracker implementation of TBufferedFileStream, there is one compatibility issue note in the bug entry. http://bugs.freepascal.org/view.php?id=30549 Nice. I have assigned this to myself. Out of curiosity: Why do you think this is needed ? Is the caching provided by most of the operating systems not enough ? Hello, 1) Delphi compatibility (It is available in Delphi). 2) TFileStream basically is a frontend for FileRead and FileWrite (Talking about Windows) and once you invoke one of those you enter in multithread contention, thread swapping, and maybe kernel mode (I'm not sure) so if you read or write small pieces of data from files the performance is very poor. Typical example is TFileStream.GetByte which I'm using in a parser, because the file could be very big, and I don't want to read everything in a TMemoryStream, performance of cache/buffered and regular is dramatically different: -- CACHE 100 byte sequential reads in 46 ms. FILE 100 byte sequential reads in 2200 ms. -- And this result is with the system cache hot (in fact the full file is in system cache). In the other hand a cache system is powerful than a buffered system if you are writing something like a filesystem over a TFileStream where you may need to jump here and there to read data, file allocation tables, attributes, and so on, in this case a cache with multiple pages instead just one improves the result (avoid multiple reads in the same zones). -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBufferedFileStream
El 04/09/2016 a las 0:23, silvioprog escribió:
--
CACHE 100 byte sequential reads in 46 ms.
FILE 100 byte sequential reads in 2200 ms.
--
[...]
Did you get this result from some sample? If so, could you share it?! I
would be glad to test it checking the TBufferedFileStream performance. :-)
Hello,
Yes, the code is in the test for TBufferedFileStream in the bug ticket
http://bugs.freepascal.org/view.php?id=30549
Delphi TBufferedFileStream should be faster as I think it implementes a
dumb buffer, or just better a read ahead buffer, so it works better for
sequential read and worst for butterfly reads on same zones.
For my works I just use my class TCacheStream which applies the same
cache code but over any stream already created. I need this as a stream
filter because I'm working on virtual file systems which access a stream
(whichever class) as a blocks device stream, so I can in example work
with ZIP files as they was a disk with functions to browse the ZIP
entries, create files, delete, read and write, once each "file" is
closed and the stream that holds the whole file is freed in destroy it
updates the zip according, compressing new and modified streams and
copying/moving the blocks not touched.
Part of this code is in the Excel reader/writer in fpspreadsheet package.
Most of this classes are mostly beta versions, operative in my
environment but not valid for wide use, that's the reason I had not
published them (and the lack of comments, and code convolution).
Currently I have, more or less:
Native filesystem: Read/Write. Maps the native filesystem to my virtual
filesystem.
ZIP filesystem: Read/Write. Up to 2GB zip files.
FAT16: Read. Typical dd images.
FAT32: Read. Typical dd images.
Microsoft Binary Compound: Read/Write with limitations. Used in XLS, DOC,...
Sample filesystem: Read/Write. Very limited sample filesystem.
MBR Partition: Read. Used to access dd images when partition information
is available.
RAR: Browse only. With special crafted dll for windows also decompress,
but it is a dirty hack.
ISO: Read only. Limited and based in GPL code.
The virtual file system allows to mount an filesystem (above) in a
folder for browsing, open, and so on, so in example you open a ZIP and
inside you find another zip, you can mount the inner stream in a folder
and access to inner files transparently to your code, with a path like
F:=VirtualLayerRoot.CreateStream("/zip1/zip2/myfile.txt",fmOpenRead);
I can publish the code but I can not provide any guarantee of correct
work and that it will not delete all your hard disk :)
--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBufferedFileStream
El 04/09/2016 a las 2:04, silvioprog escribió: If I understood right, did you create something like GIO or GVFS? Or neither of them hehe Hello, Yes and no :) It's something like GVFS but at your program level only. I originally develop it to be used in a forensic tool (which was not finally developed) to allow the same data scan engine to work in compressed files as they were real files so the file access logic is completly isolated from the information gather engine as this one works over a TVirtualFileSystem, how you implement your TVirtualFileSystem is up to your decision. You basically need to implement this functions: function intfOpenFile(const AFileName: UTF8String; const AMode: cardinal): TvlHandle; virtual; abstract; function intfCloseFile(const Handle: TvlHandle): Boolean; virtual; abstract; function intfFindList(const APath: UTF8String; const AMask: UTF8String): TVirtualLayer_FolderList; virtual; abstract; function intfSeek(const AHandle: TvlHandle; const APosition: int64; const Origin: word): int64; virtual; abstract; function intfRead(const Handle: TvlHandle; const Buffer: PBYTE; const Size: int64): int64; virtual; abstract; function intfWrite(const Handle: TvlHandle; const Buffer: PBYTE; const Size: int64): int64; virtual; abstract; function intfGetFileSize(const AHandle: TvlHandle): int64; virtual; abstract; function intfSetFileSize(const AHandle: TvlHandle; const ANewFileSize: int64): Boolean; virtual; abstract; function intfDeleteFile(const AFileName: UTF8String): boolean; virtual; abstract; function intfGetFreeSpace(const APath: UTF8String): int64; virtual; abstract; function intfIsWritableMedia(): Boolean; virtual; abstract; function intfMakeFolder(const AFolder: UTF8String): Boolean; virtual; abstract; function intfRemoveFolder(const AFolder: UTF8String): Boolean; virtual; abstract; function intfCopy(const ASourceFileName,ATargetFileName: UTF8String): Boolean; virtual; function intfMove(const ASourceFileName,ATargetFileName: UTF8String): Boolean; virtual; And you get a file system working. Of course it is a basic file system, without many functions and some restrictions like all the system works in case sensitive mode whichever the original one supports. Another question, does it work remotely too? As far as you can implement those functions yes, in fact I started (almost nothing) to write an http access using a remote zip file for read only and using the http byte ranges to access it. Maybe I should retake this work :) if there are some interest in the community. Attached is a sample (some folder names erased) of the explorer I use to test the different file systems in "real" situations. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBufferedFileStream
El 04/09/2016 a las 7:15, Michael Van Canneyt escribió: In the other hand a cache system is powerful than a buffered system if you are writing something like a filesystem over a TFileStream where you may need to jump here and there to read data, file allocation tables, attributes, and so on, in this case a cache with multiple pages instead just one improves the result (avoid multiple reads in the same zones). And why did you not use the bufstream unit of FPC ? The TBufStream stream implemented there works with any other stream, not just files. Hello, In fact I wrote my code over TStream but in Delphi the class is inherited from TFileStream so I take my "TStreamFilter" and adapt it to inherit from TFileStream just as Delphi do. The second powerful reason is that I was not aware about TBufStream :) TBufStream does support seek ? And SetSize ? My code like TBufStream inherits from TStream. Which is the advantage of inherit from TOwnerStream ? -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TBufferedFileStream
El 04/09/2016 a las 14:04, Michael Van Canneyt escribió: The second powerful reason is that I was not aware about TBufStream :) It's even documented. http://www.freepascal.org/docs-html/current/fcl/bufstream/index.html Hello, Sure :) But I'm not aware about all the gems in fpc code :) TBufStream does support seek ? And SetSize ? Seek: yes. Setsize not. I was asking looking at code: function TWriteBufStream.Seek(const Offset: Int64; Origin: TSeekOrigin): Int64; begin if (Offset=0) and (Origin=soCurrent) then Result := FTotalPos else BufferError(SErrInvalidSeek); end; Maybe I'm missing something ? On the SetSize side I think there is a missing check, SetSize can make the file smaller, so think in a 1 Kb file, you read the first byte so the buffer will be filled with the 1 Kb data, now you SetSize to 1 byte and read another byte, this read will return 1 byte success read which is out of the bounds of the file. I know this is a terrible border case and the solution could be just invalidate buffer when a SetSize is called. The TBufStream class has 2 descendents: one for reading, one for writing. This means the implementation is much more simple, and for most usecases, this is sufficient. That's more or less what I was using in other programs, with my own class (I should read more docs). My code like TBufStream inherits from TStream. Which is the advantage of inherit from TOwnerStream ? TOwnerStream is only useful if you have a second stream which you use as a source. It will free it for you. This is useful when chaining streams. Oh! I see, I'm using the typical Create(Stream,Owned=true) I will add your implementation to the bufstream unit. It offers more functionality, but works only on files. It's - as usual - a tradeoff. Not exactly, it is possible to add my original implementation TCacheStream which works over any TStream and create a TBufferedFileStream (for Delphi compat.) inheriting from it, but it will not have the same inheritance chain. What's the best for fpc ? A generic stream cache, a inheritance compatible TBufferedFileStream ? Or maybe both ? Or None ? :) -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Apply patch
Hello, Can anybody, please, apply the patch in http://bugs.freepascal.org/view.php?id=31255 ? It is very simple without side effects, except that it works now. Thank you. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
El 20/05/2017 a las 14:57, Jonas Maebe escribió: On 20/05/17 14:36, Martin Schreiber wrote: Is this intended? If not, which one is correct? random(x) is undefined for negative parameters. It should have had an unsigned parameter, like in Turbo Pascal (where it is word). Delphi defines it as always returning a positive value, but I don't know what happens if you pass a negative parameter there. Hello, At least in 3.0 (trunk not tested as I don't have it compiled) the first and second random numbers are always the same value, so: Randomize; A:=Random(n); B:=Random(n); A and B will be always the same value. Can someone with trunk test it ? -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Parameters must match exactly?
Hello Graeme, Monday, May 17, 2010, 11:56:29 AM, you wrote: GG> Yes, but I can't use OUT because the type of AForm doesn't match exactly - GG> back to my initial problem when I started with FPC 2.5.1. GG> TfpgWindowBase vs TBulkInvoiceRateListForm type. So you do not need "out" you need the non-exist "varout" which act as a var (non finalize) but do not emit the warning. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Purpose of "uses ... in"?
Hello Mattias, Wednesday, July 14, 2010, 7:05:01 PM, you wrote: >> And now, you understood the little problem? MG> Of course I understand the problem, but I have not yet encountered MG> it in a real project. I can vaguely remember a case like this in Delphi several years ago, but I think the problem was a precompiled .dcu which I can not rename. Is this possible ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sub byte arrays
Hello theo,
Tuesday, July 20, 2010, 12:03:28 PM, you wrote:
t> Now I was trying if something like this would work:
t> TTest=(one,two,three,four);
t> TTestarray = {bitpacked} array [1..10] of ttest;
t> PTestarray = ^TTestarray;
[...]
t> It seems, to work, but it even works with commented "bitpacked".
t> Shouldn't this fail? How can I test this? I have all checks on which
t> Lazarus IDE offers, but it's still happy.
>>From what I understand, this would need 400 bytes in this scenario (not
t> bitpacked), isn't it?
Had you tried SizeOf(TTestarray) ?
--
Best regards,
José
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safecall on Linux (and other unices?)
Hello Joost, Wednesday, July 21, 2010, 11:28:55 AM, you wrote: JvdS> I've finally managed to get xpcom/gecko to work (partly) on linux/i386. JvdS> The delphi/fpc gecko-headers uses the safecall calling convention a JvdS> lot. I get it to work too, but missing safecall (unix version) makes it unusable as a lot of assembler is needed. JvdS> On Windows a safecall is in principle a stdcall with a 'hidden' function JvdS> result which contains a value (nsresult) to check if there was any JvdS> problem during the call of the procedure/function. JvdS> I had to find out what calling convention is used by xpcom on Linux. And JvdS> in fact it's quite logical: it uses cdecl. (As most c-libraries do, use JvdS> stdcall on Windows, cdecl on others) It is not 100% cdecl, const records in safecall must be passed as reference while in cdecl a copy of the record is being passed. Please check my bug report: http://bugs.freepascal.org/view.php?id=16685 and some messages in mailing list: http://lists.freepascal.org/lists/fpc-pascal/2010-June/025605.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025609.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025613.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025615.html In the other side, I was unable to make Gecko work correctly (windows) using Gecko > 1.9.1.11 all 1.9.2.x versions raise a bunch of exceptions mostly related to Javascript :( I can run it removing some Javascript initialization scripts and disabling Javascript once loaded. Files needed to be removed: nsFormAutoComplete.js nsHelperAppDlg.js nsProgressDialog.js nsSearchService.js nsUpdateService.js -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Safecall on Linux (and other unices?)
Hello Joost, Wednesday, July 21, 2010, 12:46:32 PM, you wrote: >> I get it to work too, but missing safecall (unix version) makes it >> unusable as a lot of assembler is needed. JvdS> That's not true. I managed to get it to work without any assembler. JvdS> (Only used it to debug and some quick tests) JvdS> What you have to do is change definitions like: JvdS> function Bla(test: tsometype) : tresulttype; safecall; JvdS> to: JvdS> function Bla(testl: tsometype; _result: tresulttype) : nsresult; JvdS> extdecl; Well, changing interface yes, I avoid to change interface, so stack becomes unbalanced after any function call. JvdS> And define the extdecl macro to stdcall on Windows and cdecl on Linux. JvdS> Set the nsresult to the right error code to simulate an exception. I was trying to not touch interface and as my request about safecall in unix was "accepted" for a future discussion, I do not investigate further. Already spend a lot of time trying to figure why "safecall" works different in unix and in Windows... The silently replace calling convention confuses me :( >> It is not 100% cdecl, const records in safecall must be passed as >> reference while in cdecl a copy of the record is being passed. JvdS> I don't think so. The gecko-port-definitions are wrong in this regard. JvdS> They use 'const' but it should be 'var'. That this worked on Windows was JvdS> just a coincidence. I've replaced these 'const' parameter definitions to JvdS> 'var' and now they work on Linux and Windows. The headers just weren't JvdS> translated right in this regard. Even if declarations in the code are wrong (which I had not checked, I assumed they were fine) the "const" behavior with record in Windows safecall and linux cdecl is different. Also parameters not intented to be modified should not be var but const (IMHO). JvdS> That was a good starting point, to find out what the problem was JvdS> precisely. Jonas last comment was where I started. But enabling the JvdS> exception-handling wasn't enough. Using Safecall on Linut, the caller JvdS> has to clean up the stack (on windows the callee does). I don't know yet JvdS> how to the latter. JvdS> I don't think the parameter-passing should be changed. Just don't use JvdS> 'const'. I think if it is named safecall is must match windows safecall. Maybe better use "xpcom" or "unixsafecall" ? Parameter passing mode should match at all, callee or caller clean up is transparent to the people working with the library or other library, but how parameters are passed could bring a lot of confusion. JvdS> I don't know which version I used. Probably the one from the latest JvdS> Firefox release. I'll check at home. (tomorrow) I was using my modified version in the gecko port CCR, which fixes some bugs, maybe I had introduced new ones ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[4]: [fpc-devel] Safecall on Linux (and other unices?)
Hello Joost, Thursday, July 22, 2010, 5:57:27 PM, you wrote: >> Even if declarations in the code are wrong (which I had not checked, I >> assumed they were fine) the "const" behavior with record in Windows >> safecall and linux cdecl is different. JvdS> Offcourse the behaviour is different for a different calling convention JvdS> and OS. That's perfectly normal. If all calling conventions were the JvdS> same, we woudn't have them. Yes, but I think, maybe I'm wrong, that a cdecl declaration in any platform matches the same behavior in other platform. This means that: procedure (a: pointer); cdecl; is expected to produce the same effect (not internal implementation) in any platform. So: procedure (const a: record); safecall; in Unix will produce a copy of "a" and in Windows a reference to "a" which is not very portability friendly. Anyway I think the problem is on the XPCOM guys, as they decide to "define" safecall with different meanings in different platforms, so in Windows it is "stdcall safecall" and in Unix "cdecl safecall" (safecall referenced to the postprocessing of nsResult). To me it smells like everything was designed in Linux and later they decide to mimic the Windows Activex in the windows world. Anyway whichever you decide is OK to me. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[6]: [fpc-devel] Safecall on Linux (and other unices?)
Hello FPC, Thursday, July 22, 2010, 7:24:26 PM, you wrote: >> is expected to produce the same effect (not internal implementation) >> in any platform. JM> Well, no. It is expected to produce the same effect as the C JM> compilers on every platform. These may behave differently amongst JM> different platforms. So it is reasonable and "logical" that stdcall in platform A passes parameters from left to right and in platform B passes them right to left ? even called in both stdcall ? (stdcall in example). Maybe move this to fpc-pascal ? >> procedure (const a: record); safecall; >> in Unix will produce a copy of "a" and in Windows a reference to "a" JM> In Windows it currently only passes "a" by reference if the JM> size of the record is > sizeof(pointer). I was trying to simplify the idea without the details. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Safecall on Linux (and other unices?)
Hello FPC, Thursday, July 22, 2010, 9:35:55 PM, you wrote: >> To me it smells like everything was designed in Linux and later they >> decide to mimic the Windows Activex in the windows world. >> Anyway whichever you decide is OK to me. SB> I think you (and some others) got something wrong here. The wrong thing is that I was thinking that a calling convention was a strict set of rules to pass parameters and call functions, but it seems to be a set of rules per platform even using the same processor. If I were right, safecall must be stdcall+exception in both platforms, which it is not the case. I know safecall is a Borland idea, but it is documented as stdcall+exception, not as cdecl+exception. I do not know if you can catch my point of view. In the other hand I'm not against calling it safecall due the XPCOM compatibility (I had already requested it in the bug report). -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] HTML string to TFPColor
El 23/07/2017 a las 16:05, Bart escribió: https://www.w3.org/TR/css3-color/#colorunits Actually, adding more colornames is fine with me, itś just a tedious job ... Hello, If somebody needs it: type HTMLStandardColor=record ColorName: string; Red: BYTE; Green: BYTE; Blue: BYTE; end; const HTMLStandardColors: array [0..147] of HTMLStandardColor=( (ColorName:'AliceBlue';Red:$F0;Green:$F8;Blue:$FF), (ColorName:'AntiqueWhite';Red:$FA;Green:$EB;Blue:$D7), (ColorName:'Aqua';Red:$00;Green:$FF;Blue:$FF), (ColorName:'Aquamarine';Red:$7F;Green:$FF;Blue:$D4), (ColorName:'Azure';Red:$F0;Green:$FF;Blue:$FF), (ColorName:'Beige';Red:$F5;Green:$F5;Blue:$DC), (ColorName:'Bisque';Red:$FF;Green:$E4;Blue:$C4), (ColorName:'Black';Red:$00;Green:$00;Blue:$00), (ColorName:'BlanchedAlmond';Red:$FF;Green:$EB;Blue:$CD), (ColorName:'Blue';Red:$00;Green:$00;Blue:$FF), (ColorName:'BlueViolet';Red:$8A;Green:$2B;Blue:$E2), (ColorName:'Brown';Red:$A5;Green:$2A;Blue:$2A), (ColorName:'BurlyWood';Red:$DE;Green:$B8;Blue:$87), (ColorName:'CadetBlue';Red:$5F;Green:$9E;Blue:$A0), (ColorName:'Chartreuse';Red:$7F;Green:$FF;Blue:$00), (ColorName:'Chocolate';Red:$D2;Green:$69;Blue:$1E), (ColorName:'Coral';Red:$FF;Green:$7F;Blue:$50), (ColorName:'CornflowerBlue';Red:$64;Green:$95;Blue:$ED), (ColorName:'Cornsilk';Red:$FF;Green:$F8;Blue:$DC), (ColorName:'Crimson';Red:$DC;Green:$14;Blue:$3C), (ColorName:'Cyan';Red:$00;Green:$FF;Blue:$FF), (ColorName:'DarkBlue';Red:$00;Green:$00;Blue:$8B), (ColorName:'DarkCyan';Red:$00;Green:$8B;Blue:$8B), (ColorName:'DarkGoldenRod';Red:$B8;Green:$86;Blue:$0B), (ColorName:'DarkGray';Red:$A9;Green:$A9;Blue:$A9), (ColorName:'DarkGrey';Red:$A9;Green:$A9;Blue:$A9), (ColorName:'DarkGreen';Red:$00;Green:$64;Blue:$00), (ColorName:'DarkKhaki';Red:$BD;Green:$B7;Blue:$6B), (ColorName:'DarkMagenta';Red:$8B;Green:$00;Blue:$8B), (ColorName:'DarkOliveGreen';Red:$55;Green:$6B;Blue:$2F), (ColorName:'DarkOrange';Red:$FF;Green:$8C;Blue:$00), (ColorName:'DarkOrchid';Red:$99;Green:$32;Blue:$CC), (ColorName:'DarkRed';Red:$8B;Green:$00;Blue:$00), (ColorName:'DarkSalmon';Red:$E9;Green:$96;Blue:$7A), (ColorName:'DarkSeaGreen';Red:$8F;Green:$BC;Blue:$8F), (ColorName:'DarkSlateBlue';Red:$48;Green:$3D;Blue:$8B), (ColorName:'DarkSlateGray';Red:$2F;Green:$4F;Blue:$4F), (ColorName:'DarkSlateGrey';Red:$2F;Green:$4F;Blue:$4F), (ColorName:'DarkTurquoise';Red:$00;Green:$CE;Blue:$D1), (ColorName:'DarkViolet';Red:$94;Green:$00;Blue:$D3), (ColorName:'DeepPink';Red:$FF;Green:$14;Blue:$93), (ColorName:'DeepSkyBlue';Red:$00;Green:$BF;Blue:$FF), (ColorName:'DimGray';Red:$69;Green:$69;Blue:$69), (ColorName:'DimGrey';Red:$69;Green:$69;Blue:$69), (ColorName:'DodgerBlue';Red:$1E;Green:$90;Blue:$FF), (ColorName:'FireBrick';Red:$B2;Green:$22;Blue:$22), (ColorName:'FloralWhite';Red:$FF;Green:$FA;Blue:$F0), (ColorName:'ForestGreen';Red:$22;Green:$8B;Blue:$22), (ColorName:'Fuchsia';Red:$FF;Green:$00;Blue:$FF), (ColorName:'Gainsboro';Red:$DC;Green:$DC;Blue:$DC), (ColorName:'GhostWhite';Red:$F8;Green:$F8;Blue:$FF), (ColorName:'Gold';Red:$FF;Green:$D7;Blue:$00), (ColorName:'GoldenRod';Red:$DA;Green:$A5;Blue:$20), (ColorName:'Gray';Red:$80;Green:$80;Blue:$80), (ColorName:'Grey';Red:$80;Green:$80;Blue:$80), (ColorName:'Green';Red:$00;Green:$80;Blue:$00), (ColorName:'GreenYellow';Red:$AD;Green:$FF;Blue:$2F), (ColorName:'HoneyDew';Red:$F0;Green:$FF;Blue:$F0), (ColorName:'HotPink';Red:$FF;Green:$69;Blue:$B4), (ColorName:'IndianRed';Red:$CD;Green:$5C;Blue:$5C), (ColorName:'Indigo';Red:$4B;Green:$00;Blue:$82), (ColorName:'Ivory';Red:$FF;Green:$FF;Blue:$F0), (ColorName:'Khaki';Red:$F0;Green:$E6;Blue:$8C), (ColorName:'Lavender';Red:$E6;Green:$E6;Blue:$FA), (ColorName:'LavenderBlush';Red:$FF;Green:$F0;Blue:$F5), (ColorName:'LawnGreen';Red:$7C;Green:$FC;Blue:$00), (ColorName:'LemonChiffon';Red:$FF;Green:$FA;Blue:$CD), (ColorName:'LightBlue';Red:$AD;Green:$D8;Blue:$E6), (ColorName:'LightCoral';Red:$F0;Green:$80;Blue:$80), (ColorName:'LightCyan';Red:$E0;Green:$FF;Blue:$FF), (ColorName:'LightGoldenRodYellow';Red:$FA;Green:$FA;Blue:$D2), (ColorName:'LightGray';Red:$D3;Green:$D3;Blue:$D3), (ColorName:'LightGrey';Red:$D3;Green:$D3;Blue:$D3), (ColorName:'LightGreen';Red:$90;Green:$EE;Blue:$90), (ColorName:'LightPink';Red:$FF;Green:$B6;Blue:$C1), (ColorName:'LightSalmon';Red:$FF;Green:$A0;Blue:$7A), (ColorName:'LightSeaGreen';Red:$20;Green:$B2;Blue:$AA), (ColorName:'LightSkyBlue';Red:$87;Green:$CE;Blue:$FA), (ColorName:'LightSlateGray';Red:$77;Green:$88;Blue:$99), (ColorName:'LightSlateGrey';Red:$77;Green:$88;Blue:$99), (ColorName:'LightSteelBlue';Red:$B0;Green:$C4;Blue:$DE), (ColorName:'LightYellow';Red:$FF;Green:$FF;Blue:$E0), (ColorName:'Lime';Red:$00;Green:$FF;Blue:$00), (ColorName:'LimeGreen';Red:$32;Green:$CD;Blue:$32), (ColorName:'Linen';Red:$FA;Green:$F0;Blue:$E6), (ColorName:'Magenta';
[fpc-devel] TMask classes
Hello, I've written a TMask class family and I would like to know if it could be of any interest for the fpc code base, if there is interest I must write some unit test code but if there is no interest I'll not write it ;-) There is a TMask class in LazUtils but it lacks some features and has an speed problem in large strings when 2 or more '*' are involved. My TMask family is: TMaskAnsi, TMaskUTF8 and TMaskUnicode: This three classes hold the logic for each "char" space, ANSI 1 char, UTF8 1 to 6 bytes and Unicode 2 or 4 bytes. Available wildcards are: * = Any text. ? = Just one character unit. [abc] = Anyone of "abc" [a-c] = Anyone of "abc" (range) [!ab] = Negate a match "a" or "b" [!a-c] = Negate a match group [?] = One character unit or none. \? = Escape character '\' (next char is a literal "?") So the usual masks, nothing new under the sun. TMaskAnsi does not allow high chars ranges, so "[á-ú]" is not valid as characters in ANSI usually does not follow expected order. UTF8 and Unicode allows them as usually they are in the "expected order". Any feature can be toggled, so it can be set to ignore ranges, in example, so "[a-z]" will be interpreted as "a" or "-" or "z". Also the escape char can be configured, but it must be ASCII < 127. Derived from this classes there are: TMaskAnsiWindows, TMaskUTF8Windows and TMaskUnicodeWindows. This classes implements the special wildcards of Windows, inherited from CP/M, like "*." must match all files without extension, "*.*" must match any file, "file.ext" must match "file.extension" or "file??.ext" must match "file.ext", "file1.ext" and "file1a.ext". This special cases, are called Quirks and can be enabled or disabled one by one like ".ext" which in the past matches any file with ".ext" as extension, but this not happen in recent Windows versions, so in the code is disabled by default. Thank you for reading such amount of text, have a nice day. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Merging identical procedure proposals
El 16/10/2021 a las 21:57, J. Gareth Moreton via fpc-devel escribió: Certainly possible, and would address the whole function pointer thing, although I do question the performance hit because of the extra jump, especially for small procedures, as well as the fact that the function overhead would still be present. Certainly a safe start though. Hello, I do not know if its possible, but you can add a bunch of NOPs before real function, 1, 4, 8... NOPs, one group for each removed call. Of course a multiple times removed function can have a lot of NOPs to be executed before the real function body starts. -- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
