from:"Reinier Olislagers"

On 3-8-2011 9:48, Tony Whyman wrote:
 Reiner,
 
 You can certainly do this with IBX for Lazarus
 (http://www.mwasoftware.co.uk). You will also find there some guidelines
 on using the Firebird embedded library under both Windows and Linux that
 are more general than just IBX.
 
 If you want to stick with SQLDB then there is a global variable
 UseEmbeddedFirebird that you need to set to force use of the embedded
 library.
 
Thanks for the suggestion, Tony. I did download and install IBX, but
then I found bug report
http://bugs.freepascal.org/view.php?id=13340
with sample code for regular sqldb.

Adapted this code*:

(*Note: if you don't specify UseEmbeddedFirebird, you can rename
fbembed.dll to fbclient.dll and get the same results - I'd wish somebody
would implement the provided fix in issue
http://bugs.freepascal.org/view.php?id=17664)

//requires ibase60dyn in uses:
  UseEmbeddedFirebird:=true;
  IBConnection1.HostName := '';
  IBConnection1.DatabaseName := DatabaseFile; //
  IBConnection1.Username := 'SYSDBA';
  IBConnection1.Password := 'masterkey';
  IBConnection1.Charset := 'UTF8';
  IBConnection1.Dialect := 3;
  DBParams:=TStringList.Create;
  try
DBParams.Add('PAGE_SIZE=16384');
IBConnection1.Params := DBParams;
  finally
  DBParams.Free;
  end;

  if (FileExists(DatabaseFile)=false) then
  begin
  SQLTransaction1.Active:=false;
  IBConnection1.Transaction:=SQLTransaction1;
  IBConnection1.CreateDB; //Create the database file.

  IBConnection1.Open;
  SQLTransaction1.StartTransaction;
  IBConnection1.ExecuteDirect('CREATE TABLE Table1 (id VARCHAR(255),
name VARCHAR(255));');
  SQLTransaction1.Commit;
  IBConnection1.Close;
  end;

  //Finally switch on connection
  IBConnection1.Connected := True;
  IBConnection1.KeepConnection := True;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Is there a way to create a Firebird embedded database programmatically?

On 3-8-2011 11:50, Michael Van Canneyt wrote:
 
 
 On Wed, 3 Aug 2011, Reinier Olislagers wrote:
 
 When using the Firebird embedded database, it's nice to be able to
 create the database using only FreePascal/Lazarus.
 
 Why do you think this is not possible ? The CreateDB method of
 TIBConnection does exactly that.
 
 I've been using it for years.
 
 Michael.
Thanks Michael, I had just found that out (see my reply to Tony Whyman).

I've added the information to the Lazarus Firebird tutorial on the wiki.

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

Re: [fpc-pascal] Is there a way to create a Firebird embedded database programmatically?

On 3-8-2011 12:05, Tony Whyman wrote:
 Actually, my preference for creating a database in a deployed
 application is to first create it on my local system using isql with
 input from a  script and then to save it using gbak in a portable
 format. The TIBRestoreService is then used to create the database from
 the backup archive when your program fails to detect a local database copy.
 
 The advantages of this approach are that:
 
 - you only ever have one file to distribute
 
 - backup/restore is very robust and quick
 
 - you can readily add Blob data to your archive and distribute it as
 part of the archive
 
 - the initial database is consistent across all deployments
 
 Scripts tend to be more useful when issuing patches to existing
 databases. In this case, simply calling isql from your program and
 pointing it at a patch script can be much easier than embedding SQL
 execution in your program.
 

I understand your approach - and I suspect you have a lot more
experience with Firebird deployments than I.

As for the scripts, yes, I agree that's a good idea for patching, but it
would be nice if you could use SQLDB's SQLScript for that (haven't tried
it yet). This cuts down on the number of external files you have to
distribute.

I needed to create a db in code because I was writing a sample Lazarus
application to show how to use SQLDB with embedded Firebird:
http://lazarus.freepascal.org/index.php/topic,10811.msg74279.html#msg74279

Having people download and run isql just to set up the database seemed
inelegant, error prone and time consuming.
Of course, I could have used IBX components, but then people would have
to download  install those

Thanks for your insights,

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

Re: [fpc-pascal] Is there a way to create a Firebird embedded database programmatically?

On 3-8-2011 12:38, Tony Whyman wrote:
 I understand now what you are doing and would agree that for a simple
 demo, you really do want to create the DB in code. I am thinking more
 about distributing and supporting a fully supported application.
 
 Interesting that I seemed to get so much push-back when I suggested isql
 - I did so as a simple way to distribute a patch (and with an underlying
 assumption that you would install a copy in your application directory
 in order to avoid searching for it). In practice, I don't use isql to
 patch a deployed database but have my own set of units to execute an SQL
 Script using the TIBSQL component. I didn't suggest this because this is
 more than just executing a script, but also includes version control
 tables in the database itself and a configuration file distributed with
 the scripts to tell the updating application which scripts have to be
 applied to get to a specific patch level and so on. Or to put it another
 way, I didn't want to get into a lengthy discussion on how to maintain a
 database in the field. Perhaps I should have just avoided the topic :(

Agreed regarding putting isql in the app directory if you're using it;
that way you get to control what you're executing...

I understand what you're doing too - even about version tables and such.
Just never had to do it in Firebird  FPC yet ;)
As for lengthy discussions, it seems this list seems to have a few - but
I'm not in an argumentative mood ;)

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

Re: RE : [fpc-pascal] Bump: Trouble setting/getting ftVarBytes field data inTBufDataset

On 3-8-2011 12:32, Ludo Brands wrote:
 On 2-8-2011 7:39, Reinier Olislagers wrote:
 I've got trouble finding out how to fill and retrieve data for a 
 ftVarBytes field in a TBufDataset.
   TestDataset.FieldByName('ftVarBytes').Asstring := Teststring;
   writeln('ftVarbytes.AsString: ' + 
 TestDataset.FieldByName('ftVarBytes').AsString);
 
 This is the way to do it. However:
 - FieldDef.Size := 2; You only store 2 characters. 
Oops. Correct.
 - TCustomBufDataset.GetFieldSize doesn't recognise TBinaryField descendants
 and fixes their length arbitrary as 10 bytes... Setting fieldsize to more
 than 10 bytes won't store more than 10 chars. TMemDataset handles this more
 elegantly by raising a SErrFieldTypeNotSupported.
 So the answer is that TBufDataset doesn' support TBinaryField descendants
 correctly.
 
 For test purposes, limit field size to 10 bytes ;)
Thanks for the answer, I will ;)
(I'll have a go at adding this info to the wiki as well)

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

[fpc-pascal] FreeVision usable in a client/server database application?

Hi list,

I'm looking into converting a half-finished small timekeeping/billing
application of mine from .Net to Lazarus/Freepascal. It runs on SQL
Server 2008.

I'm thinking about trying to separate out the database layer (using
something like tiOPF perhaps) from the presentation layer.

I could then write a Lazarus GUI to deal with the data.
(Not even mentioning web interfaces for now, too much to learn ;)

While I'm doing that, I thought about using character mode terminals
(DOS or Linux shell) for quick data entry. I've once looked at
FreeVision (about 10 years ago), but was even more of a
Pascal/programming newbie than now, so couldn't get it to work.

Is it worth looking into FreeVision or could I better forget about it?
If so, I suppose the old FreePascal IDE would be a good example to study?


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

Re: [fpc-pascal] FreeVision usable in a client/server database application?

On 4-8-2011 10:02, Felipe Monteiro de Carvalho wrote:
 Lazarus is very easy to learn, you can read the wiki and now there is
 also a book in english explaining how to use it.
 
Thanks Felipe  Michael!

Yes, I'm already doing stuff in Lazarus (even got the book). I'd be
looking at the FreeVision app in addition to a Lazarus app, using the
same FreePascal business layer units.

But, as Michael said, I could just as well look into creating a web
server module (FastCGI or whatever) using those business layer units
first... This would have the advantage that people using mobile devices
could use it.

Anyway, first going to get back to improvements for my FCL-DB export
unit for XML...

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

Re: [fpc-pascal] FreeVision usable in a client/server database application?

On 4-8-2011 10:50, Graeme Geldenhuys wrote:
 On 3 August 2011 15:53, Reinier Olislagers wrote:
 While I'm doing that, I thought about using character mode terminals
 (DOS or Linux shell) for quick data entry.
 
 As Michael said, it could definitely work. But is there any specific
 reason why you would like to choose a terminal app over a GUI
 (desktop) app? Or even a Web app? Easy deployment with little
 dependencies, end-users are already used to terminal apps etc?
Goeiemore Graeme ( almal),

I think I didn't make myself clear. My intentions were to:
1. Create a business layer using FreePascal
2. Create a Lazarus desktop (maybe smartphone) app that uses the units in 1.
3. To see if I could create a really fast user entry solution, create a
FreeVision app using the units in 1.
4. Create a web application (using e.g. FastCGI) using the units in 1.

With 1 and 2 being compulsory or at least first steps, the rest can
come later.

 If you do use tiOPF, you could always use tiOPF's MGM
 (Model-GUI-Mediator) which makes GUI binding very easy with very
 little code. MGM already supports fpGUI, LCL and VCL. I would
 obviously recommend fpGUI for the job, which gives you lots of
 possibilities to customize the look of your app, and it has very low
 library dependencies... but them I might be a bit bias towards fpGUI.
Biased? I wouldn't think so ;)

I'll certainly keep it under consideration - and if I use tiOPF, I'd
surely use MGM for Lazarus code.

Keeping the application modular will give me the chance to learn new
things (web apps, fpGUI) without messing too much with things I know a
bit about (FreePascal, database access, Lazarus desktop apps).

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

Re: [fpc-pascal] FreeVision usable in a client/server database application?

On 4-8-2011 11:34, Graeme Geldenhuys wrote:
 On 4 August 2011 11:14, Reinier Olislagers wrote:
 My apologies; from your original message I didn't know step 2 was
 compulsory. I thought in step 2 you are considering FreeVision or some
 GUI desktop app.
No problem ;)
 
 Just curious as to why you think a terminal app (FreeVision) would be
 faster for data input than a well designed GUI desktop app?
...
 I'm not saying a terminal app is the wrong way to go (I have many
 terminal apps I still use on a daily basis, even in my Gnome desktop),
 I just wanted to know your thoughts on the subject.

Actually, it's just going to be an experiment to compare the two and see
which one is faster. (And also personal taste, I must admit - I'm still
drawn to using a mouse when entering data on Windows apps, even though I
know I can use the tab/cursor keys etc.)

When I've actually coded something, I might get back to you guys ;)

Also, it obviously is a good test of the modularity of the code, but I
could perform the same test with a web interface.

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

[fpc-pascal] [Semi-OT] How to get remote Git revision number (or last update date) using FPC+git executable

Hi all,

I'm working on expanding the LazUpdater tool, so it can download and
compile an entire working installation of FPCLazarus from scratch on
Windows. (It downloads binutils, if necessary svn executables etc).
My updates so far on:
http://forge.lazarusforum.de/issues/118

Why? Because I'm fed up writing batch scripts on Windows, and I want to
be able to just click on a program and get a running FPC/Lazarus
environment starting from a clean virtual machine ;)

I'm also extending it to use git (on Linux/OSX as well, after getting it
to work on Windows)
I'm using the git mirrors that Graeme Geldenhuys has set up, as
specified in the wiki:
http://wiki.lazarus.freepascal.org/git_mirrors

