[fpc-devel] Problems with ImageMagick MagickWand
Hi there, I presently require ImageMagick to be installed along with my software. The reason why I use it is merely to resize images from cameras downto about 1024xY where Y varies to keep aspect ratio intact. I used to use FPImage to stretchdraw on a canvas but at the time it was really slow. Slowing down directory listings in the cloud (images served via http are converted in real-time) My scaling needs are called hundreds of times concurrently for thumbnails as well. So whenever the user opens a file the server must generate 1 thumbnail for each image in the directory. ImageMagick works fast on Linux and Windows. Presently I cannot get even a simple program that uses ImageMagick to build on darwin. I suspect the /ImageMagick/config build the libraries to x86_64. It would be nice if i could remove my dependency of ImageMagick. Does anyone know the status of FPImage etc. to speed up image scaling native to FPC? Bug report on ImageMagick linker error with sample program : http://bugs.freepascal.org/view.php?id=25373 Thanks very much, Andrew Brunner ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC Darwin/Linux Installations
I wanted to see if it is possible to put in a feature request to modify the present installation of FPC to include the actual binary "fpc" program into the directory where ppc386, ppcppc, and ppcx64 binaries. Presently, under linux I am able to use symbolic links to make my system point to 32bit or 64bit compiler ../lib/fpc/2.6.2/ppc386 ../lib/fpc/2.6.2/ppcx64. I've been doing this for a long time with no problems. Recently, I was instructed by Jonas that "fpc" was more than ppcx64 or ppc386 and it proved problematic for me to use a link to the desired compiler to "swap" versions. I have a "reset-fpc.sh" script that replaces symbolic links to fpc, ppc386 and ppcx64. But now that I know fpc binary needs to be "restored" instead of point to. So, I realize that there is no "fpc" binary copy placed into the library folder. Which leads me to proposing that it should be. I wonder what actually builds "fpc" binary and included (fp*) tools presently shipped... And if "fpc" binary is different than ppcx64 than why do I have no build problems on my Linux box but am unable to build fpc on a darwin box? Thanks for any input, Andrew Brunner ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with building x86_64 on darwin
On 11/25/13, 3:42 PM, Jonas Maebe wrote: Using simply wrong hyperboles is not productive. I explained in my previous message, which you quoted below, why you cannot use a cross-compiler (such as the ppcx64 included with FPC releases on Mac OS X) to build FPC from trunk without using a special make option, and which exact make option you have to add so that it does work. Alternatively, use a cross-compiler like the one you built above. It's x86-64 binaries will be exactly the same as the ones generated by a native x86-64 compiler. Yeah, I missed that point. From an end-user prospective though my assertion makes a lot of sense. Using 2.6.2 in production builds here is not possible. My code-base uses HEAVY namespace implements. 2.7.1 is the only thing that compiles my projects. make clean all DEBUG=1 OS_TARGET=darwin CPU_TARGET=x86_64 CPU_SOURCE=x86_64 Removing the PP=... was the only way I could get :-) build-stamp.x86_64-darwin Thanks Jonas! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with building x86_64 on darwin
On 11/25/13, 2:56 PM, Jonas Maebe wrote: On 25 Nov 2013, at 21:28, Andrew Brunner wrote: I've got darwin Mac OS 10.9 running fpc 2.6.2 installed and compiling from the downloads section of the site. I'm trying with no success to get 2.7.1 to compile ppcx64 with /usr/local/bin/fpc ->/usr/local/lib/fpc/2.6.2/ppcx64 First of all, reinstall FPC so that /usr/local/bin/fpc is valid again. "fpc" is an independent program and can never be a symbolic link to a compiler binary. It supports parameters that the compiler binaries do not support. You cannot overwrite it with a symbolic link. I re-installed and it replaced the symlink with the fpc binary. I retried to build FPC with no luck. Same error as before. - FPC BUILD PROBLEMS Trying to build my svn/fpc/trunk version make all OPT="-O-" DEBUG=1 OS_TARGET=darwin CPU_TARGET=x86_64 PP=/usr/local/lib/fpc/2.6.2/ppcx64 /usr/local/lib/fpc/2.6.2/ppcx64 -dNOMOUSE -Ur -dFPC_USE_LIBC -gl -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fi../bsd -Fi../bsd/i386 -Fi../darwin/i386 -FE. -FU/Developer/FPC/rtl/units/i386-darwin -O- -di386 -dDEBUG -dRELEASE -Us -Sg ../bsd/system.pp system.inc(171,4) Fatal: Can't open include file "x86_64.inc" Fatal: Compilation aborted make[5]: *** [system.ppu] make all OPT="-O-" DEBUG=1 OS_TARGET=darwin CPU_TARGET=x86_64 PP=/usr/local/lib/fpc/2.6.2/ppc386 works perfectly. Why doesn't ppcx64 work at all? Lazarus Build Problems That's because ppcx64 on Mac OS X is an i386->x86-64 cross-compiler and the Makefiles are not designed for bootstrapping with cross-compilers. You can work around it by adding CPU_SOURCE=x86_64, but you can just as well build a new cross-compiler. I just need something that works. It's a goal to have 64bit support for my downloads. I like to have a 64bit build of FPC like on Linux. Lazarus cannot yet be compiled for x86-64 on Mac OS X (except if you compile it for GTK or Qt, possibly). Unless you are editing files that are larger than 1.5GB, it's unlikely you'd notice any difference either. Ok. At least I know it's not supported yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with building x86_64 on darwin
I've got darwin Mac OS 10.9 running fpc 2.6.2 installed and compiling from the downloads section of the site. I'm trying with no success to get 2.7.1 to compile ppcx64 with /usr/local/bin/fpc ->/usr/local/lib/fpc/2.6.2/ppcx64 which fpc shows... /usr/local/bin/fpc contents of /usr/local/bin/ include... lrwxr-xr-x 1 root wheel 31 Nov 25 14:06 fpc -> /usr/local/lib/fpc/2.6.2/ppcx64 lrwxr-xr-x 1 root wheel 31 Nov 25 08:28 pp386 -> /usr/local/lib/fpc/2.6.2/ppc386 lrwxr-xr-x 1 root wheel 31 Nov 25 14:06 ppc386 -> /usr/local/lib/fpc/2.6.2/ppc386 lrwxr-xr-x 1 root wheel 31 Nov 25 14:06 ppcx64 -> /usr/local/lib/fpc/2.6.2/ppcx64 The line in my install script that creates the fpc.cfg sudo /usr/local/lib/fpc/2.6.2/samplecfg /usr/local/lib/fpc/2.6.2 /etc The /etc/fpc.cfg looks good with the exception of a missing lib folder -Fl/usr/local/lib/fpc/$fpcversion/lib/$FPCTARGET There is no /usr/local/lib/fpc/2.6.2/lib folder - FPC BUILD PROBLEMS Trying to build my svn/fpc/trunk version make all OPT="-O-" DEBUG=1 OS_TARGET=darwin CPU_TARGET=x86_64 PP=/usr/local/lib/fpc/2.6.2/ppcx64 /usr/local/lib/fpc/2.6.2/ppcx64 -dNOMOUSE -Ur -dFPC_USE_LIBC -gl -Ur -Xs -O2 -n -Fi../inc -Fi../i386 -Fi../unix -Fi../bsd -Fi../bsd/i386 -Fi../darwin/i386 -FE. -FU/Developer/FPC/rtl/units/i386-darwin -O- -di386 -dDEBUG -dRELEASE -Us -Sg ../bsd/system.pp system.inc(171,4) Fatal: Can't open include file "x86_64.inc" Fatal: Compilation aborted make[5]: *** [system.ppu] Lazarus Build Problems Trying to build my svn/lazarus/trunk verison Much compiles but linking fails towards the end with error: Compiling resource ../units/x86_64-darwin/nogui/lazbuild.or Linking ../lazbuild Undefined symbols for architecture x86_64: "_LSOpenCFURLRef", referenced from: _LCLINTF_OPENURL$ANSISTRING$$BOOLEAN in lclintf.o ld: symbol(s) not found for architecture x86_64 An error occurred while linking lazbuild.lpr(1629) Error: Error while linking lazbuild.lpr(1629) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: *** [lazbuild] Error 1 make[1]: *** [lazbuilder] Error 2 make: *** [lazbuild] Error 2 Any thoughts would be greatly appreciated. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problem TProcess (AGAIN)
I'm running into a problem with TProcess again. A while ago TProcess's commandline property was deprecated. Something stopped working so I switched to Executable and Parameters in all my apps. Now, Parameters don't work and commandline is the only way to get the command to launch properly. This is on Linux x64. Anyone doing work that needs to fix something? The only thing I can see in debugging is that ppchar is declared and somehow parameters are assembled as an array of strings... That most likely is the culprit. Most api would require just 1 null terminated pchar concatenated with spaces Please fix.... -- Andrew Brunner Aurawin LLC 19309 Stage Line Trail Pflugerville, TX 78660 https://aurawin.com/ Aurawin is a great new way to store, share, and explore all your content featuring our innovative cloud social computing platform. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory Streams unable to handle reads past 2GB
Same problem with TMemoryStream.Write :-( On 11/05/2012 10:09 PM, Andrew Brunner wrote: objpas/classes/classesh.inc TCustomMemoryStream function Read(var Buffer; Count: LongInt): LongInt; override; Having Read result declared as LongInt is problematic on 64 bit systems with large streams. Read result MUST be either PtrInt or Int64 but it cannot be LongInt. Please fix, Thanks -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new way to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Memory Streams unable to handle reads past 2GB
objpas/classes/classesh.inc TCustomMemoryStream function Read(var Buffer; Count: LongInt): LongInt; override; Having Read result declared as LongInt is problematic on 64 bit systems with large streams. Read result MUST be either PtrInt or Int64 but it cannot be LongInt. Please fix, Thanks -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new way to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
I just added this Prepare method to my database API.
class function XML.IsInvalid(var Value:Byte):boolean;
begin
Result:=(Value<9) or (Value=11) or (Value=12) or ( (Value>13) and
(Value<32));
end;
class function XML.Prepare(var sInput:string; Refactor:TStream):string;
var
bChar:byte;
iLcv:Int64;
iLen:Int64;
sReplace:string;
begin
Refactor.Size:=0;
for iLcv:=1 to System.Length(sInput) do begin
bChar:=Byte(sInput[iLcv]);
if IsInvalid(bChar) then begin
sReplace:=Concat('&#',IntToStr(bChar),';');
iLen:=System.Length(sReplace);
Refactor.Write(sReplace[1],iLen);
end else
Refactor.Write(bChar,1);
end;
System.SetLength(Result,Refactor.Size);
if Refactor.Size>0 then
Refactor.Read(Result[1],Refactor.Size);
Refactor.Size:=0;
end;
The question is, what is going to happen when the encoding is UTF8 or
UTF16? Will this code allow bytes to go by without messing them all up?
--
Andrew Brunner
Aurawin LLC
512.574.6298
http://aurawin.com/
Aurawin is a great new way to store, share, and enjoy your
photos, videos, music and more.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
On Nov 2, 2012, at 6:39 PM, waldo kitty wrote: > On 11/2/2012 09:32, Sergei Gorelkin wrote: >> In other words, XML is wrong technology to work with binary data, unless it >> is >> encoded into textual form (Base64 or alike). > > encoding into textual form one increases the size of the stream by at least > 1/3rd... a 3M file will be a 4M stream Thats all true buy binary xfer is not doable on some mail servers. My server uses deflate stream compression. I have multicore servers. My larger problem are these datagram Thats all true buy binary xfer is not doable on some mail servers. My server uses deflate stream compression. I have multicore servers. My larger problem are the datagram values containing strings that fail. So with encoding of binary inflated - I would still have to parse each byte. To me that is the problem. Andrew Brunner Aurawin LLC 512.574.6298 A safe new way to store and share your files, pictures, videos and more. http://aurawin.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
So where in the specs does it say that parsers must reject certain byte sequences between cdata tags excepting XML tags. If this is supported by specs it would help shape a viable solution. On Nov 2, 2012, at 9:01 AM, Sergei Gorelkin wrote: > 02.11.2012 17:44, Mattias Gaertner пишет: >> >> Sergei Gorelkin hat am 2. November 2012 um 14:32 >> geschrieben: >>> In this case, the issue is not encoding, but literal ESC (#27) code used in >>> data. XML specification >>> does not allow codepoints below 32, except TAB,CR and LF, to appear in data, >>> both in literal and >>> escaped forms. >> >> Actually the specification only defines legal characters and that processors >> must accept them. >> It does not say what to do with the other characters. >> > Besides specification, there is a test suite containing lots of tests with > illegal characters and expecting them all to fail. > > Regards, > Sergei > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
On Nov 2, 2012, at 8:32 AM, Sergei Gorelkin wrote: > > In this case, the issue is not encoding, but literal ESC (#27) code used in > data. XML specification does not allow codepoints below 32, except TAB,CR and > LF, to appear in data, both in literal and escaped forms. > In other words, XML is wrong technology to work with binary data, unless it > is encoded into textual form (Base64 or alike). > Ok. The data comes from a summary function that grabs a few pieces of an email message on this case. The subject an top 2 lines of the message. Email is text so it would most likely be memory corruption as the source of any low order bytes like 0. But actual file data when streamed is done so via MIME. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
On 11/02/2012 08:08 AM, Michael Van Canneyt wrote:
There is no attachment to your mail.
The attachment was in my first posting. But just in cease I've attached
it again.
Please feel free to check it out.
The example is stripped of most of the xml code that was successfully
parsed. This was from about a 5mb stream. I grabbed the xml code
surrounding the error position.
Thanks Michael.
program unknown;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes,DOM, XMLRead;
procedure Test();
var
FXMLParser : TDOMParser;
FXMLDocument : TXMLDocument;
FXMLSource : TXMLInputSource;
sData: String;
begin
sData:=Concat(
'',
'',
'',
''
);
sData:=System.AnsiToUtf8(sData);
FXMLParser:=TDOMParser.Create();
Try
FXMLSource:=TXMLInputSource.Create(sData);
Try
FXMLParser.Parse(FXMLSource,FXMLDocument);
Try
Finally
FXMLDocument.Free();
end;
Finally
FXMLSource.Free();
end;
Finally
FXMLParser.Free();
end;
end;
begin
Test();
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
On Nov 2, 2012, at 7:24 AM, Michael Van Canneyt wrote: > > > On Thu, 1 Nov 2012, Andrew Brunner wrote: > >> I'm having a problem getting the XML parser to read. >> >> Is there any way I can get the attached program to work by changing a >> parsing option to one less strict. My XML documents get over 1-2 GBs since >> they represent files. So having to convert /scan each byte is unacceptable. > > I suggest you revert to something else than XML, if that's an option. > XML is notoriously slow to load. > I don't know if at this point I am able to switch. It's not practical. I could just grab PFC XML components and derive something outside FPC project scope. >> >> Is there another XML parser component that can establish a DOM? Or is this >> a bug in the fpc XML component? > > This is not a bug, it is prescribed behaviour. The function AnsiToUtf8 is supposed to convert data to utf. So the string in the sample should have the proper UTF8 encoding. And the parser should be able to read it. In the past, I was able to parse ANSI strings but only after converting to UTF8. But the attached program fails. 100% > > The XML components must work on any XML document that exists out there. > As a consequence, the codepage in the XML must be checked and converted if > need be. > The input data in the example attached is converted. > Imagine you have a XML file encoded in UTF16, and we assume it's UTF-8. The > resulting DOM tree would be unusable. > True. >> Any help or feedback is entirely welcome and needed. This data in currently >> in at least 1 stream and failing my cloud desktop sync application. > > You'll have to write your own XML handling routines which work only with the > codepage the XML is in. And be prepared that they will fail as soon as the > encoding of the XML changes. > Right. But converting the data to say UTF8 should have worked. I have explicitly set the encoding to UTF8 in the header. >> >> I would really love an option to disable XML byte for byte checking during >> parsing. I think it would be a good solution and even prove faster in controlled environments. Plus all data is stored as widestrings in the DOM. The first question I have is if there was such an option would the patch be accepted. The next question is what is the problem with the uf8 routine that it left the offending byte sequence intact without converting the bytes in my sample data? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XML Components
I'm having a problem getting the XML parser to read. Is there any way I can get the attached program to work by changing a parsing option to one less strict. My XML documents get over 1-2 GBs since they represent files. So having to convert /scan each byte is unacceptable. Is there another XML parser component that can establish a DOM? Or is this a bug in the fpc XML component? Any help or feedback is entirely welcome and needed. This data in currently in at least 1 stream and failing my cloud desktop sync application. I would really love an option to disable XML byte for byte checking during parsing. -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new way to store, share, and enjoy your photos, videos, music and more. program invalid; var FXMLParser : TDOMParser; FXMLDocument : TXMLDocument; FXMLSource : TXMLInputSource; sData: String; begin sData:=Concat( '', '', '', '' ); sData:=System.AnsiToUtf8(sData); FXMLParser:=TDOMParser.Create(); Try FXMLSource:=TXMLInputSource.Create(sData); Try FXMLParser.Parse(FXMLSource,FXMLDocument); Try Finally FXMLDocument.Free(); end; Finally FXMLSource.Free(); end; Finally FXMLParser.Free(); end; end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Parser problems with C-Data and Character Encoding
On 09/27/2012 04:19 AM, Mattias Gaertner wrote: Have you tried setting the right encoding in the xml? > http://mantis.freepascal.org/view.php?id=22990 I have, and it did and it did work (thanks Sergei :-) Maybe you can explain what you are trying to do? I have a cloud social virtual operating system and each read/write operation is done via XML. So adding content encoding mechanism for comparing each byte is extremely costly from a client/server standpoint. Just imagine 1M+ users and having to encode/decode each xml fragment just to get the parser to parse the data - unwanted latency. AFAIK such statements have seldom a positive effect on volunteer projects. My frustration is not with FPC team, because they are drawing code from projects like firefox. I am extremely sensitive towards wasted cpu cycles as efficiency in scale is maximized by reducing things like byte encoding. Some of my stream fragments can be as large as 1.4MB deflated from 8MB. Multiply that number by say 100 concurrent users on that 1 node and you'll begin to see my frustration. To me, an XML parser is just looking for "<>" etc. Once it hits a CDATA section it should only look for ]]. Therefore I was surprised to learn that it required the encoding tag (which in itself just increased the average network packet size) that I must transmit from client to my server nodes. A good XML parser would not care what is between core essentials. Content encoding is for human readability it is not for computers nor should it ever be a concern to something as low level as an XML parser. This is best for the Internet and it's servers - not my opinion. Well, whatever you try, you must at least encode all < > and & characters. Right. I guess when it comes to my assertions regarding all this - I am looking for an AHH OK notion as to why my servers have to decode/encode/stamp each XML fragment just so a parser - that is a machine that does not care what a euro looks like - can process it correctly. I suppose we could talk about interoperability here. And of course it seems like an a-ha moment. But these are XML fragments that were created in my system. And I think for the sake of the developer of an app - should have tweaks for efficiency aside from the content encoding de'joure (UTF8). I realize my poignancy could be harsh but this is an expensive problem for me. Each server can cost as much as $4,000 US. -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new place to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XML Parser problems with C-Data and Character Encoding
From time to time I get XML parsing exceptions even though I disabled data validation. If c-data contains any character whose ordinal value is greater than 127 the XML parser raises an exception. I realize fpc's parser is not the only one with this problem. So who's infinite wisdom decided that C-Data cannot have non-keyed input!?! Is there a ANY case where dropping c-data is OK just because a user hasn't entered it? I'm just curious... I can't seem to find any good reason as to why this happened other than to force UTF or some other encoding on everyone. The XML parser already has options for Validation. I'm hoping to get someone on the team to add a one line if Validation=true then check the values else just parse it already. http://mantis.freepascal.org/view.php?id=22990 Another thing would be to have an exception level event. There is an event there, but still the exception is raised the event is called - stopping the parsing and throwing a wrench in my streaming application logic. In a world where XML is just about the primary choice for data transmission - I think we take speed as the ut-most priority and don't use such a pivotal technology as a tool to get what someone else wants. The bottom-line inference here is that WE ALL must encode ALL DATA before it can be streamed / parsed. That's bad news and EXPENSIVE. Therefore, any help would be greatly appreciated. -- Andrew Brunner Aurawin LLC 512.574.6298 http://aurawin.com/ Aurawin is a great new place to store, share, and enjoy your photos, videos, music and more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with data validation in XML streams namely CDATA
There is no way to have CDATA with charaters past 127. Anyone know the
rationale?
Is there anyway to get the parser to respect Validate=false for
charaters beyond 127?
Thanks,
--
Andrew Brunner
Aurawin LLC
512.574.6298
http://aurawin.com/
Aurawin is a great new place to store, share, and enjoy your
photos, videos, music and more.
program invalid;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, DOM, XMLRead, XMLReader;
procedure Test;
var
FParser:TDOMParser;
FDoc : TXMLDocument;
FSource : TXMLInputSource;
sData:string;
begin
FParser:=TDOMParser.Create();
Try
FParser.Options.Validate:=false;
sData:=Concat(
'',
'',
'',
''
);
// sData:=AnsiToUTF8(sData);
FSource:=TXMLInputSource.Create(sData);
Try
FParser.Parse(FSource,FDoc);
Try
finally
FDoc.Free();
end;
finally
FSource.Free();
end;
finally
FParser.Free();
end;
end;
begin
Test();
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On Sep 26, 2012, at 8:24 AM, Graeme Geldenhuys wrote: > > Why not do the best of both worlds. Setup a NNTP server, then use fpWeb (or > even plain CGI will do) to create a NNTP Web Client (aka Web Forum). Now all > based are covered - users can use the communication medium they prefer, and > fpWeb (if used) gets another nice "real world" demo. It is great when you showcase your work. Another benefit is when you adopt industry standards like nnntp. Interoperability seems to have lost luster recently. > The WebNews HTTP front-end I use for my NNTP server is a very simple (and > rather small - 1063 line of perl including code comments) Perl script. It > acts as an ordinary NNTP client (so the NNTP server doesn't know the > difference), and the HTML in generates is rather plain too. I simply > dressed-up the HTML some basic CSS, to make it that little bit prettier. I think it should at least be professional looking. Taking a minimalist view would only bring the same complaints. > Hell, I don't even mind writing the CGI NNTP Client frontend, because I have > long been wanting to replace my Perl implementation with an Object Pascal > version. Again it would be best to get a team together and do something nice rather than simple. Andrew Brunner, Aurawin LLC http://aurawin.com/ A great place to store and share your pictures, videos, and more, featuring a rich cloud social computing platform. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL Unicode support
I've been keeping up with this topic for a while now and I haven't read any suggestions similar to how I envision encoding support. I think it's best to keep ansi strings intact. I also think it's best to create a string encoding class factory for people to draw upon for conversions. I don't think seamless conversion between types is presently required. I think looking at all the different technologies it would be wise for FPC to just support the encoding of ANSI strings to match that of popular ones. A "featured" encoding system would include character sets for Internet releated apps 'UTF-8', 'UTF-16', 'UTF-16BE', 'UTF-16LE', 'ISO-8859-1', 'ISO-8859-2', 'ISO-8859-3', 'ISO-8859-4', 'ISO-8859-5', 'ISO-8859-6', 'ISO-8859-7', 'ISO-8859-8', 'ISO-8859-8_1', 'ISO-8859-9', 'ISO-8859-10', 'ISO-8859-11', 'ISO-8859-12', 'ISO-8859-13', 'ISO-8859-14', 'ISO-8859-15', 'ISO-8859-16', 'ISO-2022-KR', 'ISO-2022-JP', 'ISO-2022-CN', 'csISO_IR_111', 'Windows-874', 'Windows-1250', 'Windows-1251', 'Windows-1252', 'Windows-1253', 'Windows-1254', 'Windows-1255', 'Windows-1256', 'Windows-1257', 'Windows-1258', 'EUC-KR', 'EUC-JP', 'EUC-TW', 'TIS-620', 'UHC', 'JOHAB', 'TCVN', 'VPS', 'CP-866', 'ARMSCII-8', 'USASCII', 'VISCII', 'HZ', 'GBK', 'Big5', 'Big5_HKSCS', 'GB2312', 'GB18030', 'KO18-R', 'KO18-U', 'IBM-850', 'IBM-852', 'IBM-855', 'IBM-857', 'IBM-864', 'IBM-862', 'MacCE', 'MacRoman', 'MacRomanian', 'MacTurkish', 'MacIcelandic', 'Shift-JIS', 'MacCyrillic', 'MacCroatian', 'MacDevanagari', 'MacGurmukhi', 'MacGujarati' Going between these via (streams or memory), and some or most of these would be the ideal. I'm thinking - borrow your design from the Image class factory system. Using fpImage class system I can go from PNG to JPG with just extensions and grab classes and create instances of converters there. In the Internet app development realm we have blocks of text that we already know what the encoding is supposed to be. Take for example a MP3 music file with ID3 Tag for a generic string. It would be declared as ANSI, UTF8 or UTF16. Codec:=StringCodecFactory.getHandler(ANSI) Codec:=StringCodecFactory.getHandler(UTF8) Codec:=StringCodecFactory.getHandler(UTF16) Codec:=StringCodecFactory.getHandler(UTF32) Codec.Pos(..) Codec.PosEx() Codec.Replace() Codec.Copy() Codec.Delete() Codec.Read(ContentType,Stream/string) overload; Codec.Write(ContentType,Stream/string) overload; Codec.AsString Codec.Encode() // ie.) ansi or UTF8 Codec.Decode() // ie.) ISO-8859-1 will remove all the =20 and = for word-wrapping etc. Ideally, during design time, I could "case" all 3 types and just reference the desired class for POS, Replace, PosEx. The beneifts of isolating all the desired encoding types would be ease of debugging, ease of growth, teams could target specific methods, and if the factory return no encoding method it's not supported. I'm at the point where I have extreme disparity codecs for various forms of communications. My ideal would be such a system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Building a new node... came up with this new error
Problem solved. This time I used the downloaded install scripts from
sourceforge. It came with a install script option to /usr or /usr/local.
My systems are /usr/local... Too keyboard happy :-) My bad.
On Tue, Jul 24, 2012 at 4:51 PM, Andrew Brunner
wrote:
> $ fpc
>
> Fatal: In options file /etc/fpc.cfg at line 29 unexpected \var{\#ENDIFs}
> encountered
>
> Shell script that made cfg
>
> sudo $FPC_CONFIG -d basepath=$FPC_DIR -o $FPC_DIR/fpc.cfg
> sudo $FPC_CONFIG -d basepath=$FPC_DIR -o /etc/fpc.cfg
>
> I never had this problem before... What gives?
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Building a new node... came up with this new error
$ fpc
Fatal: In options file /etc/fpc.cfg at line 29 unexpected \var{\#ENDIFs}
encountered
Shell script that made cfg
sudo $FPC_CONFIG -d basepath=$FPC_DIR -o $FPC_DIR/fpc.cfg
sudo $FPC_CONFIG -d basepath=$FPC_DIR -o /etc/fpc.cfg
I never had this problem before... What gives?
fpc.cfg
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] i386 build Mac OSX 10.7 Lion problem with univint
After compiling I don't have IconsCore in /usr/local/lib/fpc/2.7.1/units/i386-darwin/univint I use the Journaled Case Sensitive file system. FPC 2.6 works though. I just recently started having this problem. Start compiling package univint for target i386-darwin. Warning: Source file "CTFrameSetter.pas" from package univint not found for i386-darwin Compiling univint/src/MacOSAll.pas Compiling univint/src/MacOS.pas Compiling univint/src/IconsCore.pas Compiling univint/src/IconStorage.pas [ 9%] Compiled package univint So it did compile. Something happened with the make install process. Any ideas... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problem with building lazarus/trunk with fpc/trunk on Darwin
Mac OSX 10.7.4 FPC svn/trunk just updated Lazarus svn/trunk just updated Free Pascal Compiler version 2.7.1 [2012/05/20] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Darwin for i386 Compiling alllclunits.pp Assembling (pipe) units/i386-darwin/alllclunits.s 41 lines compiled, 1.0 sec /bin/cp -f Makefile.compiled units/i386-darwin/LCLBase.compiled make -C interfaces all make -C carbon all /bin/rm -f ../../units/i386-darwin/carbon/lcl.ppu \ ../../units/i386-darwin/carbon/lcl.o /usr/local/bin/fpc -gl -dcarbon -Fu../../units/i386-darwin -Fu../../../packager/units/i386-darwin -Fu../../../components/lazutils/lib/i386-darwin -Fuobjc -Fupascocoa/appkit -Fupascocoa/foundation -Fu.. -Fu. -Fu/usr/local/lib/fpc/2.7.1/units/i386-darwin/rtl -Fiobjc -Fipascocoa/appkit -Fipascocoa/foundation -FE. -FU../../units/i386-darwin/carbon -di386 ../lcl.pas Free Pascal Compiler version 2.7.1 [2012/05/20] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Darwin for i386 Compiling ../lcl.pas Compiling alllclintfunits.pas Compiling carbonwsarrow.pp Assembling (pipe) ../../units/i386-darwin/carbon/carbonwsarrow.s Compiling carbonprivate.pp Fatal: Can't find unit IconsCore used by CocoaAll Fatal: Compilation aborted make[3]: *** [../lcl.ppu] Error 1 make[2]: *** [carbon_all] Error 2 make[1]: *** [interfaces] Error 2 make: *** ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with nested classes and const struct values
> > It's best to file a bug report. > > > http://bugs.freepascal.org/view.php?id=21941 Thanks Jonas, I thought it would be an easy fix. I really enjoy this feature in FPC. It's worth it to me to get these problems worked out. Not to mention having to re-write really pretty code :-( I'm able to build with 2.6. However, I can't test 2.7 anymore until this particular error is resolved. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Problem with nested classes and const struct values
Ok, Attached is a sample program that demonstrates the problem. FPC 2.6.0 compiles just fine. FPC Trunk has a problem. The attachment of the unit in this thread prior SHOULD work but did not because there is a secondary problem in that once I moved the primary decs into a header file the using unit was able to compile in 2.6 but not 2.7. Adding the contents of hTest to the project's types will make the make FPC 2.6 and 2.7 not compile. I need 2.7 to compile with nested classes. You can fix the secondary problem if you want.. but I absolutely need 2.7 to compile the newly attached project. Thanks Nested.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with nested classes and const struct values
I just encountered this problem again. I can't build my process application and the attached project still won't compile. Can someone shed some light on this problem? Thanks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with nested classes and const struct values
Yes. I'm completely sure it's working now. But i can't figure out why the small project doesn't. I even tried to make clean for my big project to see if I could make it not work.. but it compiles now. On Mon, Apr 30, 2012 at 11:23 PM, Flávio Etrusco wrote: > FWIW FPC 2.6.0 also triggers the same error. AFAICS this problem is > somewhat analogous to the limitation when declaring members in a > record. Are you sure the unit in your big project is being compiled? > > -Flávio > > On Mon, Apr 30, 2012 at 3:39 PM, Andrew Brunner > wrote: > > Well, > > > > The problem started when I did a fresh install of Ubuntu 12.04. > > The main project that uses similar code to my attached test had FPC raise > > the same error but with similar code. > > Presently, a fresh build of FPC and Lazarus allows me to build my big > > project however, the test project still won't build with > > > > Compiling ./Test.lpr > > Test.lpr(65,36) Error: Incompatible types: got "Pointer" expected > "PCLSInfo" > > Test.lpr(65,44) Error: Illegal expression > > Test.lpr(66,36) Error: Incompatible types: got "Pointer" expected > "PACLInfo" > > Test.lpr(66,44) Error: Illegal expression > > Test.lpr(73) Fatal: There were 4 errors compiling module, stopping > > Fatal: Compilation aborted > > > > But yet my big project with very complex nested declarations compiles > just > > fine > > > > unit coAdmin; > > > > interface > > uses hTimer,hHTTP,hHTTPd,hRSR,uRSR,Classes,uCoreObjects,uKeywords, > > > hSRConsts,uTimer,uStringArray,uVarString,uKPList,hDateUtils,uFileUtils, > > > > > dbmDomains,dbmCoreObjects,dbmUserAccounts,dbmRSS,dbmCalendaring,hDatabase; > > > > Type > > ns=class > > Type > > Admin=class > > const > > XMLInf:TXMLInfo=( > > Enabled : false; > > ); > > ACLInf:TACLInfo=( > > Name : 'Admin'; > > NameSpace: '/core/admin'; > > Caption : 'Administration Core Object'; > > Prompt : 'User can access administration > > dashboard'; > > Description : 'Back-end system administration > handler' > > ); > > CLSInf:TCLSInfo=( > > Name : 'TAdminCore'; > > Location : 'coAdmin.pas'; > > ); > > Header:TCoreObjectInfo=( > > ID : 0; > > ProviderID : 0; > > Enabled : true; > > Anonymous: false; > > NotifyOnBuffersChanged : false; > > Scale: 0; > > CLSInfo : @CLSInf; > > ACLInfo : @ACLInf; > > ); > > > > > > > > On Mon, Apr 30, 2012 at 1:12 PM, Jonas Maebe > > wrote: > >> > >> > >> On 30 Apr 2012, at 16:48, Andrew Brunner wrote: > >> > >> > This problem did not exist a few days ago. > >> > >> Can you be more precise? I just checked with trunk from before the > >> jvmbackend merge (which is from Thursday), and that one also gives an > error. > >> > >> > >> Jonas___ > >> fpc-devel maillist - fpc-devel@lists.freepascal.org > >> http://lists.freepascal.org/mailman/listinfo/fpc-devel > > > > > > > > ___ > > fpc-devel maillist - fpc-devel@lists.freepascal.org > > http://lists.freepascal.org/mailman/listinfo/fpc-devel > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with nested classes and const struct values
Well, The problem started when I did a fresh install of Ubuntu 12.04. The main project that uses similar code to my attached test had FPC raise the same error but with similar code. Presently, a fresh build of FPC and Lazarus allows me to build my big project however, the test project still won't build with Compiling ./Test.lpr Test.lpr(65,36) Error: Incompatible types: got "Pointer" expected "PCLSInfo" Test.lpr(65,44) Error: Illegal expression Test.lpr(66,36) Error: Incompatible types: got "Pointer" expected "PACLInfo" Test.lpr(66,44) Error: Illegal expression Test.lpr(73) Fatal: There were 4 errors compiling module, stopping Fatal: Compilation aborted But yet my big project with very complex nested declarations compiles just fine unit coAdmin; interface uses hTimer,hHTTP,hHTTPd,hRSR,uRSR,Classes,uCoreObjects,uKeywords, hSRConsts,uTimer,uStringArray,uVarString,uKPList,hDateUtils,uFileUtils, dbmDomains,dbmCoreObjects,dbmUserAccounts,dbmRSS,dbmCalendaring,hDatabase; Type ns=class Type Admin=class const XMLInf:TXMLInfo=( Enabled : false; ); ACLInf:TACLInfo=( Name : 'Admin'; NameSpace: '/core/admin'; Caption : 'Administration Core Object'; Prompt : 'User can access administration dashboard'; Description : 'Back-end system administration handler' ); CLSInf:TCLSInfo=( Name : 'TAdminCore'; Location : 'coAdmin.pas'; ); Header:TCoreObjectInfo=( ID : 0; ProviderID : 0; Enabled : true; Anonymous: false; NotifyOnBuffersChanged : false; Scale: 0; CLSInfo : @CLSInf; ACLInfo : @ACLInf; ); On Mon, Apr 30, 2012 at 1:12 PM, Jonas Maebe wrote: > > On 30 Apr 2012, at 16:48, Andrew Brunner wrote: > > > This problem did not exist a few days ago. > > Can you be more precise? I just checked with trunk from before the > jvmbackend merge (which is from Thursday), and that one also gives an error. > > > Jonas___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with nested classes and const struct values
Here's the source... Test.lpr Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problem with nested classes and const struct values
This problem recently appeared in svn/fpc/trunk I tried pointing to: CLSInfo : @Root.Test.CLSInfo ; // Still not working CLSInfo : @Root.Test.CLSInfo1 ;// Renamed dec and still didn't work. This problem did not exist a few days ago. I have a ton of units that don't compile now!!! Please help. atbrunner@Satellite:/Developer/Source/Projects/Test/Nested$ fpc ./Test.lpr Free Pascal Compiler version 2.7.1 [2012/04/30] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling ./Test.lpr Test.lpr(65,43) Error: Illegal expression Test.lpr(65,36) Error: Incompatible types: got "Pointer" expected "PCLSInfo" Test.lpr(65,43) Error: Illegal expression Test.lpr(66,36) Error: Incompatible types: got "Pointer" expected "PACLInfo" Test.lpr(66,43) Error: Illegal expression Test.lpr(73) Fatal: There were 5 errors compiling module, stopping Fatal: Compilation aborted Test.lpi Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPImage unit ImageHandlersManager design problem
Having just looked over the class factory for images in FPC, I found that ImageHandlersManager is missing a critical method to obtain a reader or write by the extension used. Presently the getReader uses the TypeName and not the Extenstion. I find this quite annoying. Can someone please extend the manager to handle a GetReaderByExt(sExt) ? Thanks! I would be willing to do it myself but don't know if it would be accepted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] More namespace issues
Polymorphism and Namespaces don't work. http://bugs.freepascal.org/view.php?id=20940 Is a fix something I can expect shortly? Just want to know how serious the issue is or if I should work around. Thanks ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with namespaces and structs
> Can you report a small but full example to the bug tracker? Yes, I was able to get it to fail with just a simple unit test. It's a lazarus project. http://mantis.freepascal.org/view.php?id=20909 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with namespaces and structs
Probably, I got it to work by declaring the Callback Event Type in the Storage.Folders area and declared that type in the other unit which linked just fine. It appears that the references cannot be located from outside that namespace. On Thu, Dec 15, 2011 at 4:14 PM, Paul Ishenin wrote: > 16.12.11 1:58, Andrew Brunner пишет: > >> class >> storage >> class >> Folders >> Type >> Item=record >> end; >> PItem=^TItem >> TItems=array of PItem >> >> >> Variables in some other unit compile OK. >> >> >> in some other unit: >> type MyCallback=procedure(Var Items:Storage.Folders.TItems); // linking >> fails >> // procedures/functions of these namespaced types fail to link with >> the following messages >> >> >> >> /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x1692): >> undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' >> >> /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x16ca): >> undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' >> >> >> Can Anyone can fix this soon? This particular unit involves heavy >> namespace usage for complex organization. > > > Can you report a small but full example to the bug tracker? > > Best regards, > Paul Ishenin > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with namespaces and structs
class storage class Folders Type Item=record end; PItem=^TItem TItems=array of PItem Variables in some other unit compile OK. in some other unit: type MyCallback=procedure(Var Items:Storage.Folders.TItems); // linking fails // procedures/functions of these namespaced types fail to link with the following messages /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x1692): undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x16ca): undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' Can Anyone can fix this soon? This particular unit involves heavy namespace usage for complex organization. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Trunk build broken @ mysqlconn.inc
Can't build ./trunk/FPC with starting compiler 2.4.4+ mysql40conn.pas mysqlconn.inc(700,37) Error: Incompatible types: got "pculong" expected "PLongWord" Please fix :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-web: A proper way to set SO_REUSEADDR socket option in THTTPApplication
I think you should also look into setting linger options at a lower rate than present values. 120 seconds is too long. 15-30 seconds is a reasonable amount of time to give a dead socket. In fpc componetent design, I would recommend to also make sure that sockets issue SHUT_DOWN for Both read and write before issuing close. The poster's problems are infact, common linux behaviour, and can lead to permant socket non-resuabiltily if the kernel does not get the shutdown and/or close / and linger is not set. Since most kernel developers EXPECT users to close their sockets properly. On Fri, Oct 14, 2011 at 8:53 AM, Vladimir Zhirov wrote: > Hi, > > Currently, if THTTPApplication-based program on Linux was > stopped manually during active connection I cannot > start it again for 1-2 minutes, getting the exception > like this: >> exception at 0805304A: >> Binding of socket failed: 8080. > > According to > http://stackoverflow.com/questions/3229860/what-is-the-meaning-of-so-reuseaddr-setsockopt-option-linux > setting SO_REUSEADDR option for server socket of embedded > fcl-web server would allow to restart the application > immediately after shutdown. > > I wonder what is the proper way of implementing this option: > > 1) Should the setter code go to fcl-net's ssockets.pp > and become "function TSocketServer.SetSocketOption"? > Or "property TSocketServer.ReuseAddress: Boolean"? > Or should I use fpSetSockOpt directly on > TSocketServer.Socket without changes to TSocketServer itself? > > 2) Should this option be hardcoded in > TFPCustomHttpServer.CreateServerSocket, or configurable via > TCustomHTTPApplication? > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber wrote: > On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote: >> >> Recently strings behavior was changed, they are now codepage-aware. The >> compiler can now implicitly convert strings from one encoding to another. >> To handle non-string data, you should use RawByteString type, or better >> yet non-string types like (dynamic) array of byte. >> > So TBlobField.Value probably should be changed to array of byte and there > should be a TField.AsByteArray property? > Yes, Certainly. Or better even Stream objects. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 7:00 AM, Sergei Gorelkin wrote: > Recently strings behavior was changed, they are now codepage-aware. The > compiler can now implicitly convert strings from one encoding to another. To > handle non-string data, you should use RawByteString type, or better yet > non-string types like (dynamic) array of byte. I always felt uncomfortable with converting binary types to strings because I know older strings with #0 would cause memory leaks. I think this has something to do with the problem. I think blobs should be stream objects so we can write/read that way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 1:07 AM, LacaK wrote: > TMySQL51Connection ? I'm using TMySQL51Connection. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 12:12 AM, LacaK wrote: > >> Did anyone recently do work on BLOB features to MySQL 5.1 connector? >> > > there was commited only this > http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/mysql/mysqlconn.inc?r1=17417&r2=18951 > which introduced mapping from MySQL TEXT datatype (character LOB) to > TMemoField and BLOB (binary LOB) to TBlobField > but I do not think, that this can cause your problems. > L. Well, I did some recursive tests and there is nothing wrong with Move or the Int64Array and supporting methods using the latest FPC/Lazarus. AND this issue is not a problem with PostgreSQL 9.1 - so at least I'm able to continue working... This is a problem with MySQL 5.1 and blobs - I'm surprised this isn't more noticeable with other blob entries. my app maps this particular field as SQL_LONGVARBINARY Query.Params.ParamByName(sName).AsBlob:=uInt64Array.toBlob(Value); ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Major problem with Move and Array of Int64
I use latest FPC from /trunk/ and this problem just started happening recently. Pseudo code Write To SQL as Blob (using parameter binding) Param.AsString=uInt64Array.toBlob(MyList); unit "uInt64Array" procedure fromBlob(List,string) count=length(string) div 8; // size of int64 SetLength(List,count) iPos:=1; for iLcv=0 to Count-1 do begin System.Move(String[iPos],List[iLcv],8); Inc(iPos,8); end; end; function toBlob(List):string; begin iLen=System.Length(List)*8; System.SetLength(Result,iLen); iPos:=1; for iLcv:=0 to High(List) do begin System.Move(List[iLcv],Result[iPos],8); Inc(iPos,8); end; end; Posting to the MySQL 5.1 database : the field size is as expected. Retrieving /converting the list (asString) from the database with all values set to small numbers appears to work Retrieving converting the list (asString) from teh database with larger values no longer works. Did anyone do anything to System.Move? Did anyone recently do work on BLOB features to MySQL 5.1 connector? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 3:02 AM, Mark Morgan Lloyd wrote: >> >> 1.) Update Value : 40734.825668912039 >> 2.) Actual Value after update : 40734.8256689120 >> 3.) Actual Value on read : 40734.825668912003 > > Does MySQL come with an "official" program that you can use to run queries > manually? What happens when you use it to store and retrieve that number? 1.) is a value declared as double and viewed under GDB. 2.) is a value viewed in table data in MySQL Console App under Linux. 3.) Is the value retrieved from the table by the Application using the Select statement and Fields.FieldByName(field_name).AsFloat() I am still experiencing this issue and seeking alternatives b/c I'm using all 12 digits - and am expecting all 12 digits. Can someone update the (Fields.Data variant as double) with a binary send instead of converting to a string? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 12:55 PM, Ludo Brands wrote: > The only way to transfer double as binary data to the server is by using > prepared statements and bound parameters. This is currently not implemented > in fcl. All data are transferred as text to the database and are subject to > conversion errors. Hmmm... I seem to recall prepare and bind parameters in fcl-db/mySQL component source?. Are you sure about this? I really, really, really need double precision data to work. I know i've used binary binds with Int64 arrays and things well beyond 8 bytes binary. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 11:55 AM, Hans-Peter Diettrich wrote: > The binary value consists of an exponent and an significand (mantissa), most > probably you forgot to count the exponent and sign bits. The problem I'm trying to describe is with double precision floating point values. When the query is open and one of the parameters is double MySQL does not receive all of the memory. It's missing two bits. That is a problem with either the mysql5.1 driver or with the mysql51 component w/r/t the double data type. > I'd suggest that you read a bit about using floating point numbers. They > never are accurate, and every decimal representation adds more inaccuracy I could understand if you wanted to bring this fact into argument over arithmetic and cumulative error. But the fact is - if I send a double precision data value to a double precision field in the SQL database - that value had better be the same - "bit for bit". Now if someone is being bit shifty on the conversion - that needs to be a addressed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 10:14 AM, Ludo Brands wrote: > So you're losing 2 bits in precision by truncating to 15 digits. Ok, so I'm going to go out on a limb here and propose the question: How to we fix this 2bit loser ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 10:19 AM, Hans-Peter Diettrich > It doesn't make sense to display more digits than stored in the binary > variable. There is no loss, only rounding errors in the conversion from > binary to decimal text. I need to compare values with complete precision. I don't think this problem was present a while ago. When the memory is copied is there a missing 12bits? Is there going to be a fix for this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] MySQL 5.1 and Double (trouble)
Declaraions are all double. >Value: double; >Query.Params.ParamByName(sName).AsFloat:=Value; Also: Test:double; Test:=Query.Params.ParamByName(sName).AsFloat; Test=Value << ok here. Problem must be somwhere else. 1.) Update Value : 40734.825668912039 2.) Actual Value after update : 40734.825668912 3.) Actual Value on read : 40734.825668912003 As far as I know this is a relatively new problem. Could be with Ubuntu but was someone doing MYSQL work lately? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: MySQL 5.1 and Double (trouble)
On Sun, Jul 10, 2011 at 8:00 PM, Andrew Brunner wrote: > 2.) Actual Value after update : 40734.825668912 This is the value as read in the MYSQL admin program table data. This is under Ubuntu 10.10 x64. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] MySQL 5.1 and Double (trouble)
On Mon, Jul 11, 2011 at 4:53 AM, Ludo Brands wrote: > How do you get the 40734.825668912003 value? Fields.FieldByName(Value).AsFloat(); ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MySQL 5.1 and Double (trouble)
Can someone check the status of update if the bind parameter for double decimal values? I'm getting unexpected rounding errors after updating - the data in the column looks different than what was specified during the update statement. Value: double; Query.Params.ParamByName(sName).AsFloat:=Value; 1.) Update Value : 40734.825668912039 2.) Actual Value after update : 40734.825668912 3.) Actual Value on read : 40734.825668912003 As far as I know this is a relatively new problem. Could be with Ubuntu but was someone doing MYSQL work lately? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safely shareable objects
Another problem may be that more often then not another thread may want to acquire a new object reference. What is the status of the cMem memory manager / with/without? Can one thread create an object and be freed by another thread? What about stacks? I know you can attach events to threads using an APC queue call under windows. Using that, the owner thread could pickup that callback and create an object instance, and then a mechanism can trigger the function to return (watch out for thread lock here) These are some questions I would raise. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safely shareable objects
> function TDLLItem.getNextItem():TDLLItem; > begin > EnterCriticalSection(FOwner.FLock); > Try > Result:=FNext; > Finally > LeaveCriticalSection(FOwner.FLock); > end; > end; Thread1 code ... itm=List.First; while itm<>nil do begin itm.Process; itm=item.Next; // good end; ... Thread2 code ... item=List.Any; // represents any Item in the List(could be result of iterator function) if isItemToBeDeleted(Item) then List.Delete(Item); ... Remember, First, Next, are getters with Locking CS. And if the lock is acquired for list iterations we're really going to not be able to use the list for transactional systems, which would be one of the primary reasons why developers would use threads in the first place. The problem here is we are never really going to be able to create "fast and efficient" code to make an object like this ptr list completely thread-safe. Meaning threading concepts must be understood before a user creates and uses a list. But in the code above, at some point thread1 will encounter and error because List.Delete freed the Item. And even though Delete, and all item Next,Prev getter/setters were fenced, the data will eventually be corrupted for multi-threaded usage. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safely shareable objects
2011/7/1 Hans-Peter Diettrich : > Adem schrieb: >> >> Why each and every object? I thought (b)locking only those touched in >> the Attach() procedure (9 nodes, in my ) would be sufficient; wouldn't it? Each and every element in the collection may prove difficult to protect for a general purposing. This threadsafe list would be able to use it only one thread owns the list and uses the list in its own execution thread. For general thread-safe usage any read or write access to Item.Next,Item.Previous would need to be done within the scope of the lock itself to avoid corruption. Restricing general access to Item.Next, or Item.Previous would also prove counter-productive. > The more objects with indiviual locks are used together, the higher the risk > of deadlocks (exponential increase?) I don't think anyone would suggest that in real-world design - it's just expected outcome - for describing protection required. I personally don't use interfaces. I would create items as Objects with getters/setters to Item.Next and Item.Previous et al could be accomplished by declaring attributes as property, and thus read and write would simply request the lock and establish a complex mechanism for either read barrier or write. Performance wouldn't be ideal but items would be completely protected. TDLList=class() private FLock:TRTLCriticalSection; end; TDLLItem=class() private FNext: TDLLItem; FPrev: TDLLItem; private function getNextItem:TItem; public constructor Create(aOwner:TDLList); reIntroduce; public property Next:TItem; read getNextItem; end; function TDLLItem.getNextItem():TDLLItem; begin EnterCriticalSection(FOwner.FLock); Try Result:=FNext; Finally LeaveCriticalSection(FOwner.FLock); end; end; After just think about the above code, you can see things aren't that simple with the DLL. Even if Next,Prev reads are protected, Another thread could come in there and request the item be deleted/destroyed. Thread ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Safely shareable objects
2011/7/1 Adem : > In a multi-core multi-threaded platoform, I simply cannot see (other than > locking the whole object) how any amount of interlocking or critical > sections (or whatever) can guarantee that none of these 9 variables (nodes) > will not be altered/deleted while we're in Attach() procedure. There is no thread-safe way to write to those variables safely without blocking access to each and every object in the entire collection as demonstrated. > And, the problem isn't just the Attach() procedure, any thread (running on a > different core) that reads any property (such as FirstChild, LastChild, > NextSibling, Parent, PrevSibling etc.) of this node object cannot be > guaranteed to get valid values. Presently, I feel you are 100% correct. I think with a similar case, which did employ CS as a full fence barrier (mentioned around here before) I had a bidirectional (double link list) problem exacerbating any outstanding cache issues by reUsing records. Meaning - in addition to First,Last, I also maintain a Recycled chain. I have a Recycled Pointer d/l/l chain so I could recycle records and avoid re-creating them over and over, since this is an HPC transactional server component. So instead of calling new, often the system would just take the first acquire Recycled, swap with Recycled.Next, and use the Recycled pointer. If Recycled=nil, I would create a new data ptr. Finally, remove is designed as LIFO. Just a few thoughts on this particular issue. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] SMP > 2 core Cache issue with Posix threads
On Fri, Jul 1, 2011 at 12:48 PM, José Mejuto wrote: > This code will crash at a given time, maybe 1 millisecond, maybe 2 > days, but it will crash. Yes. It will fail. Access to a,b are forbidden without acquiring a lock. > Cache coherence is maintained by the hardware, interlocked only > provide atomicity. How the atomicity is provided is beyond the scope > of pascal and even the OS. IMO, this statement is pretty bold/broad. Meaning interlocked assignments as defined will ensure cache coherence as apposed to CrticialSections which are meant to minimally block *write* access if not read/write access. I can tell you that a,b in my case were not so trivial. a,b happen to be reference pointers in a collection that without going into too much detail were certainly paged since the collection they resided in was large. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SMP > 2 core Cache issue with Posix threads
On Fri, Jul 1, 2011 at 11:44 AM, Hans-Peter Diettrich wrote: > IMO a linked list can not work flawlessly, until at least a > multiple-read-exclusive-write lock is used. While an exclusive-write lock > can ensure list consistency, every unsynchronized reader will be fooled by > concurrent changes to the list structure :-( I agree. Without a memory barrier, coupled with interlocked exchanges per node attachment, it would make memory synchronization impossible. > Consider what will happen when an (unsynchronized) reader determined an list > node, before or after which a new node shall be inserted. When the > write-synchronized update will happen, the list structure already can have > changed, so that the referenced node can have changed its position in the > list, or can have been moved into a very different list :-( Impossible to comprehend, that's why we have barriers. But in one specific case, Interestingly enough - the problem I experienced was with the 1 owning thread accessing the list. There was no subsequent access via additional threads, but across cores on a single cpu. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SMP > 2 core Cache issue with Posix threads
On Fri, Jul 1, 2011 at 8:51 AM, Mark Morgan Lloyd wrote: > Fair play, he /has/ said he's mailed Andrew looking for source. I never received such email. But to Michael's defense, Google mail isn't the product it once was. > However under the circumstances we've got to have something definitive to > inspect and test- I for one would be very unhappy if I spent my time running > up a rarely-used system and updating its compiler, only to be told that I > didn't have the right version of the test program. I did all of my research on memory barriers a while ago. The best site that describes this "phenomena" is http://en.wikipedia.org/wiki/Memory_barrier There are others here that helped walk me through this a while ago, but to me, this is a non-issue. I intend to use interlocked statements for mission critical memory assignments. I would suggest the poster do more questions than suggest there is a problem with either FPC, POSIX, or pthreads implementations, or kernel bugs, or OOP principals regarding inter-thread memory access to LCL objects. Anyone designing systems should already know how to employ techniques. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Thu, Jun 30, 2011 at 8:04 AM, Michael Schnell wrote: > - if the potential cache incoherency would not be handled by Hardware / OS > / Libraries on behalf of user land programs, I feel that this would so > disastrous and ubiquitous that it result in so many programs not working on > SMP systems that it would be a really well known issue. I agree. This problem when encountered was hidden during steady state testing. The list was consistently working as expected. Where it failed was when the core was ~80% usage and it walked - and it was on my test system here using daily Ubuntu x64 builds - lord knows what kernel it had those days. Infact, it could possibly be an ubiquitous exploit waiting for disaster when code normally running code encounters stale values across cores. You can imagine systems designed to never fail - fail for no known reason at all... In a case I observed, it did cause a significant problem to the server. Yes, it was disastrous, and ONLY evident during stress tests. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Thu, Jun 30, 2011 at 4:31 AM, Hans-Peter Diettrich wrote: > > After these considerations I'd understand that using Interlocked > instructions in the code would ensure such read/write-through, but merely as > a side effect - they also lock the bus for every instruction, what's not > required when concurrent access has been excluded by other means before. I too have come to that conclusion. It remains to be seen/decided though, who's responsibility is it to ensure/enforce coherency? Jonas was suggesting that the posix implementation (but he probably meant kernel) was already doing that via CriticalSection. > Furthermore we need concrete examples[2], how (to what extent) it's required > to use these special instructions/procedures, in examples like above. When > cache synchronization is a big issue, then the usage of related > (thread-unaware) objects should be discussed as well, i.e. how to ensure > that their use will cause no trouble, e.g. by invalidating the entire cache > before. Some FPC work may have been done in this area - intentional or not. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Here is a nice example of one that actually works... http://wiki.lazarus.freepascal.org/Manager_Worker_Threads_System Granted I wrote this sample and Wiki a long time ago, but you may want to read this ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 10:17 AM, Michael Schnell wrote: > You still did not give an example Don't take my word. Just look at the wikipedia link I already posted which indicates otherwise. >> Remember ***cores!=threads*** people. > > Wrong regarding the issue in question (see the message by Jonas). I'm at a loss for words. So you equate threads to cores? You know what forget it. Don't bother. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
You can stick your head in the sand all you want, just don't run your code on multi-core cpus and expect valid stability - and come back here complaining on how unstable your multi-threaded application is due to FPC design! > User programs are not supposed to bother about anything beyond threads that > are a well defined arch independent paradigm. Wrong again... Sigh... Think interlocked variables in your code and you will be fine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell wrote: > On 06/28/2011 04:31 PM, Andrew Brunner wrote: >> >> how developers >> can force code execution in order w/o using a third party library? > > Execution in order only makes sense when there is another thread that relies > on this order. Wrong. Sigh... Order of execution is paramount just about everywhere. It can be disastrous if not understood. Remember ***cores!=threads*** people. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell wrote: > And this has been discussed in the other message: If the variable in fact is > global the compiler needs to avoid caching it, if it is static and the > function is in another module it might still decide to cache it, but you are > right: it is not likely that it does make this difference. Well, I think one issue is that each core has it's own cache. 1.) How can we get the core to not relent and have the code handed off to another core until we're finished? 2.) How can we get the core to have a synchronised copy of a particular variable (aside from CAS)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe wrote: On topic, Jonas can you take a few moments to describe how developers can force code execution in order w/o using a third party library? Is there a compiler directive we can use? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
> Jonas already pointed you to it: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 > > "Applications shall ensure that access to any memory location by more than > one thread of control (threads or processes) is restricted such that no > thread of control can read or modify a memory location while another thread > of control may be modifying it." > > Please note the "read or modify". If you fail to understand this, you can > read the source of a posix threads implementation, e.g. nptl (which is part > of libc). I honestly don't believe that by the above statement has anything to do with what we're talking about here. And I'm thinking it's because of the two issues. One is threads. One is cores. I think we need to focus to get to the bottom of what we're all trying to say. I have been following and it is completely agreed that thread locks are NOT what we are trying to discuss. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:00 AM, Henry Vermaak wrote: > On 28/06/11 14:23, Andrew Brunner wrote: >> >> There is no problem no need for volatile variables. Compare and Swap >> or Interlocked mechanisms will solve any problems. > > Nope. You still need to prevent the cpu from reordering instructions with > memory barriers. I'm starting to sound like a broken record. If you don't > understand this, use the threading primitives provided by your operating > system like everyone else. > > Henry You've got your list particiapants mixed up. It was me who suggested order is important (at least on the lazarus discussion). And I am am 100% correct. Interlocked / CAS happen in one shot. They don't need barriers. They are protected. I think you have my conversations mixed up. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
> Of course it is. They issue a hardware memory barrier. This stops the cpu > from reordering operations. How do you think anything using pthreads will > work if they didn't? Documentation please? If what you are saying is accurate just point me to the documentation? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
> No, that is impossible. That's the whole point of using libraries such as > libpthread. They abstract such issues away. Using atomic operations inside > mutex sections only slows down your program unnecessarily (unless you also > access the target memory location from code not guarded by that mutex, and > also use atomic operations in those alternate cases -- or if you are using a > synchronization primitive from a library that does not observe the same > semantics as libpthread, but that would be a really strange design > decision). Two issues with what you are suggesting Jonas. Issue 1.) libpthread is just a posix implementation. it does not AUTOMATICALLY resolve issues inherent with present day multi-core memory access with respect to cores. It is by definition a thread implementation that includes atomic locks. Issue 2.) Telling people that it is poor design to exclude posix threads implementation is ignorant. FPC is cross platform. Posix threads specification is mainly to offer windows like threadding to unix/linux flavors. > If what you write above would be true, almost no program using libpthread > for synchronization would consistently work on multi-core systems. How many > programs do you know that exclusively use atomic operations to access shared > memory locations inside code regions guarded by a pthread_mutex? Access vs. Order. This is what makes a variable volatile across cores (not threads). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe wrote: >> 1.) Code execution on die is not controlled by pthreads implemention - >> as it is unaware at that level. > I have no idea what you mean by this. What would "code execution off die" be > as opposed to "code execution on die"? "on die" image was meant to take you to the code on the actual core being executed. That is to say the core itself is ignorant of what just executed before and will just take the code and execute it. >> 2.) Blocking access as described in 4.11 does not address execution order. > > It does guarantee that if T1 locks the mutex, changes the value, unlocks the > mutex and then T2 acquires the mutex (either on another cpu or not is > irrelevant), then T2 will observe strict memory ordering with respect to T1 > as far as this memory location is concerned (i.e., it will see any changes > to that memory location performed by T1 that were protected by the mutex). Sort of right. 6 core system. Core 1 locks code block. Code block should still use interlocked statements to make memory assignments so that when Core 1 releases lock - Core 2 can have a real-time image of variable. Otherwise Core 2 may see a stale copy of the variable. > If by "execution ordering" you mean that there is no guarantee regarding > which thread will acquire the mutex first, then that's true, but > synchonrization races are unrelated to memory ordering issues. Don't bother looking that deep. The topic the poster raised is about variable volatility with respect to thread safe code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:16 AM, Jonas Maebe wrote: > The C (or Pascal) compiler has no idea whether or not the global variable > will be accessed by the pthread_mutex_lock()/unlock() function. As a result, > it will never cache it in a register across function calls, and the call to > the mutex function by itself guarantees that the variable's value will be > written back. Agreed. And you can make such access atomic. Getting developers to chose the right tool for the job is the key here. But understanding the core issues (pun intented ;-) is the key. > So you don't need volatile. Even if it's a local variable you don't need it, > because as soon as you take the address of a local variable and it can > escape the current function (and hence the current thread), the compiler > again has to assume that any called function may modify it via an indirect > access. > There is no problem no need for volatile variables. Compare and Swap or Interlocked mechanisms will solve any problems. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe wrote: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html > (point 4.11) Nope. Nothing about order - just access - and that is entirely on the application level - not system. 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. 2.) Blocking access as described in 4.11 does not address execution order. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe wrote: > > On 28 Jun 2011, at 14:58, Andrew Brunner wrote: > >> On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell >> wrote: >> >>> For variables not defined as volatile, (e.g.) pthread_mutex (and similar >>> stuff on Windows) can be used to protect them. >>> >> A mutex may be able to atomically block access because of its own >> memory barrier, but I would suggest that employing such a technique on >> multi-core systems will not ensure an accurate value. > > pthread_mutex() does guarantee that. I don't know about the Windows > equivalents. > Specification just describes standard mutex. What makes pthreads specification different to include ordering? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell wrote: > For variables not defined as volatile, (e.g.) pthread_mutex (and similar > stuff on Windows) can be used to protect them. > A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] compiler bug with structs within nested classes
I heavily use nested classes in general and I've come across a problem where I cannot make explicit references data structures from another unit while embedded within classes. //Developer/Source/Builds/SCS/Linux/64/Output/uRTSPd.o:(.data+0x52f): undefined reference to `RTTI_DBMRTSP_DEF112' The linking error will change as I tried referencing different structs contained in dbmRTSP.pas unit. I can create classes/structs (that reference said structs) within the dbmRTSP unit that link, but when I reference the same structs from outside this unit I get the linking error above (which again changes with respect to the struct) http://bugs.freepascal.org/view.php?id=19534 Anyone familiar with nested classes look into this for me? Thanks a lot! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problem with nested classes and types
I'm using the trunked FPC/Lazarus (just updated) and I have a problem with nested types. Ubuntu x64 10.10 dbmVDM.pas type VDM=class type DB=class const stuff = 0; // fields removed for simplicity even more subclasses end; end; Resources=class type DB=class const stuff = 0; end; TResource=record // 79 foo:integer; bar:string; end; PResource=^TResource; //80 end; uXMPPd.pas uses ... dbmVDM; type // no nested classes TClientSessionData=record foo : string; bar : integer; Resource : dbmVDM.Resources.PResource; //(error *_DEF80) also fails on just Resources.TResource (error *_DEF79) end; Project syntax looks good but fails on link. //Developer/Source/Builds/SCS/Linux/64/Output/uXMPPd.o:(.data+0x1ccc): undefined reference to `RTTI_DBMVDM_DEF79' Service.lpr(15,1) Error: Error while linking I had an identical problem a few days ago but reverted to using generic Pointer and casting with no problems. I had a test case outside my project but can't duplicate this problem at all. Seems like linker can't find subclass type of dbmVDM.Resources.TResource. Needing a fix so I can use my elaborate name-space system :-) Any help would be greatly appreciated. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MySQL 5.5 and Connector System
I just installed MySQL 5.5 and realized that the connector is bound to
5.1. I can see why looking at the code - why this is like that :-)
I had a problem with the usage of $ifdefs all over the place in the code.
It would be worth it since there are so many flavors of MySQL to
re-structure the MySQL component suite to employ the usage of
{$if defined(MySQL50) or defined(MYSQL51) or defined(MySQL55) or
defined(FutureVersions)}
CODE HERE
{$eslif defined(MYSQL41)}
OTHER CODE HERE.
{$endif}
IMO, presently the MySQL connection implement is getting too big to
just add another ifdef ad-hoc. I did set out yesterday to work on
this but I really don't have the time to figure out why the build
process on v50 connection didin't have $DEFINE mysql50 on a constant
from another unit. I edited the make files to include mysql55 etc.
So the questions are
1.) Is the dynamic unit system that MySQL connector uses compatible
with $if rather $ifdef ?
2.) What are the important things to change in /packages/mysql and
packages/fcl-db/*sql/ other than the obvious unit names for component
version?
I had to abandon this attempt due to lack of time for this particular
issue, but wanted to point out that I would be willing to implement
mysql connectors as they are released. My primary choice of DBMS is
MySQL. And I'm planning to stick with it.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Nested register error for procedure passing address
I did read this however, I don't have the option of rewriting all the other implements to my api to declare as nested... http://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_nested_procedure_variables ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Nested register error for procedure passing address
procedure Something(Param1...); var my:TMyData; procedure Testing; inline; // or whatever begin my.test:=0; end; begin MyAPI.DoeSomething(Param1,@Testing); end; I want to be able to pass Testing as a variable so the callback can occur but realize that FPC did not like nested proc. Is there a directive to resolve this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Nested Classes used as Namespace Question
As a follow-up I've temporarily got past this issue by making each member of the enumeration having a unique name with a preceding character. The only problem now is my code looks well not as refined... ns.App.Props.aName ns.Vendor.Props.vName Anyone want to give this a try at fixing ? I want to have nested enumerations isolated within classes with identical names ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Nested Classes used as Namespace Question
Type NS_APP=class const const1=2; const3=5; type NS_SPACE1=class type Properties=(Name,Value); TMyRecord=record ID : integer; Name:string; Value:string; end; end; NS_SPACE2=class type Properties=(Name,Value); // Duplicate Identifer "Name" error @ compile TMyRecord=record Key : Array[0..1] of Byte; Value : Pointer; end; end; end; I'm trying to have identical naming conventions and kind of expected these classes to have some degree of isolation within nests. NS_SPACE2.Properties.Name is not valid b/c the compiler has Name already defined above in NS_SPACE1. Is this expected? Is it too much work to isolate nested classes so I can get past this error? Is there another way to achieve having two "Properties" type with two different types with no exceptions? Thanks in advance. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
I'm really surprised that I come off as sounding pro any OS. Personally, I'm the type of person to remove Windows 7 from my brand new laptop just to run Ubuntu. I think there is though, some sort of deep seeded resentment towards event driven methods. So back to the topic... As it stands I do have SIGIO issues and am working on epoll. But since sigaction is preferable I'm searching for anyone with information as to how to get the kernel to define my sigaction and associate it with socket methods not Terminal IO. I think there is a flag I can set - I just don't have the value or name. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sun, Jan 2, 2011 at 10:58 AM, Jonas Maebe wrote: > Please move this discussion to the fpc-other list. If by "this" discussion you mean "his" discussion then great. I've still got outstanding issues with SIGIO / SIGPOLL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sun, Jan 2, 2011 at 9:07 AM, Michael Van Canneyt wrote: > All webservers I know use polling on unix, and they are what you might call > 'high availablility' environments. There is a big difference between HA and HP :-) While they are relationally proportional the cost of HA is minimized with efficient performance designed apps. > If your design is good, it should not be too much of a problem to separate > the IO from the rest of your handling, and then all the rest of your code > need not know whether it is polling or messaging that's being used. Yes. Signalling is separate from processing using custom (thread safe) caching FIFO ptr lists :-) One list per event type. Reads/Writes/etc... I recognize that no self respecting Linux buff would stoop so low as to copy anything microsoft. But event driven principals aren't owned by ms and gang. Event driven engineering is totally ideal for network sockets because you never know if/when data will arrive. I also want to assert that ideal engineering principals, no matter who/where they come from must be seriously considered with extreme diligence as the lack of such is, at its core, the main reason why it has taken Linux so long to become widely adopted. Microsoft has exercised ZERO restraint in picking off technologies and implementing them in their products even with disregard to intellectual property laws. Ask yourself - why is it then we still see resistance in general Linux land to adopting good engineering principals? You know, along those lines, it could be possible, that at least in this case, Linux was up against IP law to which ms has asserted claim... If that is true as/if in this case I could see the hand being cut off to save the rest - and we are absolutely stuck with ePoll from now until 10 years after the claim was filed ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sun, Jan 2, 2011 at 5:24 AM, Nikolai Zhubr wrote: > Formally yes maybe, but Andrew probably meant just avoiding some horrible > CPU-burning busy-loop. > > Despite of the similar name (epoll), substantial shortcomings of classical > polling scheme are gone. Say, you need not use a timeout to be able to > handle any non-socket events like you were forced with select(), you can > wait on descriptors of different types if you wish to, and you don't have to > pass huge arrays all the way. >From reading up on ePoll I came to understand that there is was a period in time, about 3 years ago where there was a push for restful event driven signals for sockets. (SIGPOLL) is/was existing *nixs that have proven methods for socket signals on some platforms. Linux (at least my Ubuntu 10.10) handles SIGPOLL as SIGIO and waits for data ending in CRLF before sending my pid the signal. Having the kernel send me such a signal with the socket handle would be the most ideal situation because I already have core classes that organize/manage sockets in a high-scale, thread-safe way. As Michael pointed out, and he and I both would benefit from having socket signaling under Linux, that employ no (rounding or transversing of socket elements) as it would be the most ideal environment. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sun, Jan 2, 2011 at 4:43 AM, Michael Van Canneyt wrote: > Do note that you're back to polling, which I understood you wanted to avoid > in the first place ? > > Michael. Sigh - yes, your right. I haven't given up on kernel level signals (SIGIO/SIGPOLL) and random posts on various *nix forums talk about people doing things as I suspect. So I realize that socket signaling is possible. There are only two io events I need. I am willing to use epoll_* to run some tests. If the kernel is efficient at circling the array - I may not notice the difference. People have mentioned that epoll is scalable within reasonable expectations of using my engine. 3,000 sockets per thread shouldn't be too much to handle. SIGIO was giving me notice on socket closings and on datagrams ending in CRLF. I'm thinking there has to be a way to tell the kernel that this fd is a socket - and when that happens the kernel might send more signals eg.) like after a few ns after data stops streaming in or when MSG_MORE* isn't attached to the actual TCP/IP frame. But as an application we can't count on MSG_MORE being attached to each unfinished datagram (as in NetCat and Telnet). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
Thanks Marco. I hope to get kqueue under darwin implemented shortly. But Linux was after Windows. Apple can wait. On Sat, Jan 1, 2011 at 7:26 PM, Marco van de Voort wrote: > In our previous episode, Andrew Brunner said: >> proven methods under Linux. I wonder if epoll was ever brought into >> Darwin... I did notice Apple making a quiet exit out of the Server >> market. > > As said, BSDs (and afaik Darwin too) use kqueue/kevent. (kevent is e.g. for > directory notifications). > > Afaik kqueue is largely equivalent to epoll in functionality (and some > people call it slightly more elegant even). > > Note that this is all written in the first paragraph of the urls that you > quote ( http://daniel.haxx.se/docs/poll-vs-select.html ) :-) > > ___ > fpc-devel maillist - fpc-de...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
Thanks, Nikolai. epoll looks like the silver bullet (for linux) and very promising. I can dump a bunch of sockets into it and get the kernel to let me know which ones get notifications for reset/read/write. But the abstraction is already accomplished in the foundational abstracted network server manager/worker threads unit that all protocols are implemented by. Interesting reading : (1) http://daniel.haxx.se/docs/poll-vs-select.html (2) http://www.kegel.com/c10k.html I can't believe it has been this difficult to tie into *working* proven methods under Linux. I wonder if epoll was ever brought into Darwin... I did notice Apple making a quiet exit out of the Server market. Thanks again! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
> On Sat, Jan 1, 2011 at 5:45 PM, Marco van de Voort wrote: > My guess is that he is desperately trying all straws to find something that > matches the application model of his existing app, which is Windows centric. Also, it should be pointed out, that the existing mechanism (which is commented out) in the app, is polling each socket in the manager's queue for data or connection status. This is highly in-efficient and cause unacceptable latencies across both Linux and Windows. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sat, Jan 1, 2011 at 5:45 PM, Marco van de Voort wrote: > > My guess is that he is desperately trying all straws to find something that > matches the application model of his existing app, which is Windows centric. I am exploring all options to switch to the most effective form for handling high scale (gargantuan) socket system management for at least 3 protocols across thousands of worker threads handling about 100 to 1000 socket ids per thread :-) All this confirmed to run flawlessly on Windows. You wanna sit here and tell me it can't / isn't to be done with LINUX!?! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sat, Jan 1, 2011 at 5:39 PM, Nikolai Zhubr wrote: > What are you trying to achieve ultimately? People tend to avoid using > signals as much as possible nowadays (for anything beyond some nice handling > of forced/fatal program termination and such) at least on linux. I'm not > guru, just somewhat curious (because some time ago I had to re-engineer some > small networking app, originating from windows, to be cross-platform and > resource-friendly) Hi Nikolai, I'm trying to build a cross platform *event* driven socket signaling mechanism that does not employ polling algorithms. When you say resource-friendly... Do you mean CPU or memory? I'm looking for something to work as advertised in the Linux man pages for signals. If it turns out that signal information is missing via the Kernel - I have no qualms with submitting a few requests to the proper channels... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sat, Jan 1, 2011 at 12:25 PM, Marco van de Voort wrote: > In our previous episode, Andrew Brunner said: >> Another important thing is that (IMO) the data structure for >> TSigAction is out-dated. > >> Please refer to rtl/linux/signal.inc and compare the struct with the >> one specified at the URL I included for linux... The two structs are >> different. >> >> http://www.kernel.org/doc/man-pages/online/pages/man2/sigaction.2.html > > IMHO it could be that that page is simply wrong, or dumbed down. It looks > like a sigaction(3) page, while FPC implements a "true" sigaction(2). > > ___ > fpc-devel maillist - fpc-de...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > Excellent. Thanks. That means that the problem is elsewhere. I think I'm narrowing down the semantics. I'm down to the problem with setting the socket attribute to the signal as instead of a file. I read about it somewhere but I don't see the constant nearby in the header file for sigaction flags. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
On Sat, Jan 1, 2011 at 12:02 PM, Mark Morgan Lloyd wrote: > > I am neither a kernel hacker nor a network guru, but would a signal be > raised when a byte was read or when a TCP packet- possibly comprising > aggregated bytes- was transferred? I think you'd be better not using a > standard telnet client for this but instead using Netcat (nc) or netpipes > (faucet and hose) which will not, certainly by default, be fiddling with > line-ends or aggregating bytes for efficiency. Thanks for the hints. Yeah, I'm aware of pipelining with mail protocols and more recent WebSockets for streaming multiple datagrams. In context - I think your suggestion with a tool other than terminal would be welcomed and adopted ;-) Thanks again. Bottom line is - I am testing signal capabilities and nuances and nc looked promising but the same result. The packet was coalesced ending in CRLF with ./nc ... with or without -C for CRLF sending... Which tells me there is going to be a SOCKET flag I need to set on the signal in association with this FD that says... Hey I'm a socket not a cmmand line session... or something to that effect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Linux Signals
I'm trying to get signals to work with sockets under x64 Ubuntu 10.10 (all updates) I installed two handlers for two events SIGIO, and SIGHUP uising fpsigaction(SIGIO, @saAct, nil) . I was expecting to get a byte by byte signal under telnet to my server instance (110-pop3) on the IO but had only received the signal on CRLF. Firefox on the HTTP has the same problem but I suspect a problem since it is impossible to ever receive a signal for binary protocols having no CRLFs for as kernel triggers to signal applications. Perhaps this particular issue is better directed at Debian? Another important thing is that (IMO) the data structure for TSigAction is out-dated. Please refer to rtl/linux/signal.inc and compare the struct with the one specified at the URL I included for linux... The two structs are different. http://www.kernel.org/doc/man-pages/online/pages/man2/sigaction.2.html There are two issues. Problem 1: How do I control the circumstances in which the signal is sent... To emulate conditions like windows... Which is every few seconds until the buffer is emptied for that socket descriptor. Problem 2: Info.FD =0. I did a trace into the callbacks and found that the socket handle was stored in the si_status field of the siginfo at runtime. To me, this seems problematic but I guess if it's not attributed to the discrepency in the declaration of SigInfo, I'm looking for an approval to use this si_status as my socket number across linux distros - or is this just a Ubuntu fluke, and under say Red Hat I will receive my socket handle on the FD attribute !?! The siginfo_t argument to sa_sigaction is a struct with the following (as interpreted by me) TSigVal = record case longint of 0 : ( sival_int : longint ); 1 : ( sival_ptr : pointer ); end; TSigInfo=record si_signo : integer; // Signal number */ si_errno : integer; // An errno value */ si_code : integer;// Signal code */ si_trapno : integer;// Trap number that caused hardware-generated signal (unused on most architectures) */ si_pid: pid_t;// Sending process ID */ si_uid: uid_t;// Real user ID of sending process */ si_status : integer;// Exit value or signal */ si_utime : clock_t;// User time consumed */ si_stime : clock_t;// System time consumed */ si_value : TSigVal; // Signal value */ si_int: integer; // POSIX.1b signal */ si_ptr: pointer; // POSIX.1b signal */ si_overrun : integer; // Timer overrun count; POSIX.1b timers */ si_timerid :integer; // Timer ID; POSIX.1b timers */ si_addr: pointer;// Memory location which caused fault */ si_band: longInt;// Band event (was int in glibc 2.3.2 and earlier) */ si_fd : integer; // File descriptor */ si_addr_lsb:shortint; // Least significant bit of address (since kernel 2.6.32) */ end; I'm asking anyone with signals and socket experience to take a look at this. I can follow-up with a sample fp program if necessary... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fcl-db / posgres Memory Leaks
Postgres has some problems with the unit code. WIthout getting into personal preferences with code indentation (eye rolls) I would like to point out that (at least on windows) reading res after pqclear(res) will result in a SIGFAULT error. So inspecting pqconnection.Execute(...) res := pqexec(tr.PGConn,pchar(s)); if (PQresultStatus(res) in [PGRES_COMMAND_OK,PGRES_TUPLES_OK]) then begin pqclear(res); if not (PQresultStatus(res) in [PGRES_COMMAND_OK,PGRES_TUPLES_OK]) then begin s := PQerrorMessage(tr.PGConn); I'm consistently getting a SIGFAULT error unless I set res to nil and change the following res := pqexec(tr.PGConn,pchar(s)); if (PQresultStatus(res) in [PGRES_COMMAND_OK,PGRES_TUPLES_OK]) then begin pqclear(res); res:=nil; if (res<>nil) and not (PQresultStatus(res) in [PGRES_COMMAND_OK,PGRES_TUPLES_OK]) then begin s := PQerrorMessage(tr.PGConn); Can someome please review pqconnection.pp and fix this? I'm having to re-apply my fix every time I update and my bug report is going unheeded. Which is crippling my ability to even use Postgres. Please, fix soon :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with rapid fpSend calls on x64 Ubuntu 10.10 (updated)
> > (and look on internet for the meaning of the MSG_NOSIGNAL flag :) ) > > Michael. > Thanks Michael. That did the trick. But sooner or later I'm going to need to switch from polling to events... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with rapid fpSend calls on x64 Ubuntu 10.10 (updated)
On Thu, Dec 2, 2010 at 1:14 PM, Michael Van Canneyt wrote: > > It would help if you could say what the exception exactly is ? > > Thanks Michael, Well all I see is a SIGPIPE exception. As stated before the actual FPC exception was not raised (or the except block was not executed) in there so I can't even log the error. Does that help? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Problems with rapid fpSend calls on x64 Ubuntu 10.10 (updated)
OS: Ubuntu 10.10 x64 all updates as of this am. But problem has persisted
for days now.
Laz/FPC: Today's trunk
worker thread running issues a call to fpSend with iSend Bytes in buffer
Try
RSRP^.LastCall:=Sockets.fpSend(RSRP^.Info.Socket,@FSendBuffer[0],iSend,0);
except
on E:Exception do
OnRSRException('TRSRManager.cb_RSR_Send','Exception',E.Message);
end;
FPC/srtl/linux/x86_64/syscall.inc
line 319 fails but execption is raised in 320.
line 319: syscall { Do the system call. }
line 320: cmpq $-4095, %rax { Check %rax for error. }
I had exception handling inside the block but it was not caught.
Anyone else having problems with sockets on Unix. This problem does not
exist on Windows. After the first occurance of this issue, all network
engine activity fails across other threads too with exceptions at this very
spot.
Any help would be greatly appreciated.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
