[fpc-pascal] Re: html link extractor
Is there a unit somewhere that can extract links from html pages? I want to be able to recursively add pages to a chm archive. I created a program called GetLinks in a couple minutes: Updated the files and changed the htmlutil functions a bit. Also, created a recursive example that uses Synapse.. and grabs web links *infinitely* until it finds no more links (using nested pascal function for the recursion, Torvalds hates those). The recursive demo probably won't work with file:// style links since it invokes Synapse, and only simple http relative paths work as is. (not sure if CHM files use file:// style links, guessing). Latest download includes recursive extractor and getlinks demo: http://z505.com/download/pascal/html/fast-html-parser-jul-02-2007.zip http://sourceforge.net/project/showfiles.php?group_id=145841package_id=212708release_id=520417 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] PowerPC crosscompiler on i386 Mac OS X looks for, wrong assembler and linker
A NOTE has been added to this issue. == http://www.freepascal.org/mantis/view.php?id=9201 == Reported By:Adriaan van Os Assigned To: == Project:FPC Issue ID: 9201 Category: Compiler Reproducibility:always Severity: minor Priority: normal Status: new FPCOldBugId:0 FPCTarget: - Fixed in Revision: == Date Submitted: 2007-07-02 16:08 CEST Last Modified: 2007-07-02 20:17 CEST == Summary:PowerPC crosscompiler on i386 Mac OS X looks for wrong assembler and linker Description: Building FreePascal on i386 Mac OS X with sudo ln -sf /usr/bin/as /usr/bin/powerpc-darwin-as sudo ln -sf /usr/bin/ld /usr/bin/powerpc-darwin-ld and make all CPU_TARGET=powerpc DEBUG=1 sudo make install CPU_TARGET=powerpc DEBUG=1 CROSSINSTALL=1 results in a PowerPC crosscompiler /usr/local/lib/fpc/2.3.1/ppcrossppc. The problem is that this compiler expects an assembler -as and a linker -ld. [p17:~/Support/fpcbugs] adriaan% /usr/local/lib/fpc/2.3.1/ppcrossppc p.p Free Pascal Compiler version 2.3.1 [2007/06/28] for powerpc Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Darwin for PowerPC Compiling p.p Assembling p Error: Assembler -as not found, switching to external assembling Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted [p17:~/Support/fpcbugs] adriaan% cat p.p program P; begin end. == -- Jonas Maebe - 2007-07-02 16:32 -- Have you installed FPC 2.1.4? The configuration file for earlier FPC's set a wrong (and superfluous) cross-compiling prefix when cross-compiling from Darwin to Darwin. 2.1.4 does not set any prefix at all, since plain as and ld are simple frontends which call through to the cpu-specific drivers. Check your /etc/fpc.cfg file. It should contain this: --- # set binutils prefix #DEFINE NEEDCROSSBINUTILS #ifdef darwin #undef NEEDCROSSBINUTILS #endif #IFDEF FPC_CROSSCOMPILING #IFDEF NEEDCROSSBINUTILS -XP$fpctarget- #ENDIF NEEDCROSSBINUTILS #ENDIF --- The -XP parameter is what sets the prefix. -- Adriaan van Os - 2007-07-02 20:00 -- Have you installed FPC 2.1.4? I installed fpc-2.1.4a.intel-macosx.dmg The configuration file for earlier FPC's set a wrong (and superfluous) cross-compiling prefix when cross-compiling from Darwin to Darwin. 2.1.4 does not set any prefix at all, since plain as and ld are simple frontends which call through to the cpu-specific drivers. compiling from Darwin to Darwin. 2.1.4 does not set any prefix at all, since plain as and ld are simple frontends which call through to the cpu-specific drivers. But somehow, it looks like a hyphen gets into the prefix Check your /etc/fpc.cfg file. It should contain this ... My /etc/fpc.cfg has these lines: # set binutils prefix #IFNDEF CPUI386 #IFNDEF CPUAMD64 #DEFINE NEEDCROSSBINUTILS #ENDIF #ENDIF #ifdef darwin #undef NEEDCROSSBINUTILS #endif #IFDEF FPC_CROSSCOMPILING #IFDEF NEEDCROSSBINUTILS -XP$fpctarget- #ENDIF NEEDCROSSBINUTILS #ENDIF so that looks OK. The -XP parameter is what sets the prefix. Compiling with -XP does solve the problem. [p17:~/Support/fpcbugs] adriaan% /usr/local/lib/fpc/2.3.1/ppcrossppc -XPpowerpc-darwin- p.p Free Pascal Compiler version 2.3.1 [2007/07/02] for powerpc Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Darwin for PowerPC Compiling p.p Assembling p Linking p 1 lines compiled, 0.7 sec -- Jonas Maebe - 2007-07-02 20:17 -- Maybe you have a ~/.fpc.cfg, or an fpc.cfg in the current directory? No, there is only one fpc.cfg on my computer and that's the one in /etc/ By default, no prefix is set, so it has to come from some configuration file you have somewhere.You can also try compiling with -va to see which config files are parsed (and see a lot of other debug information). Also, as far as I know you've cross-compiled successfully in the past, I tried ppcppc, but it turned it to be a PowerPC binary and it has endian issues
Re: [fpc-pascal] Documentation for sqldb - More Questions
I have a basic editable connection working now, but there remain a
number of questions:
1) When I tried editing in a dbGrid, I had trouble with the field
length. Looking through the code, I can't see anywhere where the length
of a string is checked against the length of the field, and longer
strings appear to overflow the field / record buffer. Should this be so
? I can fix the problem by doing the edits with a dbEdit control with a
specified maximum length, but I can't find anything in the dbGrid
component to do this. (I presume it would really be the TColumn
component)
My real question is, should it be the data control be doing it, or
should the sql components truncate a string that is too long ?
2) I am now trying a simple master slave form, with the slave table
having a parent field which links to the primary key (a sequence
generated number) in the master table. I can make this work with an
After Scroll Event on the master table thus:
with sqlAC {TSQLQuery component selecting from slave table} do begin
active := false;
Params[0].AsInteger := sqlPars.Fields[0].AsInteger; {sqlPars is on
the master table}
active := true;
end;
Is there anything less drastic than closing and reopening the sql that
will refresh the query with the new parameter values ?
I tried to do this by setting the datasource on the above SQL, (and
masking the AfterScroll event), but kept getting field not not found
errors. Should this work ? (I had the parameter name matching the
field name I was trying to link to. The field is only called ref, so
there is not a lot of room for typos, and yes I checked for the correct
case!)
3) Recently Joost van der Sluis wrote:
You could solve this problem by setting the update/delete/insert queries
yourself. (and set parsesql to false)
When I set ParseSQL to False, the object inspector in Lazarus says
updating is only possible if ParseSQL is true - unless I make it
readonly, which defeats the purpose.
Looking through the code, I surmise that when the query is opened,
InternalOpen calls Prepare which in turn calls ParseSQL, but that
ParseSQL exits after only getting the statement type if ParseSQL is
false. If the statement is a select statement and if it is
updateable, then InternalOpen initialises the update queries. If SQL
text is supplied, it is assigned to the queries, otherwise they are left
blank. When ApplyUpdates is called, this calls ApplyRecUpdate for each
record, and this then either runs the supplied SQL, or, if the supplied
SQL is null, generates it own SQL (using the stuff stored by Parse SQL) .
Is this basically correct ? (If so, you might see some of this expanded
a bit into some documentation)
If so, I guess leaving ParseSQL=true will waste some processing time,
but not actually stop it working.
Any hint about the structure of the code for the update queries ? I
guess I can work them out looking at what ApplyRecUpdate is trying to
generate, but an example would make life easier.
4) I still haven't been able to set a breakpoint in, or trace into any
of the sqldb code. Is there any good reason for this ? I can do so in
other library units, buttons for example. (If I could work this out,
I might be able to answer a more of the other questions for myself)
Thanks for your patience,
John
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpimage BMP and X11 implementation
On Tue, 3 Jul 2007, Graeme Geldenhuys wrote: Hi, I'm trying to implement fpimage support in the fpGUI widget framework. I'm really confused at the moment. :) The following queries apply to X11 (xlib) only. My GDI (windows) support will come later. My current BMP image implementation (which doesn't use the fpimage unit) has an internal TXImage. One for the Mask and one for the Image Data. Now creating a descendant of TFPCustomImage, I know I need to implement the following two methods. procedure SetInternalPixel(x, y: integer; Value: integer); override; function GetInternalPixel(x, y: integer): integer; override; 1) Those are the only abstract methods. So where am I supposed to create the instance of TXImage and assign it the internal data? When am I supposed to assign the internal data? See below. 2) Am I supposed to descend from TFPCustomImage or TFPMemoryImage? What's the difference? You must descend from TFPCustomImage. The difference is that TFPCustomImage provides no storage for the actual image data: all methods rely on the SetInternalPixel and GetInternalPixel methods. Careful, these are palette based. There are 2 other virtual calls which retrieve/set the actual colors: procedure SetInternalColor (x,y:integer; const Value:TFPColor); virtual; function GetInternalColor (x,y:integer) : TFPColor; virtual; By default, these work with the palette using the index retrieved/provided by SetInternalPixel and GetInternalPixel. It may make more sense to you to reverse the situation, depending on your storage format. TFPMemoryImage actually stores the data in an array in memory, independent of any device. (it stores the RGB values directly or using a palette) You should create a TFPCustomImage descendent which handles the storage through the TXImage auxiliary object. What you should do: Create a descendent of TFPCustomImage, say TFPGUIImage. It has an internal TXImage field. When the dimensions are set of the image (in SetSize), you allocate the TXImage with the correct dimensions: So I think the best is to override setsize, and create the TXImage there. Override destroy to free The TXImage. Then you override SetInternalColor, GetInternalColor, and SetInternalPixel and GetInternalPixel so they work as expected: they'll probably simply access the TXImage instance methods, and convert the internal format of TXImage to TFPColors. I hope this makes sense. If not, shoot :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tuesday 03 July 2007 09.55, John wrote: I have a basic editable connection working now, but there remain a number of questions: Have a look on MSEide+MSEgui: http://www.homepage.bluewin.ch/msegui/ Screenshots: http://sourceforge.net/project/screenshots.php?group_id=165409 It has lookup buffers, a sophisticated tdbwidgetgrid and many other useful components for database development and a stable and highly productive IDE. The users of MSEide+MSEgui affirm that it is production ready. Please send questions and bug reports to (NNTP): news://news.grid-sky.com/public.mseide-msegui.talk Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PowerPC crosscompiler on i386 Mac OS X looks for, wrong assembler and linker
On 3 jul 2007, at 09:45, Adriaan van Os wrote: Maybe you have a ~/.fpc.cfg, or an fpc.cfg in the current directory? No, there is only one fpc.cfg on my computer and that's the one in / etc/ Note the spelling of the first file: .fpc.cfg. Anyway, it doesn't matter, see below. By default, no prefix is set, so it has to come from some configuration file you have somewhere.You can also try compiling with -va to see which config files are parsed (and see a lot of other debug information). Also, as far as I know you've cross-compiled successfully in the past, I tried ppcppc, but it turned it to be a PowerPC binary That's by design (I now see I read your 9165 bug report wrongly). When doing a cross make all, you create both a cross compiler (ppcrossXXX) and a native compiler for the selected target platform (which can be used for bootstrapping on the target platform). and it has endian issues http://www.freepascal.org/mantis/view.php? id=9165. I meant before that. Or was that the first time ever you tried to compile a PowerPC binary on an Intel Mac? Using ppu files with compilers compiled for a different endianess than the compiler which generated those ppu files is simply something which is not supported at this time, because no one does that anymore nowadays (although Daniel is now trying to fix that -- and yes, we should have given an error message instead of failing due to reading invalid data from ppu files, but as I said, nobody even tried that for a very long time). It is not needed either for cross compiling, because all ppu files are generated using the cross compiler (and the created native compiler is only intended for bootstrapping). so what changed? Maybe it's better to take this to the mailing list, because this doesn't sound like a bug to me but a configuration problem. I am doing that now, but I bet it's a bug. Even if not, why is the build system so obscure some configuration file you have somewhere that this can happen ? I am not at all saying that FPC should follow GNU conventions, no, but at least the rules are clear there. You configure for target, host and build and then the Makefile takes cares of the rest. I'm sorry, but I'm not sure what is obscure here: a) Under *nix, FPC, like pretty much every other *nix app out there, supports three different default locations for configuration files, which are sought in the order current directory, home directory, global config directory (/etc on e.g. Mac OS X and Linux, /local/etc under *BSD, ...) b) when cross compiling, you can configure a prefix which has to be prepended to the names of the binutils. This is done using the -XP parameter. You indeed cannot do point b) with gcc afaik, because I believe that there the prefixes are hardcoded in the binary (probably specifiable as parameter to configure). It's debatable whether this is an advantage. As I asked, please try to use -va to see which config files are loaded by the compiler and which options it encounters and parses. And just like you now have a problem with fpc, other people also sometimes have trouble getting cross gcc to build/install properly. The number of howto's on how to build, install and use a cross-gcc is quite big. If a configuration is not supported or if there is a problem, you get a clear error message. Not always. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PowerPC crosscompiler on i386 Mac OS X looks for, wrong assembler and linker
Op Tue, 3 Jul 2007, schreef Adriaan van Os: I am not at all saying that FPC should follow GNU conventions, no, but at least the rules are clear there. You configure for target, host and build and then the Makefile takes cares of the rest. If a configuration is not supported or if there is a problem, you get a clear error message. The rules themselves are pretty clear: You have the PowerPC compiler on your system. This PowerPC compiler is capable of generating programs for MacOS classic, MacOS X, Linux and MorphOS. You run in on OS X, but that is not really important here, except that by default it is configured to generate programs for OS X, and if you compile for this default it calls as and ld. If you do not use the default, you probably need a different assembler and linker, and can use -XP option to specify how they are called. To help you the installation script puts -XP$fpctarget- in your config file, so that if you compile for Linux the compiler will search for powerpc-linux-as and powerpc-linux-ld. If things don't work out as expected, this is regrettable, but troubleshooting this is at least as least not harder than troubleshooting an unexpected Autoconf failure. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Need to declare FindIntToIdent in Classesh.inc
Hi, I need make this functions founded in classes.inc function FindIntToIdent(AIntegerType: Pointer): TIntToIdent; function FindIdentToInt(AIntegerType: Pointer): TIdentToInt; to be declared in classesh.inc as like as IdentToInt or IntToIdent I need it for my XML RTTI property writer/reader http://sourceforge.net/projects/minilib you can see my mnXMLFPClasses.pas mnXMLRttiWriter.pas procedure TmnXMLRttiWriter.WriteProperty Thanks in advance -- zaher dirkey ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 2007-07-03 at 17:55 +1000, John wrote:
I have a basic editable connection working now, but there remain a
number of questions:
1) When I tried editing in a dbGrid, I had trouble with the field
length. Looking through the code, I can't see anywhere where the length
of a string is checked against the length of the field, and longer
strings appear to overflow the field / record buffer. Should this be so
? I can fix the problem by doing the edits with a dbEdit control with a
specified maximum length, but I can't find anything in the dbGrid
component to do this. (I presume it would really be the TColumn
component)
This is more a Lazarus-issue.
My real question is, should it be the data control be doing it, or
should the sql components truncate a string that is too long ?
The data-controls. Or you can leave it to the SQL-Server. The official
SQL-specs say that the string should be truncated without any error. But
not all SQL-servers obey that rule...
2) I am now trying a simple master slave form, with the slave table
having a parent field which links to the primary key (a sequence
generated number) in the master table. I can make this work with an
After Scroll Event on the master table thus:
with sqlAC {TSQLQuery component selecting from slave table} do begin
active := false;
Params[0].AsInteger := sqlPars.Fields[0].AsInteger; {sqlPars is on
the master table}
active := true;
end;
Is there anything less drastic than closing and reopening the sql that
will refresh the query with the new parameter values ?
I tried to do this by setting the datasource on the above SQL, (and
masking the AfterScroll event), but kept getting field not not found
errors. Should this work ? (I had the parameter name matching the
field name I was trying to link to. The field is only called ref, so
there is not a lot of room for typos, and yes I checked for the correct
case!)
There is some master-slave system build in. But it effectively does the
same as you did. Hoe you should use it exactly, I don't know.
3) Recently Joost van der Sluis wrote:
You could solve this problem by setting the update/delete/insert queries
yourself. (and set parsesql to false)
When I set ParseSQL to False, the object inspector in Lazarus says
updating is only possible if ParseSQL is true - unless I make it
readonly, which defeats the purpose.
That's a but, I think. It should check if there are any
update/delete/insert queries provided. If that is the case, you can make
a query updateable, even if ParseSQL is false.
Looking through the code, I surmise that when the query is opened,
InternalOpen calls Prepare which in turn calls ParseSQL, but that
ParseSQL exits after only getting the statement type if ParseSQL is
false. If the statement is a select statement and if it is
updateable, then InternalOpen initialises the update queries. If SQL
text is supplied, it is assigned to the queries, otherwise they are left
blank. When ApplyUpdates is called, this calls ApplyRecUpdate for each
record, and this then either runs the supplied SQL, or, if the supplied
SQL is null, generates it own SQL (using the stuff stored by Parse SQL) .
Is this basically correct ? (If so, you might see some of this expanded
a bit into some documentation)
Yes, except...
If so, I guess leaving ParseSQL=true will waste some processing time,
but not actually stop it working.
... sometimes ParseSQL also changes the query a bit, mostly to help
filtering work. In some cases, the query isn't parsed correctly, and the
changes make the query invalid. If that's the case, you'll get syntax
errors in your query, while you think that there's nothing wrong. In
that case you have to set parsesql to false.
Second thing is that it also tries to obtain the primary key. This could
also lead to trouble. (as in your case)
Any hint about the structure of the code for the update queries ? I
guess I can work them out looking at what ApplyRecUpdate is trying to
generate, but an example would make life easier.
update table tblPeople set name=:name, birthdate=:birthdate,
email=:email where PeopleID=:PeopleID
4) I still haven't been able to set a breakpoint in, or trace into any
of the sqldb code. Is there any good reason for this ? I can do so in
other library units, buttons for example. (If I could work this out,
I might be able to answer a more of the other questions for myself)
That's because sqldb is part of Freepascal, while buttons is part of
Lazarus. By default, fpc is distributed without debug-info, but Lazarus
does have debug-info.
So you have to recompile fcl-db with debug info. If you have the full
fpc-sources, go to fpc/packages/fcl-db and execute 'make clean all
OPT='-gl' '
After you have done that you have to install the freshly created .ppu's.
You could copy them over the old ones yourself. Or you could use 'make
install' if the
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tuesday 03 July 2007 11.36, Michael Van Canneyt wrote: Why don't you contribute the database code to the FCL ? This way, everybody benefits from it. It's non-visual code, so it can perfectly be separated out. It depends on the completely rewritten tmsebufdataset, if you want to use the MSEgui DB components you need to to replace TBufDataset with tmsebufdataset and the SQL connection components need to be patched. The development speed of MSEide+MSEgui is too fast that I could depend for DB code on FCL with the difficult and time consuming FPC coordination process for bug fixes and changes. Another problem is that I am not bound to Delphi compatibility so I don't think that my code will be accepted by the FPC team. Feel free to integrate any MSEgui code which you will find useful into FCL. :-) Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpimage BMP and X11 implementation
On 03/07/07, Michael Van Canneyt [EMAIL PROTECTED] wrote: Create a descendent of TFPCustomImage, say TFPGUIImage. It has an internal TXImage field. When the dimensions are set of the image (in SetSize), you allocate the TXImage with the correct dimensions: So I think the best is to override setsize, and create the TXImage there. Override destroy to free The TXImage. Then you override SetInternalColor, GetInternalColor, and SetInternalPixel and GetInternalPixel so they work as expected: they'll probably simply access the TXImage instance methods, and convert the internal format of TXImage to TFPColors. I hope this makes sense. If not, shoot :-) Brilliant. It makes more sense now. Thanks again for you time... :) Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Martin Schreiber wrote: On Tuesday 03 July 2007 11.36, Michael Van Canneyt wrote: Why don't you contribute the database code to the FCL ? This way, everybody benefits from it. It's non-visual code, so it can perfectly be separated out. It depends on the completely rewritten tmsebufdataset, if you want to use the MSEgui DB components you need to to replace TBufDataset with tmsebufdataset and the SQL connection components need to be patched. So in fact, you are duplicating SQLDB. Judging from your website, you even used the lazarus icons for the components. (this is ok, just a constatation) The development speed of MSEide+MSEgui is too fast that I could depend for DB code on FCL with the difficult and time consuming FPC coordination process for bug fixes and changes. Another problem is that I am not bound to Delphi compatibility so I don't think that my code will be accepted by the FPC team. Since SQLDB is in no way connected to Delphi, so you're free to do as you please, as long as it descends from TDataset ? The coordination process would be non-existent, because I would give you direct access to the FCL subversion. As long as you follow the rules for the merging of fixes to fixbranches there is no problem. In fact there would be less problems, as fixes would be tested sooner/better and would make it to the fixes branch easier. With the new packaging system which will be in effect after 2.2, the FCL can be released on a more regular basis. Feel free to integrate any MSEgui code which you will find useful into FCL. :-) I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. There are not so many people available who understand the inner workings of TDataset and friends, so all this scattering and dividing is counterproductive. It would be much better if you, me, Joost and Bram (who work on SQLDB) had a single set of components to work with: speed would not be an issue then, and we could guarantee a working and reliable set of components for everyone. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Need to declare FindIntToIdent in Classesh.inc
On Tue, 3 Jul 2007, zaher dirkey wrote: Hi, I need make this functions founded in classes.inc function FindIntToIdent(AIntegerType: Pointer): TIntToIdent; function FindIdentToInt(AIntegerType: Pointer): TIdentToInt; Why don't you use the IdentToInt and IntToIdent functions ? The streaming in lazarus works perfectly without these 2 functions, and exposing an internal function is not a good idea; Then we cannot change them anymore. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. There are not so many people available who understand the inner workings of TDataset and friends, so all this scattering and dividing is counterproductive. It would be much better if you, me, Joost and Bram (who work on SQLDB) had a single set of components to work with: speed would not be an issue then, and we could guarantee a working and reliable set of components for everyone. As a relatively new user, I absolutely agree. There is a wealth of components already, and trying to work out which to use where is already quite daunting, especially when there is little/no documentation to guide you! And I am new only to FPC/Lazurus - I have been programming Pascal since Turbo Pascal 3, and did some reasonably serious database applications using Delphi 4 C/S into Oracle on the side during a stint as an Oracle DBA. John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
Joost van der Sluis wrote: On Tue, 2007-07-03 at 17:55 +1000, John wrote: I have a basic editable connection working now, but there remain a number of questions: 1) When I tried editing in a dbGrid, I had trouble with the field length. Looking through the code, I can't see anywhere where the length of a string is checked against the length of the field, and longer strings appear to overflow the field / record buffer. Should this be so ? I can fix the problem by doing the edits with a dbEdit control with a specified maximum length, but I can't find anything in the dbGrid component to do this. (I presume it would really be the TColumn component) This is more a Lazarus-issue. My real question is, should it be the data control be doing it, or should the sql components truncate a string that is too long ? The data-controls. Or you can leave it to the SQL-Server. The official SQL-specs say that the string should be truncated without any error. But not all SQL-servers obey that rule... The problem is that if the strings are too long, they overflow the buffer - I think the record buffer in T(Buf)Dataset - and break things before the data gets as far as the database itself. But I take your point and will have a look at the data controls That's because sqldb is part of Freepascal, while buttons is part of Lazarus. Ah, that distinction did cross my mind, but I didn't see why it would matter. I will have a go as you suggested. Thanks very much for all the help John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 2007-07-03 at 20:30 +1000, John wrote: 1) When I tried editing in a dbGrid, I had trouble with the field length. Looking through the code, I can't see anywhere where the length of a string is checked against the length of the field, and longer strings appear to overflow the field / record buffer. Should this be so ? I can fix the problem by doing the edits with a dbEdit control with a specified maximum length, but I can't find anything in the dbGrid component to do this. (I presume it would really be the TColumn component) This is more a Lazarus-issue. My real question is, should it be the data control be doing it, or should the sql components truncate a string that is too long ? The data-controls. Or you can leave it to the SQL-Server. The official SQL-specs say that the string should be truncated without any error. But not all SQL-servers obey that rule... The problem is that if the strings are too long, they overflow the buffer - I think the record buffer in T(Buf)Dataset - and break things before the data gets as far as the database itself. Can you make a bug-report for this? -- Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 2007-07-03 at 12:57 +0200, Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. I aggree with Michael on this. Besides, last time I looked at your 'TBufDataset' (which is a actually a fork, offcourse) it only implemented blob-fields, on top of the existing TBufDataset. The current TBufDataset also supports blob-fields, in a (in my opinion) better way, now. Are there any other changes/additions? Regards, Joost ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tuesday 03 July 2007 12.57, Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. There are not so many people available who understand the inner workings of TDataset and friends, so all this scattering and dividing is counterproductive. It would be much better if you, me, Joost and Bram (who work on SQLDB) had a single set of components to work with: speed would not be an issue then, and we could guarantee a working and reliable set of components for everyone. You are right, I will think about your offer. :-) Michael, Joost and Bram please look into my code, can you imagine to merge with FCL? The relevant files are in https://mseide-msegui.svn.sourceforge.net/svnroot/mseide-msegui/trunk/lib/common/db Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tuesday 03 July 2007 13.16, Joost van der Sluis wrote: On Tue, 2007-07-03 at 12:57 +0200, Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. I aggree with Michael on this. Besides, last time I looked at your 'TBufDataset' (which is a actually a fork, offcourse) it only implemented blob-fields, on top of the existing TBufDataset. The current TBufDataset also supports blob-fields, in a (in my opinion) better way, now. Are there any other changes/additions? It is completely rewritten. Buffer organisation is not a linked list, the record pointers are hold in arrays to allow simple record accessing by locally builded indexes and easy recno handling. String fields are stored as widestrings, there are no fixed string field sizes in the record buffer. It has the possibility to work comparable to TClientDataset with a local change log and data file. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Martin Schreiber wrote: On Tuesday 03 July 2007 12.57, Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. There are not so many people available who understand the inner workings of TDataset and friends, so all this scattering and dividing is counterproductive. It would be much better if you, me, Joost and Bram (who work on SQLDB) had a single set of components to work with: speed would not be an issue then, and we could guarantee a working and reliable set of components for everyone. You are right, I will think about your offer. :-) That's good, thank you :-) Michael, Joost and Bram please look into my code, can you imagine to merge with FCL? The relevant files are in https://mseide-msegui.svn.sourceforge.net/svnroot/mseide-msegui/trunk/lib/common/db Checking out now. I'll consult with Joost and Bram separately. I am a bit worried about the widestring issue. While good for msegui which uses widestrings internally, it's also slower and more memory consuming. A fixed buffer has it's advantages. The change-log handling and indexes are a Good Thing (tm), and I remarked on that some time ago already :-) We'll see. Let me consult, and then I'll get back to you. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Martin Schreiber wrote: On Tuesday 03 July 2007 13.16, Joost van der Sluis wrote: On Tue, 2007-07-03 at 12:57 +0200, Michael Van Canneyt wrote: I'd rather see that the whole is coordinated a bit. I don't think all this duplication is a good idea; One solid set of components makes much more sense: the number of developers available for it's maintenance would double. The end user would also benefit, as we can give 1 solid set of components, no doubts possible. I aggree with Michael on this. Besides, last time I looked at your 'TBufDataset' (which is a actually a fork, offcourse) it only implemented blob-fields, on top of the existing TBufDataset. The current TBufDataset also supports blob-fields, in a (in my opinion) better way, now. Are there any other changes/additions? It is completely rewritten. Buffer organisation is not a linked list, the record pointers are hold in arrays to allow simple record accessing by locally builded indexes and easy recno handling. String fields are stored as widestrings, there are no fixed string field sizes in the record buffer. Quick question, before I continue with the evaluation: I find no evidence of this last thing in the code ? (in trunk, that is) msbufdataset has fixed buffers for strings, and uses 1 byte per char. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tuesday 03 July 2007 14.49, Michael Van Canneyt wrote: Quick question, before I continue with the evaluation: I find no evidence of this last thing in the code ? (in trunk, that is) msbufdataset has fixed buffers for strings, and uses 1 byte per char. There is some garbage in the directory. The component is tmsebufdataset and the file msebufdataset.pas. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Martin Schreiber wrote: On Tuesday 03 July 2007 14.49, Michael Van Canneyt wrote: Quick question, before I continue with the evaluation: I find no evidence of this last thing in the code ? (in trunk, that is) msbufdataset has fixed buffers for strings, and uses 1 byte per char. There is some garbage in the directory. The component is tmsebufdataset and the file msebufdataset.pas. Hm. Quite the difference, indeed. Thanks. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
Joost van der Sluis wrote: When I set ParseSQL to False, the object inspector in Lazarus says "updating is only possible if ParseSQL is true" - unless I make it readonly, which defeats the purpose. That's a but, I think. It should check if there are any update/delete/insert queries provided. If that is the case, you can make a query updateable, even if ParseSQL is false. Well, I put some code in each of the update sql StringLists. I don't guarantee it is completely correct, but it should be close. This did not seem to make any difference. Is this worth a bug report ? In the mean time, as it is probably only a Lazarus designer issue, I will try modifying it in code somehow. Re the string length issue, I have changed the application I am working on too much to use it to double check exactly what happened, so I will set up a minimal application and submit a bug report on that once I am sure I wasn't dreaming. So you have to recompile fcl-db with debug info. If you have the full fpc-sources, go to fpc/packages/fcl-db and execute 'make clean all OPT='-gl' ' After you have done that you have to install the freshly created .ppu's. You could copy them over the old ones yourself. Or you could use 'make install' if the system is configured right. I only have the fpc that came with lazarus, and it doesn't look like that. I tried recompiling and reinstalling the SQLDBLaz package with the 'generate debugging info' option checked - it wasn't previously - hoping that that might achieve the same result, but it doesn't seem to have. I am happy to keep playing with this, but any words of wisdom would be appreciated! I am still a bit lost between the packages under lazarus and the stuff under fpc under lazarus, and how they interact. (I have started looking to add some documentation to the wiki area, but this also is a new adventure for me!) cheers, John ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 2007-07-03 at 14:13 +0200, Martin Schreiber wrote: I aggree with Michael on this. Besides, last time I looked at your 'TBufDataset' (which is a actually a fork, offcourse) it only implemented blob-fields, on top of the existing TBufDataset. The current TBufDataset also supports blob-fields, in a (in my opinion) better way, now. Are there any other changes/additions? It is completely rewritten. Buffer organisation is not a linked list, the record pointers are hold in arrays to allow simple record accessing by locally builded indexes and easy recno handling. String fields are stored as widestrings, there are no fixed string field sizes in the record buffer. It has the possibility to work comparable to TClientDataset with a local change log and data file. I had the 'old' tmbufdataset in mind. The TMSEbufDataset is indeed very different. As you can probably remember, the TBufDataset also used a array to store the record buffers. I changed that because benchmarks showed that the current solution is much faster. Even if you want to address a record immediately, as long as you use a bookmark, and not the recno directly. Which is imho not always a good idea. But there are no indexes yet, that's completely true. What I do like is the idea of storing strings in a widestring/ansistring. I tried to implement that earlier, but it's not doable in a Delphi-compatible way. As you said, you don't have that problem. But it's still something on my whish-list for sqldb/TDataset/TBufDataset. There must be a solution, without using the blob-system... What do you mean with the local change log and data file? Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How do I join the Lazarus list?
I cannot seem to find a way to join the mailing list. TIA, Tom ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Joost van der Sluis wrote: On Tue, 2007-07-03 at 14:13 +0200, Martin Schreiber wrote: I aggree with Michael on this. Besides, last time I looked at your 'TBufDataset' (which is a actually a fork, offcourse) it only implemented blob-fields, on top of the existing TBufDataset. The current TBufDataset also supports blob-fields, in a (in my opinion) better way, now. Are there any other changes/additions? It is completely rewritten. Buffer organisation is not a linked list, the record pointers are hold in arrays to allow simple record accessing by locally builded indexes and easy recno handling. String fields are stored as widestrings, there are no fixed string field sizes in the record buffer. It has the possibility to work comparable to TClientDataset with a local change log and data file. I had the 'old' tmbufdataset in mind. The TMSEbufDataset is indeed very different. As you can probably remember, the TBufDataset also used a array to store the record buffers. I changed that because benchmarks showed that the current solution is much faster. Even if you want to address a record immediately, as long as you use a bookmark, and not the recno directly. Which is imho not always a good idea. Recno should never be used for positioning. But there are no indexes yet, that's completely true. What I do like is the idea of storing strings in a widestring/ansistring. I tried to implement that earlier, but it's not doable in a Delphi-compatible way. As you said, you don't have that problem. But it's still something on my whish-list for sqldb/TDataset/TBufDataset. There must be a solution, without using the blob-system... I do not think this is a good idea: the amount of memory used for this is a multiple of the classic buffer scheme, the heap will be terribly fragmented. The buffer system is exactly meant to save memory (blobs excepted). What do you mean with the local change log and data file? Like TClientDataset: the changes to the records (the delta) are kept in a separate index. All can be written to file. It's a briefcase model. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 2007-07-03 at 17:38 +0200, Michael Van Canneyt wrote: What I do like is the idea of storing strings in a widestring/ansistring. I tried to implement that earlier, but it's not doable in a Delphi-compatible way. As you said, you don't have that problem. But it's still something on my whish-list for sqldb/TDataset/TBufDataset. There must be a solution, without using the blob-system... I do not think this is a good idea: the amount of memory used for this is a multiple of the classic buffer scheme, the heap will be terribly fragmented. The buffer system is exactly meant to save memory (blobs excepted). Do you think? Using the buffer, there's a lot of memory which isn't used. I thought about adding a new kind of fieldtype, for example ftAnsiString which you could use for larger strings. But maybe you can use a ftMemo in that case What do you mean with the local change log and data file? Like TClientDataset: the changes to the records (the delta) are kept in a separate index. All can be written to file. It's a briefcase model. I thought so. TBufDataset also has that, it can't save it to file, though. But that's easy to implement. -- Met vriendelijke groeten, Joost van der Sluis CNOC Informatiesystemen en Netwerken http://www.cnoc.nl ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] DateToStr in arm does not work!
Hi Everyone; Please, can someone test this program and write to the list if it works in arm-linux. program datetostr_test; uses sysutils; begin writeln(datetostr(now)); end. I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 if for someone this program work, please write me with your Fpc for arm version. thank you in advanced best regards Jose Pascual ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
On 03/07/07, josepascual [EMAIL PROTECTED] wrote: Hi Everyone; Please, can someone test this program and write to the list if it works in arm-linux. program datetostr_test; uses sysutils; begin writeln(datetostr(now)); end. works for me, using svn 7929, compiled for arm little endian with soft float. I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 if for someone this program work, please write me with your Fpc for arm version. thank you in advanced best regards Jose Pascual henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] DateToStr in arm does not work!
Thank you henry, I have downloaded svn version 7943 how can I donwload svn 7929? How are you build fpc for arm? make clean crossall CPU_TARGET=arm OS_TARGET=linux ? Which version of binutils do you have? (eabi?) Is SOFTFLOAT in freepascal the equivalent to EABI in c? thank you! Jose Pascual -Mensaje original- De: [EMAIL PROTECTED] [mailto:fpc-pascal- [EMAIL PROTECTED] En nombre de Henry Vermaak Enviado el: martes, 03 de julio de 2007 18:15 Para: FPC-Pascal users discussions Asunto: Re: [fpc-pascal] DateToStr in arm does not work! On 03/07/07, josepascual [EMAIL PROTECTED] wrote: Hi Everyone; Please, can someone test this program and write to the list if it works in arm-linux. program datetostr_test; uses sysutils; begin writeln(datetostr(now)); end. works for me, using svn 7929, compiled for arm little endian with soft float. I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 if for someone this program work, please write me with your Fpc for arm version. thank you in advanced best regards Jose Pascual henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal __ Información de NOD32, revisión 2374 (20070703) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
On 7/3/07, josepascual [EMAIL PROTECTED] wrote: I have downloaded svn version 7943 how can I donwload svn 7929? svn update -r 7929 -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation for sqldb - More Questions
On Tue, 3 Jul 2007, Joost van der Sluis wrote: On Tue, 2007-07-03 at 17:38 +0200, Michael Van Canneyt wrote: What I do like is the idea of storing strings in a widestring/ansistring. I tried to implement that earlier, but it's not doable in a Delphi-compatible way. As you said, you don't have that problem. But it's still something on my whish-list for sqldb/TDataset/TBufDataset. There must be a solution, without using the blob-system... I do not think this is a good idea: the amount of memory used for this is a multiple of the classic buffer scheme, the heap will be terribly fragmented. The buffer system is exactly meant to save memory (blobs excepted). Do you think? Using the buffer, there's a lot of memory which isn't used. Not more than when using ansistrings - or worse, widestrings - to store the string data. You forget the heap overhead and ansistring hidden data, plus the whole reference counting mechanism. I thought about adding a new kind of fieldtype, for example ftAnsiString which you could use for larger strings. But maybe you can use a ftMemo in that case Memo is very special and hard to handle in grids and the like. See my private mail to you for a more detailed calculation. What do you mean with the local change log and data file? Like TClientDataset: the changes to the records (the delta) are kept in a separate index. All can be written to file. It's a briefcase model. I thought so. TBufDataset also has that, it can't save it to file, though. But that's easy to implement. Indeed. All one needs is some time :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do I join the Lazarus list?
Tom York wrote: I cannot seem to find a way to join the mailing list. It's on this page: http://www.lazarus.freepascal.org/modules.php?op=modloadname=StaticPagefile=indexsURL=maill It's the link that says subscribe mailto:[EMAIL PROTECTED] Regards, Andrew ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
En/na josepascual ha escrit: I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 same here (only at a different address), though I have many funky errors under arm that nobody else has. Using self-built native fpc-2.1.4 [EMAIL PROTECTED]:~$ uname -a Linux lspro 2.6.12.6-arm1 #77 Tue Dec 5 22:23:46 CST 2006 armv5tejl GNU/Linux [EMAIL PROTECTED]:~$ cat /proc/cpuinfo Processor : ARM926EJ-Sid(wb) rev 0 (v5l) BogoMIPS: 266.24 Features: swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part: 0x926 CPU revision: 0 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format: Harvard I size : 32768 I assoc : 1 I line length : 32 I sets : 1024 D size : 32768 D assoc : 1 D line length : 32 D sets : 1024 Hardware: MV-88fxx81 Revision: Serial : Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PowerPC crosscompiler on i386 Mac OS X looks for, wrong assembler and linker
Adriaan van Os wrote: build and then the Makefile takes cares of the rest. If a configuration is not supported or if there is a problem, you get a clear error message. You *must* be joking, right ? Usually it involves digging through a messy config.log, where you sometimes can't really find the reason (just one of those mysterious test compiles failed) and then have to decrypt an enormously complex configure script that will give you nightmares for years. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
En/na Henry Vermaak ha escrit:
soft float just means that the compiler needs to emulate the floating
point unit if it doesn't exist in your hardware (like some arm
processors). if you have an fpu, then you don't have to worry about
soft float. the following assumes that you need soft float in you
compiler.
If this program compiles and works fine:
program floattest;
uses sysutils;
var a,b:double;
begin
a:=0.5;
b:=0.3;
writeln(format('%5.3f',[a*b]));
end.
can I assume that either my compiler has been built with the right
options or I have a working fpu?
I'm asking because jose original test program fails here, while the
above program correctly prints out 0.150
Bye
--
Luca
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
On 03/07/07, Bernd Mueller [EMAIL PROTECTED] wrote: Are you sure? If I remember right, using softfloat in conjunction with fpc means, that the compiler never emits floating point operations. All the floating point is going through the softfpu unit. This means, *if* you have a fpu, you waste speed. that's right. i've got two arm devices without fpus, though... Regards, Bernd. henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
josepascual wrote: Hi Everyone; Please, can someone test this program and write to the list if it works in arm-linux. program datetostr_test; uses sysutils; begin writeln(datetostr(now)); end. I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 if for someone this program work, please write me with your Fpc for arm version. the program works for me. FPC 2.1.4 compiler built without softfloat option, running on an (little endian) ARM processor without fpu on Linux, kernel version 2.6.21.1 (OABI). ppcrossarm -gl datetostr_test.pas Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
Am Dienstag, den 03.07.2007, 21:49 +0200 schrieb Bernd Mueller: Henry Vermaak wrote: On 03/07/07, josepascual [EMAIL PROTECTED] wrote: Thank you henry, I have downloaded svn version 7943 how can I donwload svn 7929? How are you build fpc for arm? make clean crossall CPU_TARGET=arm OS_TARGET=linux ? Which version of binutils do you have? (eabi?) Is SOFTFLOAT in freepascal the equivalent to EABI in c? soft float just means that the compiler needs to emulate the floating point unit if it doesn't exist in your hardware (like some arm processors). if you have an fpu, then you don't have to worry about soft float. Are you sure? If I remember right, using softfloat in conjunction with fpc means, that the compiler never emits floating point operations. All the floating point is going through the softfpu unit. This means, *if* you have a fpu, you waste speed. The ARM926EJ-S core does not have a FPU but an interface for coprocessors. So if there is floating point hardware built in depends on the chip manufacturer. Not having FPU hardware is currently the most possible case for ARM7 and ARM9, the only chip I know of having a VFP9 FPU is the LPC3180 from Phillips. This may change, at least Fujitsu has some designs in the pipeline for 3rd or 4th quarter of this year IIRC. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
En/na Bernd Mueller ha escrit: FPC 2.1.4 compiler built without softfloat option, running on an (little endian) ARM processor without fpu on Linux, kernel version 2.6.21.1 (OABI). ppcrossarm -gl datetostr_test.pas could you check bug 9191? http://www.freepascal.org/mantis/view.php?id=9191 Bye. -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
Luca, > could you check bug 9191? > > http://www.freepascal.org/mantis/view.php?id=9191 if I try to compile, the linker complaints about not finding the object dl, though dl.o and dl.ppu are present in the rtl/units/arm-linux directory. D:\FPC214\B1\BINUTI~3\arm-linux-ld.exe: cannot find -ldl pippo.pas(47,6) Error: Error while linking pippo.pas(47,6) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted How do you call the compiler? And please show me your fpc.cfg file. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
En/na [EMAIL PROTECTED] ha escrit: Luca, could you check bug 9191? http://www.freepascal.org/mantis/view.php?id=9191 if I try to compile, the linker complaints about not finding the object dl, though dl.o and dl.ppu are present in the rtl/units/arm-linux directory. D:\FPC214\B1\BINUTI~3\arm-linux-ld.exe: cannot find -ldl pippo.pas(47,6) Error: Error while linking pippo.pas(47,6) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted How do you call the compiler? And please show me your fpc.cfg file. I do simply an fpc pippo.pas (or fpc pippo2.pas), I'm running it directly on the arm, I'm not cross-compiling (that's why I asked you, I wanted to see if cross-compiling makes a difference). My fpc.cfg is what the installer for 2.1.3 generated, manually amended for 2.1.4 (consider that fpc is installed under /home/luca/fpc-2.1.4). It's attached. Bye -- Luca # # Example fpc.cfg for Free Pascal Compiler # # -- # Defines (preprocessor) # -- # # nested #IFNDEF, #IFDEF, #ENDIF, #ELSE, #DEFINE, #UNDEF are allowed # # -d is the same as #DEFINE # -u is the same as #UNDEF # # # Some examples (for switches see below, and the -? helppages) # # Try compiling with the -dRELEASE or -dDEBUG on the commandline # # For a release compile with optimizes and strip debuginfo #IFDEF RELEASE -O2 -Xs #WRITE Compiling Release Version #ENDIF # For a debug version compile with debuginfo and all codegeneration checks on #IFDEF DEBUG -g -Crtoi #WRITE Compiling Debug Version #ENDIF # set binutils prefix #DEFINE NEEDCROSSBINUTILS #IFDEF FPC_CROSSCOMPILING #IFDEF NEEDCROSSBINUTILS -XP$fpctarget- #ENDIF NEEDCROSSBINUTILS #ENDIF # # Parsing switches # # Pascal language mode # -Mfpc free pascal dialect (default) # -Mobjfpc switch some Delphi 2 extensions on # -Mdelphi tries to be Delphi compatible # -Mtp tries to be TP/BP 7.0 compatible # -Mgpc tries to be gpc compatible # -Mmacpas tries to be compatible to the macintosh pascal dialects # # Turn on Object Pascal extensions by default #-Mobjfpc # Assembler reader mode # -Rdefault use default assembler # -Ratt read ATT style assembler # -Rintelread Intel style assembler # # All assembler blocks are ATT styled by default #-Ratt # Semantic checking # -S2same as -Mobjfpc # -Scsupports operators like C (*=,+=,/= and -=) # -Sainclude assertion code. # -Sdsame as -Mdelphi # -Sex error options. x is a combination of the following: # n : compiler stops after the n errors (default is 1) # w : compiler stops also after warnings # n : compiler stops also after notes # h : compiler stops also after hints # -Sgallow LABEL and GOTO # -ShUse ansistrings # -Sisupport C++ styled INLINE # -Skload fpcylix unit # -SIx set interface style to x # -SIcom COM compatible interface (default) # -SIcorba CORBA compatible interface # -Smsupport macros like C (global) # -Sosame as -Mtp # -Spsame as -Mgpc # -Ssconstructor name must be init (destructor must be done) # -Stallow static keyword in objects # -Sxenable exception keywords (default in Delphi/ObjFPC modes) # # Allow goto, inline, C-operators, C-vars -Sgic # --- # Code generation # --- # Uncomment the next line if you always want static/dynamic units by default # (can be overruled with -CD, -CS at the commandline) #-CS #-CD # Set the default heapsize to 8Mb #-Ch800 # Set default codegeneration checks (iocheck, overflow, range, stack) #-Ci #-Co #-Cr #-Ct # Optimizer switches # -Osgenerate smaller code # -O1level 1 optimizations (quick optimizations, debuggable) # -O2level 2 optimizations (-O1 + optimizations which make debugging more difficult) # -O3level 3 optimizations (-O2 + optimizations which also may make the program slower rather than faster) # -Opx set target cpu for optimizing, see fpc -i for possible values # # See fpc -i also for more fine-grained control over which optimizations # to perform # --- # Set Filenames and Paths # --- # Slashes are also allowed under dos # path to the messagefile, not necessary anymore but can be used to override # the default language #-Fr/home/luca/fpc-2.1.4/lib/$fpcversion/msg/errore.msg #-Fr/home/luca/fpc-2.1.4/lib/$fpcversion/msg/errorn.msg # searchpath for includefiles #-Fi/pp/inc;/pp/rtl/inc # searchpath for units and other system dependent things -Fu/home/luca/fpc-2.1.4/lib/fpc/$fpcversion/units/$fpctarget -Fu/home/luca/fpc-2.1.4/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/home/luca/fpc-2.1.4/lib/fpc/$fpcversion/units/$fpctarget/rtl