1. The program checks for the current git revision number (a hex
string in fact) of the local copy. I can do this by issuing
git log -1 --format=%H
and get something like
a74e3740138d0727af73fbd2be10876c5ed8af0b
(Or, I can do it the dirty way by looking at ORIG_HEAD in the .git
directory)

2. Then it should check the remote revision number.
3. If those are different, it does a git pull to get the two in sync.

How do I find out, using FreePascal and a git executable:
1. (Preferably - so I can match behaviour between the git and svn parts
of the program) the remote git revision
2. If the local copy needs updating, i.e. the remote copy is newer.
3. (Bonus question) the date/time of latest update of local copy
4. (Bonus question 2) the date/time of latest update of remote copy

As if it isn't clear enough already, I'm not an experienced git user (I
use mercurial, and even TortoiseHg).
However, having git support in LazUpdater does make downloading updates
an awful lot quicker, so...

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

[fpc-pascal] Re: [Semi-OT] How to get remote Git revision number (or last update date) using FPC+git executable

On 4-8-2011 13:39, Graeme wrote:
 On 4 August 2011 12:58, Reinier Olislagers wrote:

 1. The program checks for the current git revision number (a hex
 string in fact) of the local copy.
 I believe you are referring to the SHA1 value.
I think you believe correctly ;)
 
 How do I find out, using FreePascal and a git executable:
 1. (Preferably - so I can match behaviour between the git and svn parts
 of the program) the remote git revision
 2. If the local copy needs updating, i.e. the remote copy is newer.
 
 Why check for it first, why not just do a 'git pull origin' and be done with 
 it.
I'd like to, but the program as used for svn currently shows current
local revision and only updates if there are differences with a remote
revision.
If possible, I'd like to keep behaviour the same for git...
But I agree, it might be simpler just to do a pull..
 
 But, if you really want to inspect the HEAD revision's SHA1 value of a
 remote repository, you can use the following command:
 
   $ git ls-remote origin HEAD
Exactly what I needed, thanks. I knew it must be possible, but just
couldn't find it.

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

[fpc-pascal] Extended LazUpdater available: cross-platform install of SVN/Git FPC/Lazarus

2011-08-05 Thread Reinier Olislagers

Hi all,

I've extended LazUpdater.
This program allows you to download and compile a subversion or git
version of FreePascal and Lazarus in an easy way, without fiddling with
batch files.

On Windows: it's meant to be able to do this without existing FPC
compiler, binutils (make.exe etc), svn client or unzip program. If you
do have a compiler installed, you can specify that LazUpdater uses that.
The bare metal install (without unzip,svn,compiler) on Windows needs
to be tested further.
I'm using it on Windows with an existing compiler and a git client;
install from scratch  further updating seems to work fine.

On Linux/OSX: this version needs to be tested.

I'm not the original author of the program; I've based my version on the
latest published version of LazUpdater and submitted my version as a
feature request.
So you can download it from:
[url]http://forge.lazarusforum.de/issues/118[/url]
(See the latest post for my most recent version)

If the original author doesn't respond to this feature request, it might
be a good idea to include it in Lazarus CCR

I'd appreciate test results, improvement requests and other feedback.

Thanks,
Reinier

PS: Yes, I know I mentioned I'd get back on my FCL-DB XML export, but
had to get a working FPC dev version, so I finished this first...
excuses, I know ;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB ready forinclusion, issue 19790 - includes Delphi Clientdataset

2011-08-05 Thread Reinier Olislagers

On 28-7-2011 14:36, Ludo Brands wrote:
 - bcd: invalid field type
 Ok, what field type do we need ;) I'll wait for your further 
 investigations.
 
 Line 2087 becomes:
 
   ftBCD: //WIDTH=precision, DECIMALS=scale
snip The sqldb mysql implementation doesn't distinguish text from
blob. Nothing
 that can be done about in the export.
 
 Ludo
 

Ludo  the rest,

After my recent adventures with LazUpdater, back to the XML export.

I've written new tests with more data types that at least produce test
output now.

My revision 13 has fixes for the Delphi Clientdataset issues, so
everyone is welcome to test if you want:
https://bitbucket.org/reiniero/fpc_laz_patch_playground/overview

You might want to just use fpxmlxsdexport.pp and use the existing
XMLXSDExportTest code to compare current output with old test output...

I'll be continuing with:
- adding as many small fixes as I can
- streamlining/refactoring the code
- testing ADO.Net, Excel  Access export formats
- preparing patch for (hopefully) inclusion in FPC 2.6 series

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

Re: RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB readyforinclusion, issue 19790 - includes Delphi Clientdataset

2011-08-06 Thread Reinier Olislagers

On 6-8-2011 19:28, Ludo Brands wrote:
 After my recent adventures with LazUpdater, back to the XML export.

 I've written new tests with more data types that at least 
 produce test output now.

 
 Problems so far:
 
 TClientDataSet:
 - ftWideString has zero length by default: Delphi 6 returns invalid
 parameter for WIDTH=0 when opening the tclientdataset. Added FieldDef.Size
 := 255; for ftWideString field definition; 

Ok, should be easy.
 
 -Access 2000:
 - access doesn't accept the empty value for ftAutoInc. TAutoIncField is read
 only and BufDataSet doesn't do anything with autoincrement fields. Better
 drop it from the test.
Ok, but it should recognize its own version of an autoinc (autonumber I
think it's called. I'll have a look.)
 - access falls over the guid not being a real guid. It aborts reading the
 remainder of the line because dataset not in edit/insert mode anymore ...
 Guid has to be a string of the form {9F5FBC24-EFE2-4f90-B498-EC0FB7D47D15}
Yep.
 - ftWideString creates sometimes non ascii characters at the end. This is
 not the case for TClientDataSet. Still looking in that one; 
Ok.
 - the year 0001 is imported as 2001. Also manually you can't enter the year
 0001 in access 2002. It always becomes 2001. 
Yeah, I had complaints with Excel as well ;)
 
 Ludo

Thanks Ludo,

I'll put them on my list...

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

[fpc-pascal] Assigning value to ftVariant datatype varbytes - still stuck

2011-08-07 Thread Reinier Olislagers

Hi list,

Free Pascal Compiler version 2.5.1 [2011/08/04] for i386

While improving my fcl-db XML export code, I'm testing with ftVariant
types in a bufdataset:
  FieldDef := FTestDataset.FieldDefs.AddFieldDef;
  FieldDef.Name := 'ftVariant';
  FieldDef.DataType := ftVariant;

This works:
  TestString:='The answer to life, the universe, and everything';
  FTestDataset.Append;
  FTestDataSet.FieldByName('ftVarBytes').AsString:=TestString;
  FTestDataSet.FieldByName('ftVarBytes').SetData(TempPChar);
  //FTestDataSet.FieldByName('ftVariant').AsString:=TestString;
  FTestDataset.Post;

However, I can't assign values to ftVariant, whatever combination I try.
The strange thing is that I get an access violation when printing the
fields' contents in a loop, and it happens when getting the value for
ftVarBytes.
Would it have to do with the ASCII NULL delimiter Ludo Brands reported
in http://bugs.freepascal.org/view.php?id=19922

This doesn't work:
  //FTestDataSet.FieldByName('ftVarBytes').AsString:=TestString;
  FTestDataSet.FieldByName('ftVarBytes').SetData(TempPChar);
  FTestDataSet.FieldByName('ftVariant').AsString:=TestString;

nor this:
  //FTestDataSet.FieldByName('ftVarBytes').AsString:=TestString;
  //FTestDataSet.FieldByName('ftVarBytes').SetData(TempPChar);
  FTestDataSet.FieldByName('ftVariant').AsString:=TestString;

nor this:
  FTestDataSet.FieldByName('ftVarBytes').AsString:=TestString;
  FTestDataSet.FieldByName('ftVarBytes').SetData(TempPChar);
  FTestDataSet.FieldByName('ftVariant').AsString:=TestString;

How can I properly assign values to ftVarBytes and ftVariant and
retrieve them?
I know I asked before for ftVarBytes; I just use .AsString:='bla', but
obviously it doesn't work.

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

Re: RE : [fpc-pascal] Assigning value to ftVariant datatype varbytes -still stuck

2011-08-07 Thread Reinier Olislagers

On 7-8-2011 18:28, Ludo Brands wrote:
   FTestDataSet.FieldByName('ftVarBytes').AsString:=TestString;
   FTestDataSet.FieldByName('ftVariant').AsString:=TestString;
 
 Same problem as before: TBufDataset doesn't support correctly ftVarBytes and
 ftVariant and doesn't raise an SErrFieldTypeNotSupported like TMemDataset is
 doing.
 Look at TCustomBufDataset.GetFieldSize and you'll see that data length for
 ftVarBytes and ftVariant is arbitrarely set at 10. Compare this with
 TMemDataset.MDSGetBufferSize.
 
 Ludo
 
I'm afraid you'll have to spell it out for me; I now set the size
explicitly:
  FieldDef.Name := 'ftVariant';
  FieldDef.DataType := ftVariant;
  FieldDef.Size:=NumberOfBytes;

even I do this:
  FTestDataset.Fieldbyname('ftTypedBinary').Asstring :=
