RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value toftVariantdatatype varbytes-still stuck
What I propose is: 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! 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. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigning value toftVariantdatatype varbytes-still stuck
In our previous episode, Ludo Brands said: PS: no misunderstanding. I'm volunteering to make these changes;) I'd be happy to help with testing at least! 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigningvalue toftVariantdatatype varbytes-still stuck
In our previous episode, Ludo Brands said: PS: no misunderstanding. I'm volunteering to make these changes;) I'd be happy to help with testing at least! 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. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] ftGuid displaytext output
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
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: RE : RE : RE : RE : [fpc-pascal] Re: RE : RE : RE : Assigningvalue toftVariantdatatype varbytes-still stuck
In our previous episode, Ludo Brands said: 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. First, the message came out a bit harsher than I meant it to be. Still it is not fun to read a comment like that after working on something for over a week. 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. It happens. I can imagine some TDBF bug submitters being quite frustrated too. Negative sentiment is not even limited to fcl-db: http://zeos.firmos.at/viewtopic.php?t=3157start=0postdays=0postorder=aschighlight= Anyway, still it is important to realize that committers are volonteer, and have their own responsibilities too. Preferably test(which is harder for databases), but at least have an idea about what they are committing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Non-standard baud rates in OS X | IOSSIOSPEED IOCTL
Apple have define an IOCTL (since Tiger) called IOSSIOSPEED which
facilitates non-standard baud rates.
They publish a C example which explains it:
http://developer.apple.com/library/mac/#samplecode/SerialPortSample/Introduction/Intro.html
Attached is a patch for FPC's darwin RTL which adds this IOCTL.
I think it's correct (i.e. it evaluates to the same value, 0x80045402,
as some C I threw together using Apple's headers, see attached).
I've appended this definition in termios.inc as this seems the most
appropriate place for it. Jonas?
Cheers, Bruce.
*** a/rtl/darwin/termios.inc Mon Aug 15 15:05:10 2011
--- b/rtl/darwin/termios.inc Mon Aug 15 15:05:10 2011
***
*** 601,605
--- 601,609
FIOGETOWN = (IOC_OUT or (sizeof(cint) and IOCPARM_MASK) 16) or ((ord('f') 8) or 123);
FIODTYPE = (IOC_OUT or (sizeof(cint) and IOCPARM_MASK) 16) or ((ord('f') 8) or 122);
+ // from /System/Library/Frameworks/IOKit.framework/Versions/A/Headers/serial/ioss.h
+
+ FIOSSIOSPEED = (IOC_IN or (sizeof(culong) and IOCPARM_MASK) 16) or ((ord('T') 8) or 2);
+
{$endif}
#include stdio.h
#define IOCPARM_MASK 0x1fff /* parameter length, at most 13 bits */
#define IOC_IN (unsigned long)0x8000
#define _IOC(inout,group,num,len) \
(inout | ((len IOCPARM_MASK) 16) | ((group) 8) | (num))
#define _IOW(g,n,t) _IOC(IOC_IN, (g), (n), sizeof(t))
#define IOSSIOSPEED_IOW('T', 2, speed_t)
typedef unsigned long speed_t;
int main()
{
printf(IOSSIOSPEED = 0x%x\n,IOSSIOSPEED);
return 0;
}
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
