Re: [fpc-pascal] Re: SDFDataset users!?
AS I understand, there are in sdfdata.pp: TFixedFormatDataSet - for SDF = (*S*tandard *D*ata *F*ormat) A simple file format that uses fixed length fields. TSdfDataSet - for variable field length, where fields are delimited by Delimiter (and probably quoted) ... we can call it CSV and here we can follow http://tools.ietf.org/html/rfc4180 (with exception, that field delimiter can be user defined - .other than comma) It will be good also document in begining of sdfdata.pp what standard is followed ;-) L. On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). There is: - the unit name (sdfdataset) - the comments - the code - the output All of this makes it in my opinion more likely to be SDF than CSV. CSV is not SDF. See the test results from the Delphi test I posted to the list earlier. For a description of what SDF is (based on Delphi help as well as the tests), see http://wiki.lazarus.freepascal.org/SDF If you understand it is CSV, why not document it, even if only in a readme: In contradiction to what its name may apply, Sdfdataset reads and writes CSV data according to RFC4180, not the Delphi SDF format. PS: I'll leave writing a test set to test against RFC4180 for people who care. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
Am 25.09.2012 07:56, schrieb Reinier Olislagers: On 24-9-2012 21:08, Sven Barth wrote: On 24.09.2012 21:06, Sven Barth wrote: Do you think this version is good enough? Comments here or on the forum would be welcome. The only problem I have with TSDFDataset is the following issue related to more strict CPU targets: http://bugs.freepascal.org/view.php?id=22964 I meant this: http://bugs.freepascal.org/view.php?id=17871 Thanks, Sven, Perhaps the modified testsdf.pp could be added to the db test suite (packages\fcl-db\test), but I suppose some writelns need to be replaced by conditional functions (the writelns can be handy when running some tests). I suppose the db test suite doesn't run at all on wince? I never tested it, so I can't tell. For the normal FPC test suite there is the possiblity to cross run it using either SSH or an emulator... and for WinCE there is the following description in the readme: === text begin === Example cross testing of target arm-wince - //arm-wince example: see FPCTRUNK\DEMO\WINCE\TESTEMU\ for additionally required tools Connect your device via ActiveSync and execute: make TEST_FPC=ppcrossarm TEST_CPU_TARGET=arm TEST_OS_TARGET=wince \ TEST_OPT=-XParm-wince- -WC -Xs \ EMULATOR=MyDisc:\My\Path\to\wcetemu.exe Tests will be performed in the \fpctests folder on the device. === text end === [though I don't know in what state the test emulator is...] Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: SDFDataset users!?
On 24-9-2012 20:21, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Ludo Brands wrote: That is in contradiction with the existing implementation as well as the following comments following comments in SDFData.pp 14/Ago/01 Version 2.00 (Orlando Arrocha) John Dung Nguyen showed me how to make this compatible with You are erroneously assuming I actually read the comments. No specs, no docs, only code and comments to go by. Is fpc promoting version 77 of the sdf definition? I added TSDFDataset to FPC because it added an implementation of CSV and fixed format data, because this is how I had used them. That's all I cared about. I had never heard of SDF as a data format. At the time, I probably assumed SDF were the initials of the author or so. That is indeed another approach that doesn't require specs nor docs. Unfortunately only available to those that have the keys to kingdom :) Well, I think that trying to let TSDFDataset conform to certain SDF specs is trying to do some unjustified backfitting. If conforming to the format that is specified in all existing evidence is wrong but conforming to some format that is never mentioned at all is right, I give up. IMO this is no way to run any serious development effort: don't expect people to read minds about what was intended if that is not documented, *especially* in cases like this where any knowledgeable person's obvious conclusion is the one you don't want them to make. Also, first accepting patches that explicitly aim for sdf/delimitedtext compatibility (bug 17285,22213) and then stating the opposite is an excellent incentive for me to drop everything that's sdfdataset related. IMHO, it should do fixed format and CSV as indicated by the RFC I posted. All the rest is nice, but not required from my perspective. It's not required anymore from my perspective either. I just wanted to fix sdfdataset so that it does what it says on the tin. I'd suggest: 1. adding a readme as indicated in my other mail so that users and developers do not fall into the same trap 2. documenting similar unwritten assumptions in other relevant units as well. Not doing so is a great way to discourage contributors 3. dealing with issues 22894, 22882 as you see fit Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: SDFDataset users!?
On 25-9-2012 7:44, Reinier Olislagers wrote: On 24-9-2012 20:21, Michael Van Canneyt wrote: IMHO, it should do fixed format and CSV as indicated by the RFC I posted. All the rest is nice, but not required from my perspective. It's not required anymore from my perspective either. I just wanted to fix sdfdataset so that it does what it says on the tin. I'd suggest: 1. adding a readme as indicated in my other mail so that users and developers do not fall into the same trap 2. documenting similar unwritten assumptions in other relevant units as well. Not doing so is a great way to discourage contributors 3. dealing with issues 22894, 22882 as you see fit Oh and 4. considering removing the TestInputOurFormattests test from packages\fcl-db\tests\tcsdfdata.pp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). There is: - the unit name (sdfdataset) - the comments - the code - the output All of this makes it in my opinion more likely to be SDF than CSV. Like I said, I had never heard of SDF. Look, for me, this is not a requirement set in stone, I am quite flexible. You guys asked what the original idea was, and I explained some of the history behind the dataset. If the desire is to have a TSDFDataset (whatever the specs) and a separate CSV dataset, fine, we'll make it so, this is really not a problem. I don't want anyone to feel that he has wasted his time :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: That is indeed another approach that doesn't require specs nor docs. Unfortunately only available to those that have the keys to kingdom :) Well, I think that trying to let TSDFDataset conform to certain SDF specs is trying to do some unjustified backfitting. If conforming to the format that is specified in all existing evidence is wrong but conforming to some format that is never mentioned at all is right, I give up. IMO this is no way to run any serious development effort: don't expect people to read minds about what was intended if that is not documented, *especially* in cases like this where any knowledgeable person's obvious conclusion is the one you don't want them to make. Also, first accepting patches that explicitly aim for sdf/delimitedtext compatibility (bug 17285,22213) and then stating the opposite is an excellent incentive for me to drop everything that's sdfdataset related. IMHO, it should do fixed format and CSV as indicated by the RFC I posted. All the rest is nice, but not required from my perspective. It's not required anymore from my perspective either. I just wanted to fix sdfdataset so that it does what it says on the tin. I'd suggest: 1. adding a readme as indicated in my other mail so that users and developers do not fall into the same trap Hoho, there is no trap :-) 2. documenting similar unwritten assumptions in other relevant units as well. Not doing so is a great way to discourage contributors That is definitely not the intention. See my other mail. I was frankly surprised by the strong responses I got. Any assumptions I made were mine, and definitely not the law, I just gave them as 'historical background', because that is how I perceived the original question :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 2012-09-24 14:39, Christo wrote: I'm interested in testing your wrapper. Unfortunately I cannot clone the git link above, I get an error (fatal: https://github.com/hansiglaser/pas-libusb/tree/libusb-1.0/info/refs not That was a web link, not the git url. If you followed that link with your web browser, you would have seen at the top a ZIP button which you can use to download the latest code of that branch in a zip archive. There are also two git clone URL's. One uses the HTTP protocol, and the other uses the faster GIT protocol. git clone https://github.com/hansiglaser/pas-libusb.git or git clone git://github.com/hansiglaser/pas-libusb.git then do... cd pas-libusb git checkout libusb-1.0 Unfortunately the master branch appears to be 2 months old. You simply forgot to switch to the 'libusb-1.0' branch. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On 25-9-2012 10:11, michael.vancann...@wisa.be wrote: On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). snip All of this makes it in my opinion more likely to be SDF than CSV. Like I said, I had never heard of SDF. I understand (and appreciate) your reasoning when you committed it. Having a CSV dataset is very handy. Before I understood the full horror of what SDF really means, especially as implemented by Delphi (see the nasty behaviour when you add spaces after a quoted text and before a delimiter) I thought SDF was really some form of CSV, too. (Well I suppose it is, it's just not RFC4180 CSV unless you e.g. decide to quote everything. IIRC then it actually complies with RFC4180). Look, for me, this is not a requirement set in stone, I am quite flexible. So am I... see below. You guys asked what the original idea was, and I explained some of the history behind the dataset. Not really, I asked what the specs were ;) If the desire is to have a TSDFDataset (whatever the specs) and a separate CSV dataset, fine, we'll make it so, this is really not a problem. Actually, if you are happy with an SDFDataset that complies with RFC4180 CSV (but not SDF), I would vastly prefer that over the atrocity that is SDF - as long as this requirement/behaviour is quite clearly specified (e.g. in a readme). If you think that any changes to sdfdataset to make it RFC4180 compliant are acceptable to current users, fine by me ;) The csvdocument [1] code has a very nice record-by-record CSV parser and writer with test set that aims to be RFC4180; this could be used for interoperability testing or even, if evidence by test set failures, used instead of parts of the current code. I don't want anyone to feel that he has wasted his time :-) Well, getting clarity about what the on disk format must be is worth it even though I can't really say I enjoyed this particular episode :) Even better, as I said, if everybody is happy with RFC4180 CSV, I vastly prefer that format to SDF and would consider my time well spent. I'm sure tatamata from the forum will appreciate it too (AFAIR, his ZMSQL is based on sdfdataset). I'm just not interested right now in implementing either a test set or the changes myself, but perhaps somebody else is. Michael. Thanks, Reinier [1] http://wiki.lazarus.freepascal.org/CsvDocument ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: SDFDataset users!?
On 25-9-2012 10:16, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 25 Sep 2012, Reinier Olislagers wrote: I'd suggest: 1. adding a readme as indicated in my other mail so that users and developers do not fall into the same trap Hoho, there is no trap :-) Well, not intentional, but it sure is confusing. 2. documenting similar unwritten assumptions in other relevant units as well. Not doing so is a great way to discourage contributors That is definitely not the intention. See my other mail. I was frankly surprised by the strong responses I got. Any assumptions I made were mine, and definitely not the law, I just gave them as 'historical background', because that is how I perceived the original question :-) Ok, that explains some of the disconnect then. I've responded to your other mail ;) Friends? ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 25-9-2012 10:11, michael.vancann...@wisa.be wrote: On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). snip All of this makes it in my opinion more likely to be SDF than CSV. Like I said, I had never heard of SDF. I understand (and appreciate) your reasoning when you committed it. Having a CSV dataset is very handy. Before I understood the full horror of what SDF really means, especially as implemented by Delphi (see the nasty behaviour when you add spaces after a quoted text and before a delimiter) I thought SDF was really some form of CSV, too. (Well I suppose it is, it's just not RFC4180 CSV unless you e.g. decide to quote everything. IIRC then it actually complies with RFC4180). Look, for me, this is not a requirement set in stone, I am quite flexible. So am I... see below. You guys asked what the original idea was, and I explained some of the history behind the dataset. Not really, I asked what the specs were ;) If the desire is to have a TSDFDataset (whatever the specs) and a separate CSV dataset, fine, we'll make it so, this is really not a problem. Actually, if you are happy with an SDFDataset that complies with RFC4180 CSV (but not SDF), I would vastly prefer that over the atrocity that is SDF - as long as this requirement/behaviour is quite clearly specified (e.g. in a readme). No problem :-) If you think that any changes to sdfdataset to make it RFC4180 compliant are acceptable to current users, fine by me ;) I have not seen any evidence that it has ever been used other than for CSV, but I may be wrong. So I suspect that this should be acceptable. The csvdocument [1] code has a very nice record-by-record CSV parser and writer with test set that aims to be RFC4180; this could be used for interoperability testing or even, if evidence by test set failures, used instead of parts of the current code. I'm fine with that. I don't want anyone to feel that he has wasted his time :-) Well, getting clarity about what the on disk format must be is worth it even though I can't really say I enjoyed this particular episode :) Even better, as I said, if everybody is happy with RFC4180 CSV, I vastly prefer that format to SDF and would consider my time well spent. I'm sure tatamata from the forum will appreciate it too (AFAIR, his ZMSQL is based on sdfdataset). I'm just not interested right now in implementing either a test set or the changes myself, but perhaps somebody else is. Well, in the not-too-far future, I'll spend time on improving the DB testsuite. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Error: Can't take the address of constant expressions
Hi,
Despite
http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields,
shouldn't the following be legal? I tested under FPC 2.6.1 and 2.7.1.
TMyRecord = record
Data: pointer;
end;
TMyClass = class
private
FRef: TMyRecord;
public
property Ref: TMyRecord read FRef write FRef;
end;
var
MyClass1, MyClass2: TMyClass;
procedure test;
begin
Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1);
end;
The complete program is attached.
Thanks,
Stephano
program constaddresstest;
{$IFDEF FPC}
{$mode delphi}
{$ENDIF}
{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes
{ you can add units after this };
type
TMyRecord = record
Data: pointer;
end;
TMyClass = class
private
FRef: TMyRecord;
public
property Ref: TMyRecord read FRef write FRef;
end;
var
MyClass1, MyClass2: TMyClass;
procedure test;
begin
Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1);
end;
begin
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
Hi! Am Dienstag, den 25.09.2012, 09:41 +0100 schrieb Graeme Geldenhuys: On 2012-09-24 14:39, Christo wrote: I'm interested in testing your wrapper. Unfortunately I cannot clone the git link above, I get an error (fatal: https://github.com/hansiglaser/pas-libusb/tree/libusb-1.0/info/refs not That was a web link, not the git url. If you followed that link with your web browser, you would have seen at the top a ZIP button which you can use to download the latest code of that branch in a zip archive. There are also two git clone URL's. One uses the HTTP protocol, and the other uses the faster GIT protocol. git clone https://github.com/hansiglaser/pas-libusb.git or git clone git://github.com/hansiglaser/pas-libusb.git then do... cd pas-libusb git checkout libusb-1.0 Unfortunately the master branch appears to be 2 months old. You simply forgot to switch to the 'libusb-1.0' branch. Thanks Graeme and Henry for taking this support request. :-) BTW: Another user asked whether I'll release the files under a modified LGPL Lazarus/FPC license. Yes, definitely. I hope I can push these changes during the weekend. Bye Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
2012/9/24 Christo christo.cra...@gmail.com: I'm new to using git so it may be something trivial I'm missing. Regarding git, I highly recommend using the easygit wrapper to make life easier, especially when you come from SVN because git will be very confusing in the beginning if you are used to svn and then try to understand the cryptic git commands. It has helped me a lot in the beginning (and still does) and it was the only thing that was finally able to convince me of the great usefulness of git: https://github.com/blog/333-easy-git Its just one huge perl script that you put into your path and then use eg instead of git and have a simpler and more logical command line syntax for most commonly used workflows. Unfortunately it is not actively maintained anymore and some commands do not work as expected with recent versions of git, for this there is a more recent fork here: https://gitorious.org/~smarr/eg/smarrs-mainline/trees/master ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 2012-09-25 17:22, Bernd wrote: I highly recommend using the easygit wrapper to make life easier, especially when you come from SVN because git will be very confusing Thanks for the tip, but Git is *not* difficult to use. To cover the average developer workflow, you need like 3-4 commands max. If you can't remember 4 commands, then you have bigger issues than git. If all else fails, then remember one of these: git help git help command Git has excellent help with lots and lots of example commands to learn from, and ASCII art to help visualize what it does. If you still have problems, simply use 'git alias' and setup SVN-like commands for git. For example: Used to using 'svn up'? No problems, do the same in git. git up-- can maybe execute: git pull origin or git co url -- can maybe execute: git clone url There are some very handy aliases created by many. Use Google to find them. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Can't take the address of constant expressions
2012/9/25 patspiper patspi...@gmail.com: Hi, Despite http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields, shouldn't the following be legal? I tested under FPC 2.6.1 and 2.7.1. This shouldn't even matter here since IMHO it should work even if Ref were a function (and it works if Ref is a function), it should always work as long as the expression before the ^ is a pointer type. And interestingly this works also (as it should): type TMyClass = class private FRef: Pointer; public property Ref: Pointer read FRef write FRef; end; var MyClass1, MyClass2: TMyClass; procedure test; begin Move(MyClass1.Ref^, MyClass2.Ref^, 1); end; but Move(MyClass1.Ref, MyClass2.Ref, SizeOf(TMyClass.Ref)); will give an error (as it should), no matter how its internally represented because the code that is using this property should not be expected to make assumptions about internal compiler optimizations, it should always treat it like a property. But your example should work, IMHO you have found a bug. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Can't take the address of constant expressions
2012/9/25 patspiper patspi...@gmail.com: procedure test; begin Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1); end; and if you cast it to some other pointer type before dereferencing the error goes away: procedure test; begin Move(MyClass1.Ref.Data^, PByte(MyClass2.Ref.Data)^, 1); end; But this should not be necessary. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
2012/9/25 Graeme Geldenhuys gra...@geldenhuys.co.uk: Thanks for the tip, but Git is *not* difficult to use. To cover the average developer workflow, you need like 3-4 commands max. If you can't remember 4 commands, then you have bigger issues than git. I know that git is not as complicated as it initially seems but by default it is doing its best to be as cryptic, strange behaving and unaccessible as possible. I almost believe Linus did this on purpose. It needed easygit to finally make me comfortable with git and see its advantages. For example svn commit versus git status git stage whatever needs to be staged git commit or git commit -a versus eg commit eg commit is much more intelligent, it will immediately commit -a if it detects that there is nothing staged yet but it will warn and ask you when it detects unstaged changes and something else *is* already staged. then there are subtle differences regarding which remote branches to pull from and push to by default, git has some totally unintuitive defaults and surprising behavior for many things while eg would just do the right thing[TM]. and btw the git help you mentioned is the worst help I have seen so far in the last 30 years. Try eg help to see how helpful help needs to look like. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 25 Sep 2012, at 20:15, Bernd wrote: I know that git is not as complicated Please move this discussion to fpc-other, thanks. Jonas FPC mailing lists admin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Can't take the address of constant expressions
On 25/09/12 20:43, Bernd wrote: 2012/9/25 patspiper patspi...@gmail.com: procedure test; begin Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1); end; and if you cast it to some other pointer type before dereferencing the error goes away: procedure test; begin Move(MyClass1.Ref.Data^, PByte(MyClass2.Ref.Data)^, 1); end; But this should not be necessary. Thanks for the feedback. Submitted as: http://bugs.freepascal.org/view.php?id=22979 Stephano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On Tue, 2012-09-25 at 09:41 +0100, Graeme Geldenhuys wrote: then do... cd pas-libusb git checkout libusb-1.0 Thanks Graeme (and Henry). Obviously I'm new to git and tried commands similar to svn which didn't work quite as expected. Regards, Christo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On Sun, 2012-09-23 at 23:26 +0200, Johann Glaser wrote: Hi! Some time ago somebody asked about USB support. I've now finished the libusb 1.0 header translation and object-oriented wrapper. Hi Hansi, I see that the imported functions in libusb.pas are declared with the cdecl calling convention. According to the libusb header this is so for all operating systems except windows which is apparently compiled using the stdcall calling convention. Any ideas on how to define the calling convention in the import unit so that it is either stdcall or cdecl depending on the target OS? Regards, Christo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
I have not seen any evidence that it has ever been used other than for CSV, but I may be wrong. So I suspect that this should be acceptable. From a simple and unexperienced user point of view, the many times I used the SDF dataset were only to load a CSV into a TMemDataset or similar for further computing. I found it simpler than CSVDocument (which anyway I discovered later) because I can setup everything in the form designer and I only have to change che filename I need at runtime. A simple call to copyfromdataset will then copy the real data to the working dataset. Finally, when everything is done, I use a TCSVExporter (also completely filled in at design time and bound to the working dataset) by calling its Execute method. Very selfishly, If you drop the fixed length support, I won't notice it; while if you rename the TSDFDataset to a TCSVDataset, then I have to tweak rebuild a few bit-tons of code. R# Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
Hi! Am Dienstag, den 25.09.2012, 21:57 +0200 schrieb Christo: On Sun, 2012-09-23 at 23:26 +0200, Johann Glaser wrote: Hi! Some time ago somebody asked about USB support. I've now finished the libusb 1.0 header translation and object-oriented wrapper. Hi Hansi, I see that the imported functions in libusb.pas are declared with the cdecl calling convention. According to the libusb header this is so for all operating systems except windows which is apparently compiled using the stdcall calling convention. Any ideas on how to define the calling convention in the import unit so that it is either stdcall or cdecl depending on the target OS? Thanks for pointing this out. I only have access to Linux and don't know anything about Windows development. So, I ask you (and anybody else) on the best and cleanest way to make libusb.pas working in Linux and other OS. Thanks Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] libusb header translation and OOP wrapper
On 25 September 2012 20:57, Christo christo.cra...@gmail.com wrote:
Any ideas on how to define the calling convention in the import unit so
that it is either stdcall or cdecl depending on the target OS?
I've used a macro for this in the past. E.g. :
{$macro on}
{$ifdef windows}
{$define CCONV:=stdcall}
{$else}
{$define CCONV:=cdecl}
{$endif}
Then use CCONV where you would specify the calling convention.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: Can't take the address of constant expressions
2012/9/25 Bernd prof7...@gmail.com: 2012/9/25 patspiper patspi...@gmail.com: procedure test; begin Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1); end; and if you cast it to some other pointer type before dereferencing the error goes away: procedure test; begin Move(MyClass1.Ref.Data^, PByte(MyClass2.Ref.Data)^, 1); end; But this should not be necessary. Why not? The error is correct. By using the type cast you tell the compiler you know what you are doing and that is should not bother doing the sanity check. So IMO, not a bug. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