PChar(AnsiLeftStr(TestString,7)+#0);

FTestDataSet.FieldByName('ftVarBytes').AsString:=PChar(AnsiLeftStr(TestString,7)+#0);

FTestDataSet.FieldByName('ftVariant').AsString:=PChar(AnsiLeftStr(TestString,7)+#0);


I still get the errors.


As for patching TBufDataset: ftVariant and ftVarbytes seem like
blob-type fields to me, so:
in TCustomBufDataset.GetFieldSize
  case FieldDef.DataType of
...
ftBlob,
  ftMemo,
  ftGraphic,
  ftFmtMemo,
  ftParadoxOle,
  ftDBaseOle,
  ftTypedBinary,
  ftOraBlob,
  ftOraClob,
  ftWideMemo : result := sizeof(TBufBlobField)
  else Result := 10
  end;

would it make sense to add ftVariant, ftVarBytes to the list with ftBlob
etc?
(I'm going to try anyway, see what happens ;)

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

Re: RE : RE : [fpc-pascal] Assigning value to ftVariant datatype varbytes-still stuck

2011-08-07 Thread Reinier Olislagers

On 7-8-2011 19:50, Ludo Brands wrote:
 Same problem as before: TBufDataset doesn't support correctly 
 ftVarBytes and ftVariant and doesn't raise an 
 SErrFieldTypeNotSupported like TMemDataset is doing. Look at 
 TCustomBufDataset.GetFieldSize and you'll see that data length for 
 ftVarBytes and ftVariant is arbitrarely set at 10. Compare 
 this with 
 TMemDataset.MDSGetBufferSize.

 Ludo

 I'm afraid you'll have to spell it out for me;
 
 
 TBufDataset doesn't support ftVarBytes and ftVariant. Variants are complex
 objects and aren't stored by just copying bytes. Don't use them with
 TBufDataset.
 
 Ludo
Thanks, that's very clear - I'll get rid of them in the tests ;)

I might upload a patch to give an error instead of the fixed size - that
might possibly lie within my abilities...

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

Re: RE : RE : [fpc-pascal] Assigning value to ftVariant datatype varbytes-still stuck

2011-08-08 Thread Reinier Olislagers

On 7-8-2011 19:50, Ludo Brands wrote:
 TBufDataset doesn't support ftVarBytes and ftVariant. Variants are complex
 objects and aren't stored by just copying bytes. Don't use them with
 TBufDataset.
 
 Ludo
 
... cause they have some kind of structure that describes what kind of
data the variable/field actually contains and a pointer to memory
containing the actual data? Just guessing...

Anyway, once again thanks a lot for the help, I've updated my test code
and posted
http://bugs.freepascal.org/view.php?id=19930

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

[fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]

2011-08-08 Thread Reinier Olislagers

On 6-8-2011 15:28, Causal Lists wrote:
 I finally managed to get Intel Mac OS X cross-compilation (from Linux)
 working well so I thought I'd document what I did for the benefit of
 others because the info in the wiki is wildly out of date.
 
 I'll update the wiki (if I can) to point to this message.
 
snip
 Cheers, Bruce.

Bruce,

Thanks for your post. I've taken the liberty to start the wiki page as
I'm trying it out.

See
http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux

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

Re: [fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]

My pleasure - though I haven't finished yet  may run into things.

It seems you're setting up a 32 bit environment. Both my Linux (Debian)
and OSX machine are 64 bit - don't know if this will work.

Anyway, I'll get back on the list if I have problems...

Reinier
On 9-8-2011 10:28, Bruce Tulloch wrote:
 Brilliant, thanks Reinier, it looks good. Cheers, Bruce.
 
 On 08/08/11 23:03, Reinier Olislagers wrote:
 http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Suggested fix for problem make install trunk FPC: trailing backslash in directory specification

Just tried updating FPC sources and compiling (32 bit) on Windows Vista
x64 and got an error and a solution.

===
Summary: I get an error when I do something like:
make.exe install INSTALL_PREFIX=C:\Development\Fpc\
PP=C:\Development\Fpc\bin\i386-win32\fpc.exe
but when I leave out the trailing backslash in the INSTALL_PREFIX:
make.exe install INSTALL_PREFIX=C:\Development\Fpc
PP=C:\Development\Fpc\bin\i386-win32\fpc.exe
it works.
===
Would it be possible to adapt fpmake to accept a directory with a
trailing directory separator? Or is the issue in make or somewhere else?
It seems more natural to me to specify a directory with such as
separator at the end.

I had a look at the FreePascal Programmer's manual, Appendix E Using
FPCMake (same as fpmake?); it describes the directories, and gives
examples without trailing separators, but does not say anything about
them being forbidden...

Thanks,
Reinier
===
Details:
On recent SVN trunk 18151 (using LazUpdater/git though; git commit
71614930203ea050198f).
Got an error on make install:
C:\lazarus\fpc\2.5.1\bin\i386-win32\make.exe install
INSTALL_PREFIX=C:\Development\Fpc\
PP=C:\Development\Fpc\bin\i386-win32\fpc.exe
. a lot of activity
C:/lazarus/fpc/2.5.1/bin/i386-win32/make.exe -C fcl-base distinstall
make.exe[4]: Entering directory
`C:/Development/Fpc/Source/packages/fcl-base'
C:/Development/Fpc/Source/compiler/ppc386.exe fpmake.pp -n
-FuC:/Development/Fpc/Source/rtl/units/i386-win32
-FuC:/Development/Fpc/Source/packages/hash/units/i386-win32
-FuC:/Development/Fpc/Source/packages/paszlib/units/i386-win32
-FuC:/Development/Fpc/Source/packages/fcl-process/units/i386-win32
-FuC:/Development/Fpc/Source/packages/fpmkunit/units/i386-win32
.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32
--cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-FuC:/Development/Fpc/Source/rtl/units/i386-win32 -o
-FuC:/Development/Fpc/Source/packages/hash/units/i386-win32 -o
-FuC:/Development/Fpc/Source/packages/paszlib/units/i386-win32 -o
-FuC:/Development/Fpc/Source/packages/fcl-process/units/i386-win32 -o
-FuC:/Development/Fpc/Source/packages/fpmkunit/units/i386-win32 -o -FE.
-o -FUunits/i386-win32 -o -di386 -o -dRELEASE
--compiler=C:/Development/Fpc/Source/compiler/ppc386.exe
--prefix=C:\Development\Fpc\
--unitinstalldir=C:\Development\Fpc\/units/i386-win32/fcl-base -ie
The installer encountered the following error:
Failed to create directory C:\Development\Fpc \bin\
make.exe[4]: *** [distinstall] Error 1
make.exe[4]: Leaving directory `C:/Development/Fpc/Source/packages/fcl-base'

So it seems there's an error with fpmake trying to create
c:\development\fpc \bin\ which should probably be c:\development\fpc\bin

Tried to do it again:
cd /d c:\development\fpc
make clean
del /s *.ppu
del /s *.o
= fpmake.o is deleted
C:\lazarus\fpc\2.5.1\bin\i386-win32\make.exe install
INSTALL_PREFIX=C:\Development\Fpc\
PP=C:\Development\Fpc\bin\i386-win32\fpc.exe
I still get the same error, but when I remove the trailing \ from the
INSTALL_PREFIX directory and specify
C:\lazarus\fpc\2.5.1\bin\i386-win32\make.exe install
INSTALL_PREFIX=C:\Development\Fpc
PP=C:\Development\Fpc\bin\i386-win32\fpc.exe
... it works.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 12:17, Ludo Brands wrote:
 I created a patch for ftVariant, ftBytes and ftVarBytes support as well as a
 check for supported types and attached it to the issue. Feel free to extend
 your tests with it ;) 
Thanks, I'll have a look.

 
 Also a change in fpXMLXSDExport line 388:
 
   Fanode := Foutputdoc.Createtextnode(Utf8decode(EF.Field.AsString));
 
 Instead of 
 
   Fanode :=
 Foutputdoc.Createtextnode(Encodestringbase64(EF.Field.AsString));
 
 The format was defined as string before.
That doesn't match my current version.
Maybe I already made the change:
I've changed ftVariant to base64 encoding (i.e. treat is as binary) in
commit 19:
https://bitbucket.org/reiniero/fpc_laz_patch_playground/changeset/a78b5a5de22e

Can you tell me what field type it is? I'm guessing ftVariant...

You might also be interested in the newest version on Bitbucket. The
last couple of days I've added some fixes to block invalid date ranges
for Access/Excel, as well as the order of output in Delphi clientdataset...
The tests are crashing again now, so I might be back with some newbie
questions.

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

[fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]

On 9-8-2011 12:21, Torsten Bonde Christiansen wrote:
 On 2011-08-09 10:46, Reinier Olislagers wrote:
 My pleasure - though I haven't finished yet  may run into things.

 It seems you're setting up a 32 bit environment. Both my Linux (Debian)
 and OSX machine are 64 bit - don't know if this will work.
 I've just tried to follow the guide, but seem to run into the same
 problem as many other apparently also do:
 
 At global scope:
 cc1plus: warning: unrecognized command line option -Wno-long-doubl
 
 From what I can read on the web this is somehow related to 64-bit vs.
 32-bit crosscompile, but I'm not sure how to solve it.
 
 The following resources are an interesting read, but didn't really seem
 to get me any further.
 http://code.google.com/p/iphone-dev/issues/detail?id=212#makechanges
 http://code.google.com/p/iphone-dev/issues/detail?id=14
 
 Neither of the CFLAGS/LDFLAGS options helped me, perhaps someone have
 done this succesfully on a Ubuntu 10.04 x86_64 like my system.
 
I've put this on the wiki, don't know if it helps
On 64 bit Linux environments, fpc mailing list users have problems.
Perhaps this
[http://stackoverflow.com/questions/3024255/building-odcctools-in-a-64-bit-os
StackOverflow question and answer] can help: in the configure step,
you'd apparently need to set
CC=gcc -m32 CXX=g++ -m32 ./configure blah blah blah
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 13:34, Ludo Brands wrote:
 I've changed ftVariant to base64 encoding (i.e. treat is as 
 binary) in commit 19: 
 
 Mmm... That's taking risks and requires quite some testing with the
 different host applications. When transferring data as strings, we know that
 apps do the string to integer/date/whatever transformation. But when you
 transfer them as binary, I'm afraid that they will be imported as is ie. no
 transformation. 
Yes, it is taking a risk. However, if I understand correctly, a variant
can contain an integer, string, anything really. Couldn't it also
contain blob or binary data?
Encoding it as base64 seems safer to me than just blindly writing it out
as a string.

(Don't know if ftVariant fields are ever used in real world databases
though)

I really don't care myself which way we go - I'll happily defer to your
expertise.

Just say the word  I'll change them all back to string ;)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 12:17, Ludo Brands wrote:
 I created a patch for ftVariant, ftBytes and ftVarBytes support as well as a
 check for supported types and attached it to the issue. Feel free to extend
 your tests with it ;) 
Applied patch in fpc source, make clean, make all make install for FPC,
make for Lazarus, rescan fpc source directory, recompile test project.

Still get access violations.
(ftVariant, ftVarbytes set to size 10, then assigning all kinds of
strings to it using .AsString)

Could you have a look at the test code now - I might still be doing
something really stupid.
The commit where the files are readded, you can download the test code
there:
https://bitbucket.org/reiniero/fpc_laz_patch_playground/changeset/6be7ed0edb4b

(It seems getting the value from the ftVariant field gives an access
violation, but I'm not sure)

Thanks,
Reinier



Some output from the test:
*** Starting to fill row 1
snip
Field: ftString_256 has value Douglas Adams less than:  greater than
 tab:  crlf:
åœ‹ç¼ºç•Œå¹¿æ¬ å»£ç•Œç•Œä¸œç¼º. Haddock drinks rosÃ© (ros, e accent
aigu), Ð²Ð¾Ð´ÐºÐ° (wodka cyrillic) and Î¿Ï�Î¶Î¿ (ouzo Greek) but prefers
Loch Lomond whiskey.
Field: ftTime has value 23:59:59
Field: ftTypedBinary has value
Field: ftVariant: error retrieving value:
EAccessViolation; detailed error message: Access violation
Field: ftVarBytes has value Douglas Ad
snip
EAccessViolation; detailed error message: Access violat Time:00.027 N:8
E:7 F:0 I:0
  Ttestxmlxsdexport1 Time:00.027 N:8 E:7 F:0 I:0
00.003  TestXSDExport_Access_NoXSD_Decimal  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.003  TestXSDExport_Access_NoXSD_NoDecimal  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.004  TestXSDExport_Access_XSD_Decimal  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.004  TestXSDExport_Access_XSD_NoDecimal  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.003  TestXSDExport_ADONET_NoXSD  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.003  TestXSDExport_ADONET_XSD  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.003  TestXSDExport_DelphiClientDataset  Error: EAccessViolation
  Exception:   Access violation
  Source unit:
  Method name:
  Line number: 574
00.004  TestXSDExport_Excel

Number of run tests: 8
Number of errors:7
Number of failures:  0

List of errors:
  Error:
Message:
Ttestxmlxsdexport1.TestXSDExport_Access_NoXSD_Decimal: Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:
Ttestxmlxsdexport1.TestXSDExport_Access_NoXSD_NoDecimal: Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:
Ttestxmlxsdexport1.TestXSDExport_Access_XSD_Decimal: Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:
Ttestxmlxsdexport1.TestXSDExport_Access_XSD_NoDecimal: Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:   Ttestxmlxsdexport1.TestXSDExport_ADONET_NoXSD:
Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:   Ttestxmlxsdexport1.TestXSDExport_ADONET_XSD:
Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:

  Error:
Message:
Ttestxmlxsdexport1.TestXSDExport_DelphiClientDataset: Access violation
Exception class:   EAccessViolation
Exception message: Access violation
Source unitname:
Line number:   574
Failed methodname:
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]

On 9-8-2011 14:29, Torsten Bonde Christiansen wrote:
 On 2011-08-09 12:59, Reinier Olislagers wrote:
 On 9-8-2011 12:21, Torsten Bonde Christiansen wrote:
 On 2011-08-09 10:46, Reinier Olislagers wrote:
 I've put this on the wiki, don't know if it helps
 On 64 bit Linux environments, fpc mailing list users have problems.
 Perhaps this
 [http://stackoverflow.com/questions/3024255/building-odcctools-in-a-64-bit-os

 StackOverflow question and answer] can help: in the configure step,
 you'd apparently need to set
 CC=gcc -m32 CXX=g++ -m32 ./configure blah blah blah
 You may also put a note that there exists a launchpad ppa for ubuntu,
 then you don't need to compile the binutils yourself (which evidently
 can be a pain in the ...).
 
 https://launchpad.net/~flosoft/+archive/cross-apple
 https://launchpad.net/%7Eflosoft/+archive/cross-apple
 
 Btw. I got the compilation working on a Ubuntu 11.04 64-bit (within a
 VM), but since my main desktop still runs 10.04 I cannot use the ppa.
 
Thanks for the hints, but feel free to write it up yourself; I use
Debian, not Ubuntu  haven't tried it...

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

Re: RE : [fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 16:42, Ludo Brands wrote:
 
 Downloaded the code and it raises an SUnsupportedFieldType when
 creating the ftAutoInc field. That is OK since I didn't include
 ftAutoinc in the supported list for TBufDataset. If you are not
 getting this error, then the patch and/or install didn't work.
I feared as much. Totally strange, as I tried my patch for SQLExport as
well and that did work fine.
I'll clean up everything  try again...

 Line 547 is where FillTestData is called. Not very usefull.
I agree. Seems like the test setup  teardown should be a test of their
own for TBufDataset :(
 
 I do get a segfault in the last test when assigning to
 ftWideString256. When tracing the code it crashes when moving the
 size+1 chracters to the database. This fixed length moving is
 fundamentally wrong. The string is only 20 or so chars long and
 TCustomBufDataset.SetFieldData tries to do a move of the full 514
 bytes (256+1)*2. This asking for trouble. The source of the data is
 here a temporary WideString created by casting a string, so probably
 on the heap. Reading 514 bytes when only 40 odd where allocated is
 not always working
 
 I'll try to fix that one also.
I'd appreciate that a lot!


Thanks a lot for the help,
Reinier
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 17:03, waldo kitty wrote:
 On 8/9/2011 10:42, Ludo Brands wrote:
Exception:   Access violation
Source unit:
Method name:
Line number: 574
  00.003  TestXSDExport_Access_NoXSD_NoDecimal  Error:

 Line 547 is where FillTestData is called. Not very usefull.
 
 line 547 or 574? the error report is 574 ;)
waldo, thanks for trying to help, unfortunately, I think he meant 574 ;)

FillTestData is called in 573; the next line is the end; of the Setup
procedure

I probably will need to write a test case for TBufdataset if that hasn't
already been done - I know there's some changes going on in the fcl-db
test set...

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

[fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

On 9-8-2011 16:42, Ludo Brands wrote:
 Applied patch in fpc source, make clean, make all make install for 
 FPC, make for Lazarus, rescan fpc source directory, recompile test 
 project.
snip
 
 Downloaded the code and it raises an SUnsupportedFieldType when 
 creating the ftAutoInc field. That is OK since I didn't include 
 ftAutoinc in the supported list for TBufDataset. If you are not 
 getting this error, then the patch and/or install didn't work.
Oops, sorry, you're right. Your cygwin diffs don't seem to agree with
(the way I use) fpc patch; I got it to apply only the first part of the
patch...
Now it works.

Using fpc diff -u --minimal oldfile newfile  patch.diff does work for
me with patch -p0  patch.diff
I suppose you use cygwin patch to apply the patches?

Very glad the test is working again, now I can get back to improving the
export code!

Thanks a million!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : [fpc-pascal] Re: RE : Re: RE : RE : RE : Assigning value to ftVariant datatype varbytes-still stuck

2011-08-10 Thread Reinier Olislagers

On 10-8-2011 9:49, Ludo Brands wrote:
 Oops, sorry, you're right. Your cygwin diffs don't seem to 
 agree with (the way I use) fpc patch; I got it to apply only 
 the first part of the patch... Now it works.

 
 The patches I upload to bugs.freepascal are made with svn diff. The ones I
 sent you earlier were made with cygwin diff since the code wasn't versioned
 with svn.
 I use patch -p0  patch.diff.
 The cygwin diff I sent earlier: I forgot to mention the diff -u parameter,
 hence the different format. Sorry, 
Thanks, no problem.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value to ftVariantdatatype varbytes-still stuck

2011-08-10 Thread Reinier Olislagers

On 10-8-2011 11:51, Ludo Brands wrote:
 I do get a segfault in the last test when assigning to 
 ftWideString256. When tracing the code it crashes when moving the
 size+1 chracters to the database. This fixed length moving is
 fundamentally wrong. The string is only 20 or so chars long and 
 TCustomBufDataset.SetFieldData tries to do a move of the full 514 
 bytes (256+1)*2. This asking for trouble. The source of the data is 
 here a temporary WideString created by casting a string, so 
 probably 
 on the heap. Reading 514 bytes when only 40 odd where 
 allocated is not 
 always working

 I'll try to fix that one also.
 I'd appreciate that a lot!

 
 Uploaded a patch to http://bugs.freepascal.org/view.php?id=19930. Initially,
 because of the crash, I wanted to submit another bug report but the more I
 dig into this, the more I feel the definition of SetFieldData/GetFieldData
 without a length/size parameter and strings passed as pchar is causing all
 kind of problems:
 1) TStringField.SetAsString copies the string to a buffer with size
 dsMaxStringSize so that datasets that don't figure out the original length
 of the string can simply copy the full Field.TDatasize (TBufDataset, TDbf,
 TMemDataset,...). TWideStringField.SetAsString didn't which caused the crash
 when the string is shorter than Field.Size. TCustomSqliteDataset uses a
 StrNew(PChar(Buffer)); to get the length of the string but fails sometimes
 (see 4).
 2) dsMaxStringSize isn't enforced for TStringField. Defining a Field.size 
 dsMaxStringSize causes a crash in TStringField.SetAsString. I haven't raised
 an issue on this, yet.
 3) some of the speed advantage of memory based datasets is offset by moving
 full Field.Tdatasize bytes in both set and get fielddata
 4) pascal strings can contain #0 characters in the string. When converting
 to pchar part of these strings is lost. 
 
 What I propose is:
 1 to create overloaded versions of SetFieldData and GetFieldData that
 include a length parameter, to change TStringField.SetAsString and
 TWideStringField.SetAsWideString to use these versions and to migrate the
 different datasets to use these new versions. This way existing (user) code
 using SetFieldData/GetFieldData will still work (and the user still being
 responsible for buffer overruns...) and datasets can correctly save and
 retrieve strings while improving performance. 
 2 change the bufdataset internal storage for ftstring and ftwidestring
 fields to include the string length so that stored strings can be retrieved
 in full when containing #0 characters and without having to copy
 systematically datasize bytes. However this will introduce an incompatible
 binary format for TFpcBinaryDatapacketReader. Having a second FpcBinaryIdent
 would allow for both formats to co-habitate. 
 
 If need be the discussion can be moved to fpc-devel.
 
 Ludo
 
 PS: no misunderstanding. I'm volunteering to make these changes;)
 
I'd be happy to help with testing at least!
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] XMLXSDExport: line ending in Excel cells

Hi list,

I've been refactoring the XMLXSDExport code and am now busy fixing some
bugs based on testing.

I'd appreciate your input.
In Excel text fields, you can generate a line ending by pressing
Alt-Enter. On export to XML this is written as #10;
So far so good.

If exporting dataset text (memo, string, ..) data to Excel XML text
fields, which characters do I need to convert to #10;
1. Carriage return + linefeed (#13#10)
2. Linefeed (#10)
3. All occurrences of #10 and #13#10
4. Value of LineEnding constant

My reasoning: it shouldn't matter on which platform you're accessing a
database, so we should treat both #13#10 and #10 equally, so I'd choose
option 3.

Your thoughts?

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

[fpc-pascal] Re: XMLXSDExport: line ending in Excel cells

On 12-8-2011 12:32, Reinier Olislagers wrote:
 In Excel text fields, you can generate a line ending by pressing
 Alt-Enter. On export to XML this is written as #10;
 So far so good.
 
 If exporting dataset text (memo, string, ..) data to Excel XML text
 fields, which characters do I need to convert to #10;
 1. Carriage return + linefeed (#13#10)
 2. Linefeed (#10)
 3. All occurrences of #10 and #13#10
 4. Value of LineEnding constant
 
Well, seems I had to drink more coffee.

#10; is line feed encoded in XML. So it doesn't matter, I can just
strip out the #13s - still working on getting those pesky Alt-enters
correctly imported into Excel but it's probably something very stupid...


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

[fpc-pascal] Explicit encoding of LF in XML

All,

Looking at multiline support of text/string cells for export to Excel
XML format.

My code, such as:
TDOMElement(FieldNode).SetAttribute('ss:Type', 'String');
FNode :=
Foutputdoc.CreateTextNode(LeftStr(UTF8Decode(EF.Field.AsString), 32767));
writes out a cell like:

CellData ss:Type=StringFirst line.
Second line/Data/Cell
(Separated by CR LF - changing it to only LF with a hex editor doesn't help)

Excel needs an encoded LF:
CellData ss:Type=StringFirst line.#10;Second line/Data/Cell

How can I produce that?

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

Re: RE : [fpc-pascal] Explicit encoding of LF in XML

On 12-8-2011 16:31, Ludo Brands wrote:
 Excel needs an encoded LF:
 CellData ss:Type=StringFirst line.#10;Second line/Data/Cell

 How can I produce that?

 
 Uses strutils;
 ...
 Foutputdoc.CreateTextNode(LeftStr(UTF8Decode(AnsiReplaceStr(AnsiReplaceStr(E
 F.Field.AsString,#10,'#10;'),#13,'')),32767));
 
 Ludo
 
That's what I thought at first, too ;)

But the  gets encoded again by the XML unit and you get:
amp;#10;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] ftGuid displaytext output

2011-08-13 Thread Reinier Olislagers

While trying to export dataset data to XML, I use this for ftGUID fields:

FNode :=
Foutputdoc.CreateTextNode(Utf8decode(GUIDToString(TGuid(EF.Field.Value;

This works on Windows 32 and shows a hex representation of the GUID, like
{---C000-0046}

On Linux x64, I get: Illegal type conversion: Variant to TGuid

I then tried something like:
FNode :=
Foutputdoc.CreateTextNode(Utf8decode(EF.Field.DisplayText));
However, this just output the GUID as a number (e.g. 42)

1. Is the conversion error I got due to the use of a 64 bit compiler?
How can I fix it? (e.g. use EF.Field.AsLargeint - but that has 64 bits,
not the the 128 bits present in a GUID)

2. Is the behaviour of .DisplayText correct for ftGUID variables -
shouldn't it use GUIDToString to output the hex value?

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

Re: RE : [fpc-pascal] ftGuid displaytext output

2011-08-14 Thread Reinier Olislagers

On 13-8-2011 13:04, Ludo Brands wrote:
 TGuidField stores guid in the string format (GuidToString).
 EF.Field.AsString should give you the correct string value.
 
 Ludo
Thanks, Ludo.

I think I was using AsString at first.

I'll have a further look; maybe I'm putting in rubbish; I'll probably
have to assign the value to the field with something like GUIDToString...

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

Re: RE : RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigningvalue toftVariantdatatype varbytes-still stuck

2011-08-14 Thread Reinier Olislagers

On 14-8-2011 16:30, Ludo Brands wrote:
 In our previous episode, Ludo Brands said:
 Sorry mate. No reaction. Everybody seems to be happy with 
 the current 
 implementation. Under these circumstances, I'm not going to 
 spend any 
 time on creating a patch that makes a, minor, change to the 
 interface 
 when other, less intrusive, patches for fcl-db are sitting 
 in mantis 
 for months/years without being merged.

 Your remarks really hurt my motivation to look at those 
 bugreports at all. That and the fact that I spent a holiday 
 week closing quite some goes unnoticed.

 
 Marco, all my excuses if you felt my message suggested I was pointing in
 your direction. I wasn't. I'm a little surprised by you taking this
 personnally since most of the patches I personnaly submitted and that you
 dealt with where comitted quickly. And, you don't have to believe me, but I
 did notice your great efforts last weeks working and catching up on older
 and new issues. 
 What did trigger my reaction are examples like this:
 http://bugs.freepascal.org/view.php?id=19902 a patch contributed recently to
 implement ODBC transactions while this patch
 http://bugs.freepascal.org/view.php?id=14944 was submitted in 2009 for the
 same but never committed. 
 
Marco  Ludo,

Just wanted to say thanks for answering my questions, helping with
testing and coding of my export code, the bufdataset patch and, Marco,
closing a lot of patches (yes, I noticed, too).
It has really helped improve my knowledge and I think improved the XML
export code as well, which is almost (warning: developer's estimate!)
ready for testing and then submission as a new patch for FPC.

I noticed the ODBC transaction patches too and it seems a shame.
However, it does take experienced people with an overview of the code to
review  commit patches, so I can understand these things do happen -
nobody is getting paid to work on FPC I suppose.

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

Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset

On 28-7-2011 9:24, michael.vancann...@wisa.be wrote:
 On Thu, 28 Jul 2011, Reinier Olislagers wrote:
 On 27-7-2011 20:52, michael.vancann...@wisa.be wrote:
 Code like

   ftWideString: //fixed length or at least max length string
   begin
 TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
 TDOMElement(ColumnNode).SetAttribute('WIDTH',
  
 UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
   end;
Regarding the snippet above: for Unicode-enabled Delphis, using
Clientdataset savetofile as UTF8-based XML (dfXMLUTF8), what do I need
to output for a ftString:
- Field.Size (number of characters in string)
- Field.DataSize (number of bytes in string field)

As Michael indicated, it probably is Field.Size, but I'd like to have
that confirmed. (Can't seem to find any documentation on ClientDataset
XML format on Embarcadero's Delphi help at
http://docwiki.embarcadero.com/VCL/en/DBClient.TCustomClientDataSet.SaveToFile)

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

Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset

On 15-8-2011 11:25, Michael Van Canneyt wrote:
 I created a dataset with 2 fields. A ftString field with size 33, and a
 ftWideString field with size 44.
 
 Based on the following output from SaveToFile, I would say that you'll
 need to put Size*SizeOf(CharTypeUsedInfield), which should be DataSize.
 
 Michael.
 
 ?xml version=1.0 encoding=UTF-8 standalone=yes? DATAPACKET
 Version=2.0
 METADATA
 FIELDS
 FIELD attrname=stringveld fieldtype=string WIDTH=33/
 FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/
 /FIELDS
 PARAMS/
 /METADATA
 ROWDATA
 /ROWDATA
 /DATAPACKET

Thanks, Michael,

Set to .DataSize...

I'm ready for uploading this for inclusion in FPC, I can open a
bugreport and attach the patch if you're happy with that.

Fixes/changes since first commit to FPC
===
1. Code cleanup to make it more modular and maintainable: split out code
per export format and moved class-level variables there.
2. Delphi Clientdataset export now works thanks to FPC XML fixes by
Sergei Gorelkin and tests/improvements by Ludo Brands.
3. Extended test coverage with all field types in a BufDataset so tests
cover more.
4. Fixes for invalid data: Access, ADO.Net, Excel date limits respected
(generate NULL or text fields respectively)
5. Decimalseparator setting in Access export should now work.
6. Variants are saved as blobs, not strings, because of their variable
nature.
7. Fix for proper export of null values to Access NULL values (instead
of empty/default values).
8. Changed description of class from Unicode XML file with XSD to
Unicode XML file to better match unit function.
9. Compiled on Windows x86, Linux x64 without warnings using fpc -vweh
fpxmlxsdexport.pp. Compared output.
- ftVarBytes gave different output on Windows  Linux. Disregarded as I
don't fill these fields in the test because of bug 19930
10. Added option KeepFilesAfterTest = true in xmlxsdexporttestcase1; can
be switched to false to delete export test files after use.
11. Lower-cased source code file names.
12. Fixes for Linux invalid date export to Excel by using clocale and
specifying dateformat (restored at end of export).
13 .Datasize instead of .Size for string/widestring Delphi fields.

Regards,
Reinier

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

Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset

On 15-8-2011 11:44, Reinier Olislagers wrote:
 On 15-8-2011 11:25, Michael Van Canneyt wrote:
 I created a dataset with 2 fields. A ftString field with size 33, and a
 ftWideString field with size 44.

 Based on the following output from SaveToFile, I would say that you'll
 need to put Size*SizeOf(CharTypeUsedInfield), which should be DataSize.

 Michael.

 ?xml version=1.0 encoding=UTF-8 standalone=yes? DATAPACKET
 Version=2.0
 METADATA
 FIELDS
 FIELD attrname=stringveld fieldtype=string WIDTH=33/
 FIELD attrname=WideStringVeld fieldtype=string.uni WIDTH=44/
 /FIELDS
 PARAMS/
 /METADATA
 ROWDATA
 /ROWDATA
 /DATAPACKET
 
 Thanks, Michael,
 
 Set to .DataSize...
 
 I'm ready for uploading this for inclusion in FPC, I can open a
 bugreport and attach the patch if you're happy with that.
Decided to upload it - I think it's a great improvement compared to the
original code. Unfortunately that has more to do with my skills and
other peoples' help, but well... better code is better code :)

Uploaded as issue 19987.

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

Re: [fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset

On 15-8-2011 12:33, michael.vancann...@wisa.be wrote:
 I applied the patch, thank you very much for this work :-).
 
 But please:
 - Try to split patches in smaller chunks. It's better for bugfixing.
   If you break something it's harder to track what caused the break with
   these huge patches.
Ok - and I thought it would be less work for you guys to apply it if I
submitted one big one ;)
 
 - Please send diffs.
Ok.
 - Don't change casing of files in between patches.
   (should be no problem if you send diffs, actually)
Mmm, tried to help there, by lowercasing everything...
 
Thanks a lot, my itch has been scratched for now - back to developing
the program that was actually meant to use this functionality.

Of course, bug reports/improvement suggestions still welcome; I'll try
and submit small patches for them ;)

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

[fpc-pascal] Funambol/syncml and fpc

2011-08-30 Thread Reinier Olislagers

Hi all,

Has anyone used funambol/syncml libraries or an FPC equivalent to talk
the syncml protocol?

I've got a Firebird address database that I would like to sync some day
using Funambol (with Thunderbird, or sogo/OpenChange in future).
(Also, another very wild idea is trying to write a Thunderbird syncml
plugin that works, using FPC)

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

[fpc-pascal] DBF Field name length and fpdbfexport

Hi all,

If I Googled correctly, the following field size limits are present for
the various DBase formats:
3: DBase III: 10 characters
4: DBase IV: 10 characters
7: DBase VII: 32 characters
8: FoxPro: 10 characters

3,4: http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT

7: IIRC, from http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm
(forwarded by Wikipedia), but that page is down now

8:
http://www.dynamic.com/v7/what-are-limitations-foxpro-full-isam-file
http://www.foxite.com/archives/foxpro-field-names-066805.htm
Apparently Visual FoxPro 8 has 27 characters in a DBC (Database
container) file, but only 10 in a DBF file.

Is that correct?
The reason I ask:

In packages\fcl-db\src\export\fpdbfexport.pp
These tablelevels/formats are defined:
  TTableFormat = (tfDBaseIII,tfDBaseIV,tfDBaseVII,tfFoxPro);

In function
function TFPCustomDBFExport.BindFields: Boolean;
there is this part (line 136):
  If FormatSettings.AutoRenameFields and
(FormatSettings.TableFormat=tfDbaseIII) then
CheckExportFieldNames;

1. Shouldn't this be amended to (don't know if you can use in in this way):
  If FormatSettings.AutoRenameFields and (FormatSettings.TableFormat in
[tfDbaseIII,tfDbaseIV,FoxPro]) then
CheckExportFieldNames;

2.
http://devzone.advantagedatabase.com/dz/webhelp/Advantage8.1/server1/table_dbf_.htm
Characters allowed seem to be for standard Xbase DBF tables that are
compatible with CA-Clipper DBF tables, Microsoft FoxPro DBF tables, and
dBASE III+ DBF tables:

may only contain the letters ‘a’-‘z’ and ‘A’-‘Z’, digits ‘0’-‘9’, and
the underscore ‘_’ character

Presumably the CheckExportFieldNames could be amended for that, too, right?

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

Re: [fpc-pascal] DBF Field name length and fpdbfexport

On 2-9-2011 13:23, michael.vancann...@wisa.be wrote:
 
 On Fri, 2 Sep 2011, Reinier Olislagers wrote:
 
 Hi all,
snip long-winded post
 
 Presumably, yes.
 
 Michael.
;)

Thanks, I'll give it a go and attach a patch to Mantis...

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

Re: [fpc-pascal] DBF Field name length and fpdbfexport

On 2-9-2011 13:23, michael.vancann...@wisa.be wrote:
 On Fri, 2 Sep 2011, Reinier Olislagers wrote:
snip
 In packages\fcl-db\src\export\fpdbfexport.pp
 These tablelevels/formats are defined:
  TTableFormat = (tfDBaseIII,tfDBaseIV,tfDBaseVII,tfFoxPro);

 In function
 function TFPCustomDBFExport.BindFields: Boolean;
 there is this part (line 136):
  If FormatSettings.AutoRenameFields and
 (FormatSettings.TableFormat=tfDbaseIII) then
CheckExportFieldNames;

 1. Shouldn't this be amended to (don't know if you can use in in this
 way):
  If FormatSettings.AutoRenameFields and (FormatSettings.TableFormat in
 [tfDbaseIII,tfDbaseIV,FoxPro]) then
CheckExportFieldNames;
sip
 Presumably, yes.
 
 Michael.
Uploaded a patch, issue 20134
http://bugs.freepascal.org/view.php?id=20134

I think I've also found the solution to
http://bugs.freepascal.org/view.php?id=20069
(patch attached), so if somebody would be so kind to review  apply
them, I'd be very happy.

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

Re: [fpc-pascal] DBF Field name length and fpdbfexport

On 2-9-2011 15:09, michael.vancann...@wisa.be wrote:
 On Fri, 2 Sep 2011, Reinier Olislagers wrote:
 On 2-9-2011 13:23, michael.vancann...@wisa.be wrote:
 On Fri, 2 Sep 2011, Reinier Olislagers wrote:
 I think I've also found the solution to
 http://bugs.freepascal.org/view.php?id=20069
 (patch attached), so if somebody would be so kind to review  apply
 them, I'd be very happy.
 
 You can start being happy.
 
 Thanks for the patches!
 
 Michael.

:) :) :)

Thanks a lot, Michael, one step closer to a working data
processing/export program the hard way (i.e. getting FPC patches in for
everything that seems wrong, apart from my newbie mistakes)

Yes, I have a masochistic streak - but it's nice to be able contribute
back for a change.

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

[fpc-pascal] Improved LazUpdater - testers welcome on Windows

2011-09-03 Thread Reinier Olislagers

Hello FPC and Lazarus lists,

I've been improving the LazUpdater FPC/Lazarus SVN downloader/installer
written by Ingo Steiniger for a while now.

I didn't get any reaction from the original author
http://forge.lazarusforum.de/issues/118
so I uploaded my version to a mercurial repository:
https://bitbucket.org/reiniero/lazupdater_baremetal

I use it myself next to a snapshot Lazarus install to keep a GIT version
of FPC  Lazarus up to date.
Features:
- Runs on Windows, needs some improvements (URLs, paths) to work
correctly on Linux, OSX
- Checkout/update from either SVN or GIT for FPC  Lazarus
- Compiles FPC and Lazarus if any changes were downloaded
- Option to force Lazarus compile after FPC compile
- Compile Lazarus with make or lazbuild
- Options can be passed to make
- Compiles LazDataDesktop
- Redirects svn/git and make output to screen for viewing
- LazUpdater settings can be saved and loaded into profiles
- Attempt at Windows bare metal install: install without binutils or
SVN/Git/zip binary present

There were still some niggling problems with the bare metal mode last
time I tested... Please feel free to test and report issues though on
the repository's bugtracker.

How to use it:
Run LazUpdater, set it to download from SVN or GIT and indicate your
GIT/SVN executable location.
Indicate if you want to update/make both FPC and Lazarus (I always run
the force options) and run.

It should checkout/update FPC from SVN, compile FPC. Then accept the
request to change the compiler used in Lazupdater to the newly compiled
FPC compiler.
IIRC, it will also generate fpc.cfg correctly using fpcmkcfg.exe.
Lazupdater will checkout/update Lazarus from SVN and compile with the
compiler that was set.

You can use this to have multiple Lazarus/FPC installs on your system,
but remember to use a shortcut with --primary-config-path to
differentiate the settings.

Some improvements to be done:
1. Test bare metal mode on Windows without any FPC/Lazarus/SVN/GIT.
2. On Linux+OSX: let the program check for make (other needed bins?),
fix URLs, program paths, test.
3. Strip out old fpc.cfg boilerplate text as I'm using FPC's
fpcmkcfg.exe anyway
4. Get in touch with original author and try to merge changes. Don't see
any changes of his since I started my modifications, so that is probably
easy.
5. Perhaps get in touch with FPC/Lazarus devs, and submit for inclusion
as a Lazarus tool, or include as a download on the Lazarus site. Will
possibly need to change license from GPL to the FPC modified LGPL???
This will enable easier download of updated versions by developers not
familiar with or to lazy for FPC/Laz build processes.
6. Detect bitness (64, 32) and install 64 bit if possible, unless
overruled by user setting.

Patches, tests and suggestions are welcome!

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

[fpc-pascal] TField.Attributeset explanation?

Hi all,

Working on the SQLDB Tutorial1 on the wiki.

I'm struggling with getting dbgrid-driven inserts to work.
Using Firebird employee.fdb CUSTOMER table; CUST_NO is an integer
primary key with Firebird generator/sequence + trigger = sort of an
autonumber/autoinc field.

When inserting records with an empty CUST_NO, I get an error that
CUST_NO is required.

Somebody on a Dutch forum told me to try to predefine SQLQuery field
definitions, and set faRequired to false for CUST_NO.
While that didn't seem to work for me, I thought why not
programmatically set that property after loading the query and found
http://freepascal.org/docs-html/fcl/db/tfield.attributeset.html

However, it doesn't say exactly what AttributeSet is meant for, and more
importantly, what values to set.
A grep through the FPC source code didn't help either.

So my questions:
1. What does Attributeset mean
2. What strings can I feed it with
3. Would that help in my case (of course, this is the FPC list, so any
answer to this Lazarus-related question would be a bonus ;)

Sample source code with Windows embedded Firebird dlls, database can be
downloaded from
https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/laztut_nlDelphi_embedded4sept.zip

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

[fpc-pascal] FPCDocs Git repository

Hi all, goeiemore Graeme ;),

While there are git repositories for FPC and Lazarus, there doesn't seem
to be one for FPCDocs.

Is a public git repository available for FPCDocs?

The reason: I'm looking into extending my version of LazUpdater
https://bitbucket.org/reiniero/lazupdater_baremetal
to support getting/updating FPCdocs as well. Would be handy if that
could done by either Git or SVN binaries...

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

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

On 5-9-2011 10:30, michael.vancann...@wisa.be wrote:
 On Mon, 5 Sep 2011, Reinier Olislagers wrote:
 When inserting records with an empty CUST_NO, I get an error that
 CUST_NO is required.
 
 That is normal.
 
 Just set the 'Required' property of the CUSTNO field to False.

AAARGGH. A million thanks, Michael. That works.
I KNEW it would be simple. Why hadn't I looked at required in the
fielddefs...!?!?!?
 
 Forget the 'Attributeset' property. It's not used in FPC.
 
 (in fact, I don't even know what it's for or where it comes from)
Ok, I noticed it isn't used ;)

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

Re: [fpc-pascal] FPCDocs Git repository

On 5-9-2011 12:19, Graeme Geldenhuys wrote:
 I'm a bit busy at work at the moment, but will see if I can setup a
 Git mirror in a few days time.
 
 Regards,
   - Graeme -
Baie dankie dat jy dit wil doen!
Thanks a lot in advance,

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

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

On 5-9-2011 11:39, michael.vancann...@wisa.be wrote:
 On Mon, 5 Sep 2011, Alex Shishkin wrote:
 05.09.2011 12:30, michael.vancann...@wisa.be пишет:
 Forget the 'Attributeset' property. It's not used in FPC.

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

 Michael.
 http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/DB_TField_AttributeSet.html

 
 In short, Delphi also no longer uses it, as TTable and TQuery are BDE
 components and they are deprecated. None of the newer technologies uses the
 data dictionary.
 
 I never understood why they abandoned their data dictionary technology :/
 
 Michael.
See documentation patch:
http://bugs.freepascal.org/view.php?id=20152

Be gentle - it's my first doc patch ;)

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

Re: [fpc-pascal] DBF Field name length and fpdbfexport

On 2-9-2011 14:38, Reinier Olislagers wrote:
 I think I've also found the solution to
 http://bugs.freepascal.org/view.php?id=20069
 (patch attached), so if somebody would be so kind to review  apply
 them, I'd be very happy.

Turns out the dbf export code needs at least another patch.
DBF export missed support for ftfloat and other field types.

Issue + patch at
http://bugs.freepascal.org/view.php?id=20160

Even with this patch, and the other 2 recently committed, I get some
errors (cannot find field= probably a field name/length issue).

When I know more, I'll post another issue  hopefully patch.

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

Re: [fpc-pascal] DBF Field name length and fpdbfexport

2011-09-06 Thread Reinier Olislagers

On 6-9-2011 8:32, Michael Van Canneyt wrote:
 On Tue, 6 Sep 2011, Reinier Olislagers wrote:
 Wasn't aware of your/maintainers' preferences regarding naming, so I'll
 keep that in mind. To be honest, just thought you guys were lazy  old
 fashioned to use I  J as loop counter variables ;)
 
 No, brevity is a virtue. Small is beautiful :-)
So size does matter - as I've been told before ;)

 I've noticed that SQL insert statement output (issue 19937) and CSV
 output (issue 19759) don't work well either (quoting issues for memo
 fields and/or blobs), so if anyone's feeling in a bug fixing mood,
 there's patches in there already ;)
 
 I'll definitely have a look at them later today.
Thanks.

 I do intend also to upload the dbf export test I used in these bug
 reports for inclusion in the fcl db test directory.
 Great !
Done, issue 20163

 Also, creating a Lazarus XMLSDExport component, and possibly rewriting
 CSVexport to use sdfdata, so it needs less code (current code basically
 duplicates what sdfdata does...)
 Well, the reason I didn't do that was that I wanted to test the generated
 files with sdfdata. Kind of a cross-check.
 Feeling like I'm going to make obvious points, but well, I'm not
afraid of appearing obvious ;) 

I understand.
1. However, the existing csvexport code could be modified  moved to the
test suite to verify export. (Can't remember now if it already exists,
but we can also create a csvimport module for sdfdata and test the
export that way)
2. Alternatively, we could use a comprehensive but fairly static (i.e.
test code/data doesn't change often) export test. That would include the
generated CSV data as data. Then let the test compare the
sdfdataexport generated file with the stored CSV data.
The advantage would be that sdfdata gets more exposure, and, if needed,
another tool (LibreOffice, Excel, Access, .Net, C++ application) could
be used to read in  verify the sdfdataexport generated files.
After all, that's the final test, lacking a csv import module.

 You are aware that the Export components can be registered inside lazarus ?
Mmmm, yes, but I'm talking about having a nice shiny XMLXSDExport button
(a la existing SimpleXMLExport button) for people to throw on a form.
(Maybe that's what you mean, too...)
I had tried to create a button/component before but faild due to lack of
knowledge.
I now have the Lazarus book  more knowledge, so I'll give it another go.


 Why, are you looking for people to improve Datadesktop (any hints) or
 planning to improve it yoursel? ;)
 
 I continuously improve it (slowly), and now your patches do as well, all
 these components are used in the data desktop :-) But from your
 descriptions I gathered that you were working on something similar as
 the data desktop.
Ok.
No, it's something else ;)

Though my holy grail that is (can be) data desktop related is having a
GUI/visual query builder such as those provided by Access, SQL Server
management studio (and presumably Oracle tools, have only tried them a
couple of times), and Business Intelligence tools.
That would allow technically inclined end users (or end users of
technical software ;) to construct their own queries, could be handy,
also in my current project.

Coffee first now, though ;)

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

CSVExport: was Re: [fpc-pascal] DBF Field name length and fpdbfexport

2011-09-07 Thread Reinier Olislagers

On 6-9-2011 9:14, Reinier Olislagers wrote:
 On 6-9-2011 8:32, Michael Van Canneyt wrote:
 On Tue, 6 Sep 2011, Reinier Olislagers wrote:
 Also, creating a Lazarus XMLSDExport component, and possibly
 rewriting CSVexport to use sdfdata, so it needs less code
 (current code basically duplicates what sdfdata does...)
 Well, the reason I didn't do that was that I wanted to test the
 generated files with sdfdata. Kind of a cross-check.

Just thought of some more reasons - I'll be away for some days, so I
thought I'd throw it out to the list to ponder.
(Reworded previous reasons for - hopefully - coherent argument):

Feeling like I'm making obvious points, but well, I'm not afraid of
appearing obvious ;)

I understand, but:

1. An import test could be written using TStringList.LoadFromFile.
This will probably work for simpler formats. Will probably need a fix in
TStringList.DelimitedText (issue 19610)
Hint: Dataset.LoadFromFile data import functionality for FCL ;)

2. Alternatively, we could use a comprehensive but fairly static (i.e.
test code/data doesn't change often) export test. That would include the
generated CSV data as data. Then let the test compare the
sdfdataexport generated file with the stored CSV data.

3. Additionally, if needed, another tool (LibreOffice, Excel, Access,
.Net, C++ application) could be used to read in  verify the
sdfdataexport generated files.

4. Using sdfdataset, you get multiline capability (embedding a line
break in a field) for free (mantis 17285) ;)

The advantage of moving to sdfdataset would be code simplification/reuse
Sdfdata also gets more exposure and therefore testing.


And, yes, I'm willing to write up a patch for review, but probably not
soon...

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

[fpc-pascal] How to detect supported data types in dataset?

2011-09-07 Thread Reinier Olislagers

Hi list,

Possible newbie question so feel free to educate me ;)
(Away for some days, so may not read response until back)

A patch by Ludo Brands on bufdataset (mantis 19930) got me thinking:

const
  ftSupported = [ftString,ftGuid,... and so on];

procedure TCustomBufDataset.CreateDataset;
var i:integer;
 begin
...
// check if all types are supported
  For i:=0 to FieldDefs.Count-1 do
if not (Fielddefs.items[i].DataType in ftSupported) then

DatabaseErrorFmt(SUnsupportedFieldType,[Fieldtypenames[Fielddefs.items[i].DataType]]);
   CreateFields;
 end;

Suppose I want to write a dataset data copier or importer/exporter, how
do I detect supported datatypes in a dataset?

For example, in my dbfexport test code, I make a bufdataset with all
possible fields, then strip each field away when strange errors/AVs
occur when assigning values to them.
For other datasets (with similar checks as proposed in Ludo's patch),
the runtime library is nice enough to warn me on field creation that it
doesn't work.

Am I missing something obvious or does it make sense to expose something
like a SupportedFieldTypes property for datasets?
How does Delphi do this?

Besides that, I think it's an excellent idea to check for invalid
datatypes when creating fields, rather than failing later on when
assigning values to them.
(Of course, if that is implemented in a lot of datasets, checking
exceptions when creating fields would be a rough way of checking if a
datatype is supported ;)

I understand that 3rd party inherited datasets may not abide by this,
but it's worth a shot to offer the functionality..

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

[fpc-pascal] Re: How to detect supported data types in dataset?

2011-09-15 Thread Reinier Olislagers

On 8-9-2011 9:16, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
 On Thu, 8 Sep 2011, Reinier Olislagers wrote:
 Am I missing something obvious or does it make sense to expose something
 like a SupportedFieldTypes property for datasets?
 How does Delphi do this?
 
 It does not.
 Besides that, I think it's an excellent idea to check for invalid
 datatypes when creating fields, rather than failing later on when
 assigning values to them.
 
 It is up to the implementation of the datasets to give a decent error when
 an unsupported data type is being created.
Ok, thanks, I'll raise bug reports for the relevant datasets when I hit
that problem again...

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

[fpc-pascal] [Patch] New tests for fcl-db export

2011-09-16 Thread Reinier Olislagers

Hi list,

FYI  hopefully implementation:

I've been writing some tests for fcl-db export, that test basic
functionality for:
- CSV export
- DBF export
- SimpleXML export

Please find them in Mantis:
20271   [Patch] SimpleXML export: new test for fcl-db

20268   [Patch] CSV export: new test for fcl-db

20163   [Patch] Dbase export: new test for fcl-db
(reopened, contains fixes suggested by Michael Van Canneyt)


They're all set up in a similar way: create a bufdataset with all the
field types I can cram in, fill them with some rows of extreme and
middle-of-the-road data and try an export.
For e.g. simple xml and csv export, default export formatting settings
as well as custom format settings are tested.

In future, they could be extended a bit (e.g. test reading generated csv
into a stringlist, reading dbf etc).

I do realise these tests could be combined in a big export test, but it
might be an even better idea to incorporate it in the existing
dbtestframework.

However, understanding how to work the db testframework to do the export
tests for a large amount of different data in the datasets is a bit
above the combination of (my skills+my interest in figuring it out), so
in the meanwhile my motto is: a test (or 2) is better than no test.

Also, if somebody would be willing to look at my pet patches:
19759 CSV export doesn't quote memo fields
19937 TSQLExporter does not quote memo fields (or blobs)

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

[fpc-pascal] How to do conditional compilation with macros

Trying to test for a certain minimum version of FPC.

Have got FPC version 2.7.1 [2011/09/17] for i386 on Windows.

What am I doing wrong?

program conditional;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes;

begin
  //How should I use FPCVULLVERSION in conditional compilation?
  {$IF $FPCFULLVERSION  20200}
  writeln('Version newer than 2.2');
  //Error: Compile time expression:
  //Wanted BOOLEAN but got INTEGER at IF or ELSEIF
  {$ENDIF}


  //so maybe the IF wants a precooked boolean result
  //let's try some brackets
  //Tried to apply Programmer's Guide 2.4 on Compile time expressions:
  {$MACRO+}
  {$IF (FPCFULLVERSION  20200)}
  //Error: Compile time expression Wanted STRING but got INTEGER at
  //FPCFULLVERSION  20200
writeln('Version newer than 2.2 another try');
  {$ENDIF}

  //adding a $:
  {$IF ($FPCFULLVERSION  20200)}
  //Error: Syntax error while parsing a conditional compiling expression
writeln('Version newer than 2.2 yet another');
  {$ENDIF}
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to do conditional compilation with macros

On 18-9-2011 13:41, Sven Barth wrote:
 On 18.09.2011 13:29, Reinier Olislagers wrote:
 What am I doing wrong?
 
 Additionally to what Marco wrote:
 
 You must not use the $ as prefix for the variable if you reference
 such a compiler define inside an $if or $ifdef.
 
 Regards,
 Sven

Thanks guys - reading manuals is not always my strong point ;)

This works:
program conditional;

{$mode objfpc}{$H+}

begin
  {$IF FPC_FULLVERSION  20200}
  //apparently FPC_FULLVERSION was introduced
  //in FPC 2.2.4 though...
  //http://delphi.wikia.com/wiki/FreePascal_detection_and_versioning
  writeln('Version newer than 2.2');
  {$ENDIF}
end.

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

[fpc-pascal] Hints on getting FPDocs to work on Linux

Hi gang,

total Latex newbie here

Any hints on which packages to install on Debian Squeeze (current
stable) or which files are required so I can try generating some FPDocs
content?

Something like
aptitude install texlive tex4ht python-plastex hevea dvi2tty
perhaps?

(Looking into writing some documentation on the db export units, but not
so sure about my patches  want to test first how they end up looking)

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

Re: [fpc-pascal] Hints on getting FPDocs to work on Linux

On 18-9-2011 23:27, Graeme Geldenhuys wrote:
 On 18/09/2011, Reinier Olislagers  wrote:
 
I never install binary releases of the various distro packages - they
are always out of date.

LazUpdater ftw ;) (When I have it working on Linux)

 Your post did remind me to check whether git is installed though, thanks ;)
 
 Did I mention SVN and Git come standard with Slackware too. :-)
Could have guessed though ;)

Still, it comes down to what one is most comfortable with.
And if you want to, you can use a preseed file (IIRC) that customises
your Debian install, similar to RedHat kickstart. Used it once to
generate a working, configured VPN server from an ISO.
... leaving out other methods like puppet, FAI etc, but I've never used
these in anger yet.
 
 
 Personally, I'd rather see some more content in the help files than yet
 another way of generating the stuff,
 
 That's the problem for the documentation writers, not for the
 documentation tools. 
True, if you want to divide people into categories ;)

 On the topic, I can add that the FPC docs are
 very good. It's class documentation from other frameworks that are
 lacking.
Yep, such as a certain well-known Delphi clone...

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

[fpc-pascal] fcl-extra ServiceManager doesn't seem to working with unelevated Windows account?

Hi list,

First wanted to check with you if I'm doing something wrong.
Using the ServiceManager unit (Windows only), I'm trying to find out if
a service is running (Vista x64).
I can do:
sc query samss
on the command line without problem.
When I run
fpc ServiceTest.pas
rem Free Pascal Compiler version 2.7.1 [2011/10/04] for i386
ServiceTest
I get:
Starting test for SamSs service.
An unhandled exception occurred at $0041FAD5 :
EOSError : System error, (OS Code 5):
Access is denied.

  $0041FAD5
  $00421333
  $0040162B
  $004017C1
When I run the same program using an elevated (administrator) command
prompt, I get:
Starting test for SamSs service.
The SamSs service is running

Am I doing something wrong?

Program below can also be found on wiki:
http://wiki.lazarus.freepascal.org/ServiceManager

program ServiceTest;
// Check if a certain process is running.
{$mode objfpc}{$H+}
uses
  Classes,
  SysUtils,
  ServiceManager,
  JwaWinSvc {for services declarations};

function IsServiceRunning(ServiceName: string): boolean;
  {description Checks if a Windows service is running}
var
  Services: TServiceManager;
  ServiceStatus: TServiceStatus;
begin
  //Check for existing services
  //equivalent to sc query servicename
  Services := TServiceManager.Create(nil);
  try
try
  Services.Connect;
  Services.Acces := SC_MANAGER_CONNECT; //Note typo in property.
  //We don't need more access permissions than this; by default
  //the servicemanager is trying to get all access
  Services.GetServiceStatus(ServiceName, ServiceStatus);
  if ServiceStatus.dwCurrentState = SERVICE_RUNNING then
  begin
Result := True;
  end
  else
  begin
Result := False;
  end;
  Services.Disconnect;
except
  on E: EServiceManager do
  begin
// A missing service might throw a missing handle exception? No?
  {LogOutput('Error getting service information for ' + ServiceName +
'. Technical details: ' + E.ClassName + '/' + E.Message);}
Result := False;
raise; //rethrow original exception
  end;
  on E: Exception do
  begin
  {LogOutput('Error getting service information for ' + ServiceName +
'. Technical details: ' + E.ClassName + '/' + E.Message);
}
Result := False;
raise; //rethrow original exception
  end;
end;
  finally
Services.Free;
  end;
end;

const
  ServiceToTest = 'SamSs';

//Security Accounts Manager, should be running, at least on Vista
begin
  WriteLn('Starting test for ' + ServiceToTest + ' service.');
  if IsServiceRunning(ServiceToTest) then
  begin
WriteLn('The ' + ServiceToTest + ' service is running');
  end
  else
  begin
WriteLn('The ' + ServiceToTest + ' service is not running');
  end;
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fcl-extra ServiceManager doesn't seem to working with unelevated Windows account?

On 4-10-2011 12:31, Sven Barth wrote:
 Am 04.10.2011 12:22, schrieb Reinier Olislagers:
Services.Connect;
Services.Acces := SC_MANAGER_CONNECT; //Note typo in property.
 
 You need to set Acces(s), before calling Connect, because the
 connection API OpenSCManager is called inside Connect using the
 access flags that were set.
 
 At least that's the only problem I see without testing it myself.
 
 Regards,
 Sven
Thanks, Sven,

Another duh moment. I had even already commented that Connect is
trying to request all possible access by default.

It works now.

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

[fpc-pascal] [Semi-OT] Git format patches don't seem to work

Hi all,

Having some trouble creating patches that actually work.
(On Windows)
I've been using git to get FPC trunk and
git diff --no-prefix  %temp%\mypatch.diff
rem --no-prefix : Do not show any source or destination prefix.
to create patches.

Using Msysgit:
git --version
git version 1.7.6.msysgit.0

However, if I try to apply the patch with
cd /d c:\development\fpc\source
rem use fpc binutils patch
patch -p0  %temp%\mypatch.diff
I often get a nasty error:
patching file `packages/fcl-extra/src/win/ServiceManager.pas'
Assertion failed: hunk, file patch.c, line 321

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

Patch version:
patch --version
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall with lots o' patches by Paul Eggert

As an alternative, I've used diff with two directories like this:
diff -u --minimal --recursive --unified -N olddir newdir  mypatch.diff
but that may have some issues with Linux/Windows line endings..

Any suggestions for creating/applying better patches using git or diff?

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

Re: [fpc-pascal] [Semi-OT] Git format patches don't seem to work

On 4-10-2011 13:14, Marco van de Voort wrote:
 In our previous episode, Reinier Olislagers said:
 Having some trouble creating patches that actually work.
 (On Windows)
 I've been using git to get FPC trunk and
 git diff --no-prefix  %temp%\mypatch.diff
 rem --no-prefix : Do not show any source or destination prefix.
 to create patches.
 
 I don't know about GIT, but some tips:
 
 1. Play with lineending.  (I use cygwin's dos2unix and unix2dos to convert)
 2. Also make sure that the generated diffs are in the universal format.
Thanks, Marco  cobines:

That seems to be it!

Unified format: yep, running either
git diff --no-prefix  %temp%\mypatch.diff
or
git diff --no-prefix --unified=3  %temp%\mypatch.diff
gives the same results.

git diff (in my install at least) seems to generate Unix line endings.
If I do something like
cd /d C:\Development\Fpc\Source\packages\fcl-extra\src\win
git diff --no-prefix  %temp%\gitpatch.diff
rem convert unix line endings to dos:
sfk lf-to-crlf %temp%\gitpatch.diff
rem using swiss file knife, for some reason I hate cygwin ;)
ren %temp%\gitpatch.diff gitpatch_convertedtodoslineending.diff
patch -p5  %temp%\gitpatch_convertedtodoslineending.diff
it seems to work.

Unfortunately, git diff doesn't seem to have any arguments for line end
conversion, but there must be some setting/config somewhere that I had
set incorrectly...

I'll get back when I know more...

Thanks!

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

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

On 4-10-2011 14:41, Reinier Olislagers wrote:
 On 4-10-2011 13:14, Marco van de Voort wrote:
 In our previous episode, Reinier Olislagers said:
 Having some trouble creating patches that actually work.
 (On Windows)
 I've been using git to get FPC trunk and
 git diff --no-prefix  %temp%\mypatch.diff
 I don't know about GIT, but some tips:

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

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

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

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

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

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


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

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

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

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

On 6-10-2011 16:56, Alex Shishkin wrote:
 06.10.2011 16:37, Reinier Olislagers пишет:
 On 4-10-2011 14:41, Reinier Olislagers wrote:
 On 4-10-2011 13:14, Marco van de Voort wrote:
 In our previous episode, Reinier Olislagers said:
 Having some trouble creating patches that actually work.
 (On Windows)
 I've been using git to get FPC trunk and
 git diff --no-prefix  %temp%\mypatch.diff
 I don't know about GIT, but some tips:

 1. Play with lineending.  (I use cygwin's dos2unix and unix2dos to
 convert)
 Ok, I've looked at it some more:
 Example:
 packages\fcl-extra\src\win\ServiceManager.pas

 svn:
 via web:
 http://svn.freepascal.org/svn/fpc/trunk/packages/fcl-extra/src/win/ServiceManager.pas

 =  Unix line endings
 Local svn:
 svn proplist -v packages\fcl-extra\src\win\ServiceManager.pas
svn:eol-style
  native
 so:
 =  WINDOWS LINE ENDINGS
 Therefore patch.exe on Windows probably works

 Git:
 https://github.com/graemeg/freepascal/raw/7026b7669fd422f88ffe33174dac1725c0295427/packages/fcl-extra/src/win/ServiceManager.pas

 =  Unix line endings
 via git pull etc
 =  Unix line endings
 not surprising...

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

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


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

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

 Thanks,
 Reinier

 there is git config option core.autocrlf try to use it

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

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

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

On 6-10-2011 17:07, Graeme Geldenhuys wrote:
On 06/10/2011, Reinier Olislagers wrote:

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

Seems the SVN client is converting line endings to my native format.
Thanks for the clear explanation.

Don't be so quick to blame the tool, rather learn how to use the tool!
Not really, I did suggest that smarter users than me might have a
solution... ;)

If you want Git to convert EOL characters to your native platform,
then tell it to do so during the Git installation (which you clearly
skipped or didn't understand the options), or specify it later as a
global or per repository option (normally before a 'git clone'
process).
Thanks, that matches with what I found out.

Here it show the option you somehow skipped to notice in the Git installation:
http://opensoft.homeip.net:8080/~graemeg/msysgit-1.png
Did see that, thought about it obviously picked the wrong one ;)

To find out more about the core.autocrlf option look it the help:
git help config
then search for 'core.autocrlf'
Yep, had seen that, but it wasn't too clear to a git newb like me
though. Still, I've been finding out more - by trial and error ;)

I had supposed that FPC stored its text files in CRLF format but
obviously both the Git and SVN repositories contain LF data.

I'll get back to the list when necessary. Thanks for the help.

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

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

On 6-10-2011 17:04, Alex Shishkin wrote:
 06.10.2011 18:59, Reinier Olislagers пишет:
 Thanks Alex, I already fiddled with that. I'll try again with
 core.autocrlf set to true and false to make sure it doesn't work...


 not true not false, but input. Read this if have not yet :
 http://progit.org/book/ch7-1.html http://help.github.com/line-endings/
Thanks Alex, that's a fairly clear explanation.

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

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

On 6-10-2011 17:04, Alex Shishkin wrote:
 06.10.2011 18:59, Reinier Olislagers пишет:
 Thanks Alex, I already fiddled with that. I'll try again with
 core.autocrlf set to true and false to make sure it doesn't work...

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

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

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

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

Am I doing something stupid with autocrlf input?

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

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

On 7-10-2011 9:15, Graeme Geldenhuys wrote:
 On 06/10/2011 20:41, Reinier Olislagers wrote:
 The Git installation under Windows set mine to true (not input).
true it is, see other message ;)
 So while it could be used, I'd have to remember to run unix2dos over it
 - that is, if people expect a Windows patch (
 I don't think that is needed. I believe the 'patch' program will sort
 that out by itself. I have sent numerous patches to FPC and Lazarus
 (both those repositories are git ones on my Linux system). Nobody has
 ever complained that the EOL style was wrong. I also don't specify the
 --no-prefix when creating patches. Again, the 'patch' program can handle
 those a/... b/... prefixes for the committer without problems.
Thanks, did a quick test with svn/patch. SVN diff gives Windows line
endings. FPC patch applying diff works.

However, on Windows, the git diff doesn't seem to work, patch as
supplied by FPC on windows freaks out on Unix line endings:
cd /d C:\Development\Fpc\source
notepad packages\fcl-extra\src\win\ServiceManager.pas
rem do some changes
git diff  c:\windows\temp\gitdiff.diff
rem results in unix line endings, see attachment
type c:\windows\temp\gitdiff.diff
diff --git a/packages/fcl-extra/src/win/ServiceManager.pas
b/packages/fcl-extra
src/win/ServiceManager.pas
index 47bd1cc..af62487 100644
--- a/packages/fcl-extra/src/win/ServiceManager.pas
+++ b/packages/fcl-extra/src/win/ServiceManager.pas
@@ -136,7 +136,8 @@ type
 procedure GetServiceStatus(SHandle : THandle; Var Status :
TServiceStatus)
 overload;
 procedure GetServiceStatus(ServiceName : String; Var Status :
TServiceStat
s); overload;
 Property  Handle : THandle Read FHandle;
-Property  Acces : DWord read FAccess Write FAccess;
+Property  Access : DWord read FAccess Write FAccess;
+Property  Acces : DWord read FAccess Write FAccess; deprecated;
//Kept for
compatibility
 Property  Services : TServiceEntries Read FServices;
   published
 { Published declarations }

rem now try to reverse the change:
patch --dry-run -R -p1  c:\windows\temp\gitdiff.diff
Assertion failed: hunk, file patch.c, line 321

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

ok, converted LF=CRLF into c:\windows\temp\gitdiff_crlf.diff (attached)
patch -R -p1  c:\windows\temp\gitdiff_crlf.diff
works

Patch version:
C:\Development\Fpc\sourcepatch -v
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall with lots o' patches by Paul Eggert

File modification date 30 May 2005, 21:05, 28.160 bytes
diff --git a/packages/fcl-extra/src/win/ServiceManager.pas 
b/packages/fcl-extra/src/win/ServiceManager.pas
index 47bd1cc..af62487 100644
--- a/packages/fcl-extra/src/win/ServiceManager.pas
+++ b/packages/fcl-extra/src/win/ServiceManager.pas
@@ -136,7 +136,8 @@ type
 procedure GetServiceStatus(SHandle : THandle; Var Status : 
TServiceStatus); overload;
 procedure GetServiceStatus(ServiceName : String; Var Status : 
TServiceStatus); overload;
 Property  Handle : THandle Read FHandle;
-Property  Acces : DWord read FAccess Write FAccess;
+Property  Access : DWord read FAccess Write FAccess;
+Property  Acces : DWord read FAccess Write FAccess; deprecated; //Kept for 
compatibility
 Property  Services : TServiceEntries Read FServices;
   published
 { Published declarations }
diff --git a/packages/fcl-extra/src/win/ServiceManager.pas 
b/packages/fcl-extra/src/win/ServiceManager.pas
index 47bd1cc..af62487 100644
--- a/packages/fcl-extra/src/win/ServiceManager.pas
+++ b/packages/fcl-extra/src/win/ServiceManager.pas
@@ -136,7 +136,8 @@ type
 procedure GetServiceStatus(SHandle : THandle; Var Status : 
TServiceStatus); overload;
 procedure GetServiceStatus(ServiceName : String; Var Status : 
TServiceStatus); overload;
 Property  Handle : THandle Read FHandle;
-Property  Acces : DWord read FAccess Write FAccess;
+Property  Access : DWord read FAccess Write FAccess;
+Property  Acces : DWord read FAccess Write FAccess; deprecated; //Kept for 
compatibility
 Property  Services : TServiceEntries Read FServices;
   published
 { Published declarations }
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

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

On 7-10-2011 9:15, Graeme Geldenhuys wrote:
 I don't think that is needed. I believe the 'patch' program will sort
 that out by itself. I have sent numerous patches to FPC and Lazarus
 (both those repositories are git ones on my Linux system). Nobody has
 ever complained that the EOL style was wrong. I also don't specify the
 --no-prefix when creating patches. Again, the 'patch' program can handle
 those a/... b/... prefixes for the committer without problems.

Tried on Debian with subversion, build-essential installed:
Normal git diff: patch  git.diff
doesn't work - will need patch -p1  git.diff

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

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

On 7-10-2011 15:13, Graeme Geldenhuys wrote:
 On 07/10/2011 12:52, Reinier Olislagers wrote:
 doesn't work - will need patch -p1  git.diff
 
 Correct, and anybody that has applied a handful of patches or more in
 there time would have known that already. ;-)
Sure, but why add to the aggravation - SVN diff doesn't do this, so one
less difference to worry about:
--- packages/fcl-extra/src/win/ServiceManager.pas   (revision 19392)

Just trying to make life simpler for our dear hard-working
committers even if that takes hours of annoying mailing list messages ;)

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

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