[fpc-devel] Re: TProcess, bash, and escaping quotes
Thank you! It makes sense now. I'll keep an eye on the enhancement request Marco pointed me to and use the workaround I came up with in the meantime. -SG > If you look at how TProcess parses command line into parameters > (fcl-process/src/unix/process.inc CommandToList) you see that it > doesn't support escaping with backslash (inside or outside double > quotes). Your command is parsed as (using FPC 2.5.1): > 1: bash > 2: -c > 3: "ifconfig | grep -E -e \"inet6? > 4: addr:\" | grep -v -E -e\"(127.0.0.1|::1|Scope:Link)\" | sed > -e\"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g\"" > -- > cobines -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: TProcess, bash, and escaping quotes
If you look at how TProcess parses command line into parameters (fcl-process/src/unix/process.inc CommandToList) you see that it doesn't support escaping with backslash (inside or outside double quotes). Your command is parsed as (using FPC 2.5.1): 1: bash 2: -c 3: "ifconfig | grep -E -e \"inet6? 4: addr:\" | grep -v -E -e\"(127.0.0.1|::1|Scope:Link)\" | sed -e\"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g\"" -- cobines ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: TProcess, bash, and escaping quotes
I also just realized I sent all of these messages to the wrong mailing list (devel instead of pascal). My apologies, it's been one of those days. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem & TotalAllocated: Round 2
18.02.2010 0:29, Marco van de Voort: I think so, please enter it in Mantis. Ok, should I create a new entry or rather add it to bug 0014315 (http://bugs.freepascal.org/view.php?id=14315) which is probably the same issue, though filled for earlier version? I quickly looked around and noticed two things: 1) It is also striking that it seems to happen on the first realloc of a NIL ptr, maybe that is a scenario not properly updated, sizewise. 2) I also see a "exit(true)" in systryresize that doesn't update sizes. ___ 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] Re: TProcess, bash, and escaping quotes
Well, even after playing with escaping various characters (like \, `, and "), it still wouldn't work, so I came up with a hack that will work for my needs. In the case where I need to "bash -c" some command with TProcess, I am now writing the command out to a file, then just passing "bash /path/to/file" as the TProcess command line, then deleting the file. Kind of a hack, but at least it works the way I want it to. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem & TotalAllocated: Round 2
In our previous episode, Nikolai Zhubr said: > Please note that while the problem itself is quite stable, the example > is not. That is, if you insert or remove some code, change the filename > etc, then the example might just start work properly! (Maybe it is > alignment-related, not sure) > > I haven't sent this to mantis yet. Please someone let me know if this > example is appropriate (or not). I think so, please enter it in Mantis. I quickly looked around and noticed two things: 1) It is also striking that it seems to happen on the first realloc of a NIL ptr, maybe that is a scenario not properly updated, sizewise. 2) I also see a "exit(true)" in systryresize that doesn't update sizes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ReallocMem & TotalAllocated: Round 2
13.02.2010 15:32, Marco van de Voort:
2) GetHeapStatus.TotalAllocated sometimes return negative values, though
I haven't been able to prepare a reasonably small example yet (should I?)
Please attach example programs to a bugreport. Thank you.
I've created a small self-consistent example, but something is wierd
with it. In order to reproduce the effect, put the example in a file
named 000.pas (with other filename misbehaviour might not trigger!),
compile with 2.4.0 (do not add any options to compiler) and run on
windows. Then (hopefully) you will see bogus TotalAllocated values:
4194281K
4194257K
4194233K <...>
4194208K
4194184K
4194160K
4194136K
4194112K
4194088K
4194064K
Please note that while the problem itself is quite stable, the example
is not. That is, if you insert or remove some code, change the filename
etc, then the example might just start work properly! (Maybe it is
alignment-related, not sure)
I haven't sent this to mantis yet. Please someone let me know if this
example is appropriate (or not).
Thank you.
Nikolai
- cut ---
{$mode delphi}
{$apptype console}
uses
SysUtils;
const
data: array [0.. 12] of integer = (9000, 1000, 9000, 12, 9000, 26,
9000, 74, 9000, 1, 2000, 9000, 1);
var
p: pointer;
i: integer;
begin
p := nil;
repeat
for i := low(data) to high(data) do
ReAllocMem(p, data[i]*4);
writeln((GetHeapStatus.TotalAllocated shr 10), 'K');
readln;
until false;
end.
- cut ---
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: TProcess, bash, and escaping quotes
In our previous episode, Seth Grover said: [ Charset UTF-8 unsupported, converting... ] > Sigh, looking closer I realize it's probably because there's other > characters in there I need to escape (like the \ and the $). I'll play > around with that and see if that solves my problem. > > I always see these things AFTER I send and email to the mailing list. > Apologies. Don't forget to search mantis too. http://bugs.freepascal.org/view.php?id=14446 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: TProcess, bash, and escaping quotes
Sigh, looking closer I realize it's probably because there's other characters in there I need to escape (like the \ and the $). I'll play around with that and see if that solves my problem. I always see these things AFTER I send and email to the mailing list. Apologies. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TProcess, bash, and escaping quotes
I'm working with TProcess, which for the most part I love, but I'm
scratching my head right now because of a problem I'm experiencing.
Suppose I have the following command:
ifconfig | grep -E -e "inet6? addr:" | grep -v -E -e
"(127.0.0.1|::1|Scope:Link)" | sed -e
"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g"
I can run that as-is from the command-line, since my shell hooks up
all of the pipes and whatnot for me. Also, I can execute it like this:
bash -c "ifconfig | grep -E -e \"inet6? addr:\" | grep -v -E -e
\"(127.0.0.1|::1|Scope:Link)\" | sed -e
\"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g\""
By escaping the double-quotes and then passing the whole thing to bash
as the argument for the -c, it works.
However, if I pass the above command (the one using bash -c with the
double-quotes of the original command escaped), as the CommandLine of
a TProcess, it doesn't work. TProcess execs bash, but the argument
doesn't seem to make it there correctly. Bash spits out:
$ ./tprocquotes
addr:\" | grep -v -E -e \"(127.0.0.1|::1|Scope:Link)\" | sed -e
\"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g\"": -c: line 0: unexpected
EOF while looking for matching `"'
addr:\" | grep -v -E -e \"(127.0.0.1|::1|Scope:Link)\" | sed -e
\"s/^.*addr:\s*\(\S*\)\(\/\d+\)*.*$/\1/g\"": -c: line 1: syntax error:
unexpected end of file
Yes, I know I could use single quotes instead of double quotes to the
-c argument, and then I wouldn't have to escape the double-quotes.
And, yes, I know there are other ways to accomplish what that command
does by parsing the output of ifconfig. I've got workarounds for this
particular example, but I still don't know why it shouldn't work with
TProcess with me escaping the double-quotes with a backslash and then
passing the whole thing double-quote enclosed to bash -c as the
TProcess CommandLine.
What am I doing wrong?
I've got an example program illustrating what I'm doing on PasteBin at
http://pastebin.com/f336d384b, and I'll also include the contents of
the program in this email in case anyone in the future's ever
searching the archives and the pastebin link doesn't exist any more.
-SG
-
program tprocquotes;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}
cthreads,
{$ENDIF}
Classes,
SysUtils,
dateutils,
process,
pipes;
function ExecuteProcess(const command : string;
out commandExitCode : integer;
const timeoutSec : integer;
const stdout_stream : TStream;
const stderr_stream : TStream;
const redirectErr : boolean) : boolean;
const
READ_BYTES = 2048;
var
P : TProcess;
buffer : array of byte;
tmpStdOutput : TMemoryStream;
tmpStdError : TMemoryStream;
stdOutToUse : TStream;
stdErrToUse : TStream;
startTime : TDateTime;
stdOutBytesRead : longword;
function ReadAvailableBytes(const source_stream : TInputPipeStream;
const dest_stream : TStream) : longword;
var
bytes_available : longword;
bytes_read : longint;
bytes_to_read : longint;
begin
result := 0;
if Assigned(source_stream) and Assigned(dest_stream) then begin
bytes_available := source_stream.NumBytesAvailable;
while (bytes_available > 0) do begin
if (bytes_available >= READ_BYTES) then begin
bytes_to_read := READ_BYTES;
end else begin
bytes_to_read := bytes_available;
end;
bytes_read := source_stream.Read(buffer[0], bytes_to_read);
if (bytes_read > 0) then begin
dest_stream.Write(buffer[0], bytes_read);
result := result + longword(bytes_read);
end;
bytes_available := source_stream.NumBytesAvailable;
end;
end;
end;
begin
result := true;
commandExitCode := 1;
if Assigned(stdout_stream) then begin
tmpStdOutput := nil;
stdOutToUse := stdout_stream;
end else begin
tmpStdOutput := TMemoryStream.Create;
stdOutToUse := tmpStdOutput;
end;
stdOutToUse.Size := 0;
stdOutToUse.Seek(0, soFromBeginning);
if Assigned(stderr_stream) then begin
tmpStdError := nil;
stdErrToUse := stderr_stream;
end else begin
tmpStdError := TMemoryStream.Create;
stdErrToUse := tmpStdError;
end;
stdErrToUse.Size := 0;
stdErrToUse.Seek(0, soFromBeginning);
SetLength(buffer, READ_BYTES);
P := TProcess.Create(nil);
try
P.CommandLine := command;
P.Options := [poUsePipes];
if redirectErr then P.Options := P.Options + [poStderrToOutPut];
P.InheritHandles := false;
startTime := now;
P.Execute;
{ read stdout while the process runs }
while P.Running do begin
stdOutBytesRead := ReadAvailableBytes(P.Output, stdOutToUse);
Re: [fpc-devel] MemSize argument validity
In our previous episode, Fl?vio Etrusco said: > > Afaik fastmm does this on Delphi. Together with having barriers before and > > after the allocation that are checked regularly to see if they are > > overwritten. > > I'm sure somebody "has to" have asked this before (maybe even me :-$ > ), but has someone ever tried to port fastmm to FPC? No idea. I don't even know how much sense it makes. Some stuff (debug format(traces), dll and packages stuff) is probably not (or not yet) portable. The license is incompatible etc etc. Better improve on the current memory managers (2.4/2.5 default memmgr and heaptrc) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
2010/2/17 Flávio Etrusco : > I've read somewhere that Windows ANSI functions support utf-8? > (despite the name) lol!!! You read from someone deeply missinformed =D -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Wed, Feb 17, 2010 at 4:10 AM, dmitry boyarintsev wrote: > Reported: http://bugs.freepascal.org/view.php?id=15795 > > It's up to FPC team to accept or reject the package. > > thanks, > dmitry I've read somewhere that Windows ANSI functions support utf-8? (despite the name) -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
> > Afaik fastmm does this on Delphi. Together with having barriers before and > after the allocation that are checked regularly to see if they are > overwritten. I'm sure somebody "has to" have asked this before (maybe even me :-$ ), but has someone ever tried to port fastmm to FPC? Best regards, Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Martin Schreiber said: > On Wednesday 17 February 2010 09:15:53 Marco van de Voort wrote: > > > > Reject as far as I'm concerned. I'd like to see the RTL being in the system > > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > > RTLString. > > > Aren't filenames on Linux an array of bytes without any encoding by > definition? I never saw that. The encoding is sometimes a bit opague yes. It will be a practical detail which exact 1-byte encoding to choose for rtlstring (cp_utf8, rawbytestring or default). Whatever works best. > Are you sure there are no Linux running with other system > encoding than utf-8 today? No. Does it matter? > How are imported filesystems with other encodings (for example Samba > shares) handled? Don't see a relevance here. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Wednesday 17 February 2010 09:15:53 Marco van de Voort wrote: > > Reject as far as I'm concerned. I'd like to see the RTL being in the system > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > RTLString. > Aren't filenames on Linux an array of bytes without any encoding by definition? Are you sure there are no Linux running with other system encoding than utf-8 today? How are imported filesystems with other encodings (for example Samba shares) handled? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
17.02.2010 13:35, Marco van de Voort: In our previous episode, Jonas Maebe said: I've just discovered that passing an invalid pointer to MemSize() results in a bogus value returned and no error generally reported. Is this intentional? It's just as intentional as dereferencing an invalid pointer can result in a segmentation fault, that freemem'ing an invalid pointer can corrupt the heap, etc. It's how manual memory management works: the programmer is responsible for not making any errors with pointers. ... and that means assuming that you can't make out failsafe if a pointer is valid or not. One needs to manage that oneself. Ok, thanks. I just hoped MemSize could be magically different from others :) Nikolai ___ 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] procedure ... message(); in Linux
In our previous episode, Michael Schnell said: > How to send a message from a thread ? > > How to send a message from another process ? > > I do know that there are other (supposedly more decent) ways to do > inter-thread and inter-process communication, But as > procedure...message(), does compile in a Linux executable, I'd like to > know how it's supposed to be used. Afaik it is nothing more than a table that says "for msg with value xxx call method yyy". IOW it is abstract. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Hello Graeme, Wednesday, February 17, 2010, 2:57:07 PM, you wrote: GG> Yes, that is always ideal, but I can only work with what I know and what I GG> can find on the internet. If you have a link on the internet that defines GG> color values in 48bit, then please do post it here. I have search for the GG> last 30 minutes and haven't found a single link. You will not find nothing quite sure as 24 bits is quite closer to our color perception capability. GG> All colors I could find are defined as 24-bit RGB values (certified values GG> and color names created by companies like Microsoft, HP, Adobe, W3C, Exif GG> etc.), so that is what I based my calculations on. Using ratios to do the GG> upscaling calculation seems to be the most common conversion method too - GG> as per the links I found on the internet (wikipedia and many websites like GG> Adobe or other photographic websites). The problem is that for each 24 bit colors there are 16.1 million equivalent colors in 48 bits so any test like: Pixel[x,y]=clMaroon; if Pixel[x,y]=clMaroon then blah, blah... will only be true 1/1600 times, so that compare is not logical due different bases. Any other discussion about the low byte of 48 bit colors is useless because: $8001 is in 24 bits the same as $80FF in 24 bits, and there is not proper upscaling, as clMaroon is not $8080 nor $8000, nor $80FF. It is a 48 bits value defined by somebody using any upscaling or downscaling technique. Colorimetric is a "dangerous" field for programmers. We are used to think in RGB values, but once you work a bit with temperature or different codifications like YUV, YUY, CMYK or any other you end knowing that 2+2=2.12321+-2*pi when the wind blows from the north :) GG> But yes I understand the most accurate would be to only downscale - but I GG> can't find color name definitions in 48-bit color. As 24 bit versions of cl colors are compatible with Delphi any 48 bit definition is valid from my point of view. -- Best regards, JoshyFun ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] procedure ... message(); in Linux
What messages does it capture ? How to send a message from a thread ? How to send a message from another process ? I do know that there are other (supposedly more decent) ways to do inter-thread and inter-process communication, But as procedure...message(), does compile in a Linux executable, I'd like to know how it's supposed to be used. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
JoshyFun wrote: > > To base change colors you must change from high resolution to lower > resolution, not the inverse, you should not define colors in 48 bits > based in their values of 24 bits, but the inverse. Yes, that is always ideal, but I can only work with what I know and what I can find on the internet. If you have a link on the internet that defines color values in 48bit, then please do post it here. I have search for the last 30 minutes and haven't found a single link. All colors I could find are defined as 24-bit RGB values (certified values and color names created by companies like Microsoft, HP, Adobe, W3C, Exif etc.), so that is what I based my calculations on. Using ratios to do the upscaling calculation seems to be the most common conversion method too - as per the links I found on the internet (wikipedia and many websites like Adobe or other photographic websites). But yes I understand the most accurate would be to only downscale - but I can't find color name definitions in 48-bit color. > That's why things like Pantone exists as they provide a clear > definition of each color. I'll read some more on Pantone - I don't really know much about it. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Hello Graeme, Wednesday, February 17, 2010, 1:27:30 PM, you wrote: GG> Yes, but I'm not limiting my calculation based 24-bit color only. I'm GG> working with the ratio of red in 24-bit color and applying that same ration GG> to 48-bit color. That should mean the two colors are the same. Now using GG> such a ratio with the known 24-bit colors does not equate in all cases to GG> the 48-bit color definitions in fpImage. They are close, but not equal. Instead using the known equivalences, reduce the conversion to an absurd situation. You are using 24 bits as your base, but thats an arbitrary base, so change it to 1 bit base and you get that half of color wheel is white and the other half is black. To base change colors you must change from high resolution to lower resolution, not the inverse, you should not define colors in 48 bits based in their values of 24 bits, but the inverse. Some values in any base are clear to be calculated, like black, white and all gray tones (in any color primitive) as in example gray is white/2 which is in 48 bits $8080 and $80 in 24. A different case is maroon, if you define maroon as a 50% red you get a 48 bits $8080, but maroon has not such definition as it is a subjetive perception so both $8080 and $8000 are completly valid and both renders to the same value in 24 bits. If you transcode up from 24 to 48 bits the right values is $8080 but you are doing a bad transcode for color definition, because you are upscaling a values instead downscaling it. That's why things like Pantone exists as they provide a clear definition of each color. In example, pantone define a (one of them) 24 bit maroon as $844A5A in 24 bits space, to me it is a bit of pink, but for Pantone it is maroon. -- Best regards, JoshyFun ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Zitat von Luiz Americo Pereira Camara : Mattias Gaertner escreveu: On Wed, 17 Feb 2010 06:52:25 -0300 Luiz Americo Pereira Camara wrote: fpimage is not documented at all AFAIK. It's not loosing bits if your information, in previous mail, about TFPColor format is correct. Defining colGray, and related, as TFPColor = (Red: $8080; Green: $8080; Blue: $8080; Alpha: alphaOpaque) would make it work. ... would make it work with a 24bit color image that uses one pixel color conversion *$101, div $100. It won't work on a 24bit color image that uses color conversion *$100, div $100 or on any other format. Are you saying that TFPColor is just a container for any 48bit format and has not a defined format? It is defined as a RGBA format. AFAIK there is no definition how TFPCustomImage.Get/SetColor map this to 24bit RGB. The point is that the TFPColor constants are inconsistently defined. $8000 is exactly the middle. It is the right value for gray. OK. If i understand correctly, you are saying that in TFPColor format $ means black (no color in the channel) $ means white (full color in the channel) and between them you get the remaining intensity. Assuming that, giving a color in 24bit RGB (one byte per channel) where $00 means no color $FF full color, if a channel is on the middle ($80 = 128) it would be equivalent to $8000 in the 48bit format, right? LazIntfImage is returning $8080. The LCL uses the $101 to get full 16bit white/black, and full alpha/opaque, so you can use Colors[x,y]=colWhite and Colors[x,y].Alpha=alphaOpaque. This makes porting many algorithms easier. About gray: gray is the middle between black and white. But the middle between black (0) and white (255) is 127.5 which does not fit into 8bit. So a gray of $80 is somewhat to bright. The LCL converts $80 to $8080 which is also somewhat above the real gray in 16 bit: $7fff.8 (32767.5). If channel is $40 (=64) in 24bit, it should not map to $4000 in 48bit? LazIntfImage is returning $4040 If channel is $2 (=2) in 24bit, it should not map to $0200 in 48bit? LazIntfImage is returning $2020 If channel is $1 (=1) in 24bit, it should not map to $0100 in 48bit? LazIntfImage is returning $1010 AFAIK, it should not be difficult to fix that (assuming is broken). All in all, this is not an issue for me and i won't take any longer if other agree that there's nothing broken. IMO nothing is broken, just gray is a rounded value and converting a rounded value between various precisions creates rounding errors. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
In our previous episode, Felipe Monteiro de Carvalho said: > I think it's possible for you to write your own memory manager which > stores data about memory blocks in a table instead and is then able to > check if the pointer is valid or not. Some operations would be slower > in this case, but also safer. Such stuff is routinely done in debugging memory managers. Afaik fastmm does this on Delphi. Together with having barriers before and after the allocation that are checked regularly to see if they are overwritten. One could also fill deallocated blocks with random garbage. (trashing memmanager), afaik there is a simple one on BDN for Delphi that does this. It lowers speed, but one can use it to find bugs/validate(*) an app, if possible at lower speed, and then switch back to the normal one. The FPC functionality to trash local vars (-gt) is also useful in this regard. (*) of course such validation is never 100% ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] MemSize argument validity
Hello Felipe, Wednesday, February 17, 2010, 12:56:15 PM, you wrote: FMdC> I think it's possible for you to write your own memory manager which FMdC> stores data about memory blocks in a table instead and is then able to FMdC> check if the pointer is valid or not. Some operations would be slower FMdC> in this case, but also safer. heaptrc has some settings for that. I think they are between defines so a recompile is needed but it performs that checks with a serious speed penalty and a very big penalty in memory needed. -- Best regards, JoshyFun ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote: Michael Van Canneyt wrote: You happen choose to use the ratio as the basis of your definition. Someone else may decide on some other definition. Who is right ? Like I said, you must have a 48-bit definition of Maroon. Only then you can correctly define maroon in TFPColor. Michael, didn't you write fpImage (as far as I know)? So what color metric did you use? :-) NOTE: SubVersion history only goes back to 2005 when it was imported from CVS, so I do not have a full history of fpimage.pp unit and can't tell who the original author was. Luk Vandelaer, my collega and friend, implemented it under my supervision. My responses are based on my discussions with him. fpImage by itself does not use presuppose any metric. There are various conversion mechanisms implemented, that is all. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Michael Van Canneyt wrote: > > You happen choose to use the ratio as the basis of your definition. > Someone else may decide on some other definition. Who is right ? > > Like I said, you must have a 48-bit definition of Maroon. > Only then you can correctly define maroon in TFPColor. Michael, didn't you write fpImage (as far as I know)? So what color metric did you use? :-) NOTE: SubVersion history only goes back to 2005 when it was imported from CVS, so I do not have a full history of fpimage.pp unit and can't tell who the original author was. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Graeme Geldenhuys wrote: > value per 48-bit color channel (65536) I calculated the same 48-bit red > channel color. 65536 * 0.5 = 32768 = in hex $8080. Sorry, I'm talking bull here! :-/ No idea how I got to $8080. 32768 is $8000 in hex. > 128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in > 48-bit) color. I see my problem! I used 255 as the max value per channel (24-bit color), when it should have been 256. :-( Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote: Luiz Americo Pereira Camara wrote: Assuming that, giving a color in 24bit RGB (one byte per channel) where $00 means no color $FF full color, if a channel is on the middle ($80 = 128) it would be equivalent to $8000 in the 48bit format, right? LazIntfImage is returning $8080. If channel is $40 (=64) in 24bit, it should not map to $4000 in 48bit? LazIntfImage is returning $4040 Exactly! :) Using the same ratio of each color channel defined in a known 24-bit range and upscaling it to 48-bit (keeping the same ratio), not all definitions in fpImage are correct. They are close, but not 100% correct. The ratio is just one of many possible color metrics. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote: Michael Van Canneyt wrote: As defined by fpImage unit. colMaroon : TFPColor = (Red: $8000; Green: $; Blue: $; Alpha: alphaOpaque); This is *incorrect*. It should be: colMaroon : TFPColor = (Red: $8080; Green: $; Blue: $; Alpha: alphaOpaque); This is not so. Both definitions are - within the 256-bit color plane - 100% equivalent. I'm no color expert (maybe that shows), but I based the calculation on ratio information only. Maroon has a red channel value in 24-bit color set to $80. That's 128/256 giving you a 0.5 ratio. But this ratio is not *the* definition of maroon. You happen choose to use the ratio as the basis of your definition. Someone else may decide on some other definition. Who is right ? Like I said, you must have a 48-bit definition of Maroon. Only then you can correctly define maroon in TFPColor. I was once asked to define a metric for colors. There are many metrics available, more than I imagined. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Luiz Americo Pereira Camara wrote: > > Assuming that, giving a color in 24bit RGB (one byte per channel) where > $00 means no color $FF full color, if a channel is on the middle ($80 = > 128) it would be equivalent to $8000 in the 48bit format, right? > LazIntfImage is returning $8080. > > If channel is $40 (=64) in 24bit, it should not map to $4000 in 48bit? > LazIntfImage is returning $4040 Exactly! :) Using the same ratio of each color channel defined in a known 24-bit range and upscaling it to 48-bit (keeping the same ratio), not all definitions in fpImage are correct. They are close, but not 100% correct. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Michael Van Canneyt wrote: >> As defined by fpImage unit. >> >> colMaroon : TFPColor = (Red: $8000; Green: $; Blue: $; Alpha: >> alphaOpaque); >> >> >> This is *incorrect*. It should be: >> >> colMaroon : TFPColor = (Red: $8080; Green: $; Blue: $; Alpha: >> alphaOpaque); > > This is not so. > > Both definitions are - within the 256-bit color plane - 100% equivalent. I'm no color expert (maybe that shows), but I based the calculation on ratio information only. Maroon has a red channel value in 24-bit color set to $80. That's 128/256 giving you a 0.5 ratio. Using that ratio and the max value per 48-bit color channel (65536) I calculated the same 48-bit red channel color. 65536 * 0.5 = 32768 = in hex $8080. 128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in 48-bit) color. So using the same ratio for both 24-bit and 48-bit color, colMaroon is incorrectly defined in fpImage. Now lets apply the same ratio math to colDkGray. colDkGray : TFPColor = (Red: $4000; Green: $4000; Blue: $4000; Alpha: alphaOpaque); I know the RGB (24-bit color) of DarkGray is $40 for the Red channel. So lets calculate the ratio or the Red channel and upscale it to 48-bit color. $40 hex = 64 decimal. 64/256 = 0.25 ratio 0.25 * 65536 max color per 48-bit channel = 16384 decimal 16384 dec = $4000 hex. So based on the definition of colDkGray, the ratio of the red channel is equivalent to the known 24-bit color ratio. So colDrGray is correctly defined in fpImage, but colMaroon is not. I worked with values I know. I only know the hex values of Maroon and DarkGray in 24-bit color. I tried to use Google to find the exact hex values in 48-bit color, but couldn't find any clear information. Hence the reason I upscaled the 24-bit color channel ratios to 48-bit. So having the same color channel ratios in both 24-bit and 48-bit should equate to the same color. > Even the following would be maroon in the 256-bit color plane. > >colMaroon : TFPColor = (Red: $80FF; Green: $; Blue: $; Alpha: > alphaOpaque); Yes, but I'm not limiting my calculation based 24-bit color only. I'm working with the ratio of red in 24-bit color and applying that same ration to 48-bit color. That should mean the two colors are the same. Now using such a ratio with the known 24-bit colors does not equate in all cases to the 48-bit color definitions in fpImage. They are close, but not equal. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
I would immediately think that the memory size could either be stored at a negative offset in the memory block or in a table. Looking at the standard implementation in FPC it uses a negative offset: from heap.inc: function SysMemSize(p: pointer): ptruint; begin result := pmemchunk_fixed(pointer(p)-sizeof(tmemchunk_fixed_hdr))^.size; if (result and fixedsizeflag) = 0 then begin result := result and sizemask; dec(result, sizeof(tmemchunk_var_hdr)); end else begin result := result and fixedsizemask; dec(result, sizeof(tmemchunk_fixed_hdr)); end; end; So it's impossible with this implementation to check if the pointer is valid or not. I think it's possible for you to write your own memory manager which stores data about memory blocks in a table instead and is then able to check if the pointer is valid or not. Some operations would be slower in this case, but also safer. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Mattias Gaertner escreveu: On Wed, 17 Feb 2010 06:52:25 -0300 Luiz Americo Pereira Camara wrote: fpimage is not documented at all AFAIK. It's not loosing bits if your information, in previous mail, about TFPColor format is correct. Defining colGray, and related, as TFPColor = (Red: $8080; Green: $8080; Blue: $8080; Alpha: alphaOpaque) would make it work. ... would make it work with a 24bit color image that uses one pixel color conversion *$101, div $100. It won't work on a 24bit color image that uses color conversion *$100, div $100 or on any other format. Are you saying that TFPColor is just a container for any 48bit format and has not a defined format? The point is that the TFPColor constants are inconsistently defined. $8000 is exactly the middle. It is the right value for gray. OK. If i understand correctly, you are saying that in TFPColor format $ means black (no color in the channel) $ means white (full color in the channel) and between them you get the remaining intensity. Assuming that, giving a color in 24bit RGB (one byte per channel) where $00 means no color $FF full color, if a channel is on the middle ($80 = 128) it would be equivalent to $8000 in the 48bit format, right? LazIntfImage is returning $8080. If channel is $40 (=64) in 24bit, it should not map to $4000 in 48bit? LazIntfImage is returning $4040 If channel is $2 (=2) in 24bit, it should not map to $0200 in 48bit? LazIntfImage is returning $2020 If channel is $1 (=1) in 24bit, it should not map to $0100 in 48bit? LazIntfImage is returning $1010 AFAIK, it should not be difficult to fix that (assuming is broken). All in all, this is not an issue for me and i won't take any longer if other agree that there's nothing broken. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote: Luiz Americo Pereira Camara wrote: The point is that the TFPColor constants are inconsistently defined. I see your point and agree. Some colors have both high and low byte set, some other colors do not. @Mattias What is the 48bit value for Maroon (#80)? R = $8000 or R = $8080 and Within 256-bit precision, you cannot say which one is correct. You MUST provide a 48 bit definition of Maroon, only then you can decide which one is correct. This is what Mattias is trying to say. Normal 256-bit colors correspond to a single type. 48-bit colors correspond to double type. You cannot say anything sensible about double values if your initial definition is based on a single value. assuming all the other values are $ As defined by fpImage unit. colMaroon : TFPColor = (Red: $8000; Green: $; Blue: $; Alpha: alphaOpaque); This is *incorrect*. It should be: colMaroon : TFPColor = (Red: $8080; Green: $; Blue: $; Alpha: alphaOpaque); This is not so. Both definitions are - within the 256-bit color plane - 100% equivalent. Even the following would be maroon in the 256-bit color plane. colMaroon : TFPColor = (Red: $80FF; Green: $; Blue: $; Alpha: alphaOpaque); Compare: 1.2 and 1.0 are, when considered with 0 decimal precision, the same value. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > > RTLString. > > > > This sets a precedent. > > Could you please resolve the issue with "won't be accepted" (or no > changes required)? It's not my decision alone. The whole problem with this unicode string is that there is no definitive roadmap, and the utf-8 ansistring is not ready. > The implementation is not only about RTL encoding, but system > environment as well, since it depends upon Windows *W function to be > available. True, but I'm not going to commit anything Windows only till the plans for the system environment are clear. On all relevant platforms. > But who cares about 9x these days?! :) I don't. But that is not even a problem; FPC has prepared long for this by having and UNICODE define in most windows headers. (afaik Peter already did when he translated windows unit originally), but specially the older bits are not test and probably full of bugs. In theory, we could have a win32u target that sets UNICODE and switch the default of most functions to unicode, like D2009+. It is probably going to happen that way anyway, sooner or later. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
In our previous episode, Jonas Maebe said: > > I've just discovered that passing an invalid pointer to MemSize() > > results in a bogus value returned and no error generally reported. > > Is this intentional? > > It's just as intentional as dereferencing an invalid pointer can > result in a segmentation fault, that freemem'ing an invalid pointer > can corrupt the heap, etc. It's how manual memory management works: > the programmer is responsible for not making any errors with pointers. ... and that means assuming that you can't make out failsafe if a pointer is valid or not. One needs to manage that oneself. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Mattias Gaertner said: > > > > Could you please resolve the issue with "won't be accepted" (or no > > changes required)? > > > > The implementation is not only about RTL encoding, but system > > environment as well, since it depends upon Windows *W function to be > > available. But who cares about 9x these days?! :) > > Notes: > - Comparison is wrong under OS X, see lcl FileUtil.pas > - missing a note that files with broken UTF8 chars can not be read > under Linux. Maybe add a note where the system encoding file routines > are. > - ExtractRelativePath works Delphi compatible, but always case > insensitive, so not useful under Linux. On the implementation front I had some doubts about charinset. It doesn't seem to be locale aware and only treat the bottom 128 chars. Is this compatible? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Luiz Americo Pereira Camara wrote: > > The point is that the TFPColor constants are inconsistently defined. I see your point and agree. Some colors have both high and low byte set, some other colors do not. @Mattias What is the 48bit value for Maroon (#80)? R = $8000 or R = $8080 and assuming all the other values are $ As defined by fpImage unit. colMaroon : TFPColor = (Red: $8000; Green: $; Blue: $; Alpha: alphaOpaque); This is *incorrect*. It should be: colMaroon : TFPColor = (Red: $8080; Green: $; Blue: $; Alpha: alphaOpaque); 128/255 = 32896/65536 = red channel $80 (in RGB 24-bit) or $8080 (in 48-bit) color. I think this is the point Luiz is trying to make. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On 02/17/2010 09:54 AM, Michael Van Canneyt wrote: > The class exists since 8 years, so we're not going to change that. I understand :( -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010 06:52:25 -0300 Luiz Americo Pereira Camara wrote: > Mattias Gaertner escreveu: > > On Wed, 17 Feb 2010 04:39:26 -0300 > > Luiz Americo Pereira Camara wrote: > > > > > >> Mattias Gaertner escreveu: > >> > >>> On Tue, 16 Feb 2010 17:15:37 -0300 > >>> Luiz Americo Pereira Camara wrote: > >>> > >>> > >>> > or > > colGray be redefined as colGray : TFPColor = (Red: $8080; Green: > $8080; Blue: $8080; Alpha: alphaOpaque) ?? > > > >>> Yes, although this rarely makes a difference. > >>> > >>> > >> It does. > >> See below. > >> > >> > >>> > >>> > >>> > This info will help to fix http://bugs.freepascal.org/view.php?id=15793 > > > >>> IMO the bug report is misleading. Converting a TFPColor to RGB looses > >>> bits. > >>> > >> The bug is not about converting to RGB. See the attached example in > >> bugreport. > >> > >> SetCol := colGray; > >> Img.Colors[0,0] := SetCol; > >> GetCol := Img.Colors[0,0]; > >> > >> SetCol <> GetCol > >> > > > > That's exactly what my long response explained. > > Why do you expect that the 48bit color constants can be assigned to > > 24bit images without loss? Is this somewhere wrongly documented? > > > > fpimage is not documented at all AFAIK. > > It's not loosing bits if your information, in previous mail, about > TFPColor format is correct. > > Defining colGray, and related, as TFPColor = (Red: $8080; Green: $8080; > Blue: $8080; Alpha: alphaOpaque) would make it work. ... would make it work with a 24bit color image that uses one pixel color conversion *$101, div $100. It won't work on a 24bit color image that uses color conversion *$100, div $100 or on any other format. > The point is that the TFPColor constants are inconsistently defined. $8000 is exactly the middle. It is the right value for gray. Your comparison is wrong. It is as wrong as: ASingle := ADouble; if ASingle<>ADouble then ... Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Thanks Mattias, i'll do proper changes to file name comparison functions. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
Michael Schnell schreef: On 02/17/2010 09:57 AM, Michael Van Canneyt wrote: I agree that the name is confusing, but it has historical roots. Thus I vote for changing it. Fork the fpc packages directory. Then you can make your vote count. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Wed, 17 Feb 2010 12:34:35 +0300 dmitry boyarintsev wrote: > On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: > > Reject as far as I'm concerned. I'd like to see the RTL being in the system > > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > > RTLString. > > > > This sets a precedent. > > Could you please resolve the issue with "won't be accepted" (or no > changes required)? > > The implementation is not only about RTL encoding, but system > environment as well, since it depends upon Windows *W function to be > available. But who cares about 9x these days?! :) Notes: - Comparison is wrong under OS X, see lcl FileUtil.pas - missing a note that files with broken UTF8 chars can not be read under Linux. Maybe add a note where the system encoding file routines are. - ExtractRelativePath works Delphi compatible, but always case insensitive, so not useful under Linux. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On 02/17/2010 09:57 AM, Michael Van Canneyt wrote: > I agree that the name is confusing, but it has historical roots. Thus I vote for changing it. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Mattias Gaertner escreveu: On Wed, 17 Feb 2010 04:39:26 -0300 Luiz Americo Pereira Camara wrote: Mattias Gaertner escreveu: On Tue, 16 Feb 2010 17:15:37 -0300 Luiz Americo Pereira Camara wrote: or colGray be redefined as colGray : TFPColor = (Red: $8080; Green: $8080; Blue: $8080; Alpha: alphaOpaque) ?? Yes, although this rarely makes a difference. It does. See below. This info will help to fix http://bugs.freepascal.org/view.php?id=15793 IMO the bug report is misleading. Converting a TFPColor to RGB looses bits. The bug is not about converting to RGB. See the attached example in bugreport. SetCol := colGray; Img.Colors[0,0] := SetCol; GetCol := Img.Colors[0,0]; SetCol <> GetCol That's exactly what my long response explained. Why do you expect that the 48bit color constants can be assigned to 24bit images without loss? Is this somewhere wrongly documented? fpimage is not documented at all AFAIK. It's not loosing bits if your information, in previous mail, about TFPColor format is correct. Defining colGray, and related, as TFPColor = (Red: $8080; Green: $8080; Blue: $8080; Alpha: alphaOpaque) would make it work. The point is that the TFPColor constants are inconsistently defined. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
On Wed, 17 Feb 2010 04:39:26 -0300 Luiz Americo Pereira Camara wrote: > Mattias Gaertner escreveu: > > On Tue, 16 Feb 2010 17:15:37 -0300 > > Luiz Americo Pereira Camara wrote: > > > > > >> or > >> > >> colGray be redefined as colGray : TFPColor = (Red: $8080; Green: > >> $8080; Blue: $8080; Alpha: alphaOpaque) ?? > >> > > > > Yes, although this rarely makes a difference. > > > > It does. > See below. > > > > > > >> This info will help to fix http://bugs.freepascal.org/view.php?id=15793 > >> > > > > IMO the bug report is misleading. Converting a TFPColor to RGB looses > > bits. > > The bug is not about converting to RGB. See the attached example in > bugreport. > > SetCol := colGray; > Img.Colors[0,0] := SetCol; > GetCol := Img.Colors[0,0]; > > SetCol <> GetCol That's exactly what my long response explained. Why do you expect that the 48bit color constants can be assigned to 24bit images without loss? Is this somewhere wrongly documented? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MemSize argument validity
On 16 Feb 2010, at 19:11, Nikolai Zhubr wrote: I've just discovered that passing an invalid pointer to MemSize() results in a bogus value returned and no error generally reported. Is this intentional? It's just as intentional as dereferencing an invalid pointer can result in a segmentation fault, that freemem'ing an invalid pointer can corrupt the heap, etc. It's how manual memory management works: the programmer is responsible for not making any errors with pointers. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: > Reject as far as I'm concerned. I'd like to see the RTL being in the system > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > RTLString. > > This sets a precedent. Could you please resolve the issue with "won't be accepted" (or no changes required)? The implementation is not only about RTL encoding, but system environment as well, since it depends upon Windows *W function to be available. But who cares about 9x these days?! :) thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
dmitry boyarintsev schreef: On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: Reject as far as I'm concerned. I'd like to see the RTL being in the system encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted RTLString. Vincent, is there a place in CCR for the run-time package? Yes. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On Wed, 17 Feb 2010, Michael Schnell wrote: On 02/17/2010 09:25 AM, Michael Van Canneyt wrote: I don't see a point in an event queue, since TCustomApplication is also meant for non-event-driven (or queueing) applications; Of course. I only vote for a hook. If it is not used it's just a non-event-driven application (command line tool or nonpersistent CGI). What's more event queues can take wildly different forms in terms of implementation, so it's hard to create a catch-all hook for that. I do see this, and this is exactly why I think such a hook would be great (even if not that easily done). Having a standard type (class) for all events (similar to the exception type), would allow for a much more standardized management of the events. According to the topic of this thread a central logging of the events for debugging would be enabled, Despite the name TEventLog, it has nothing to do with events. It's a logging facility. I agree that the name is confusing, but it has historical roots. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On Wed, 17 Feb 2010, Michael Schnell wrote: On 02/17/2010 09:37 AM, Graeme Geldenhuys wrote: This is another issue I wanted to raise about TEventLog. Is the name TEventLog set ? Yes. The name stems from the Windows 'Event Viewer' system logging facility. The class exists since 8 years, so we're not going to change that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On 02/17/2010 09:37 AM, Graeme Geldenhuys wrote: > > This is another issue I wanted to raise about TEventLog. > Is the name TEventLog set ? IMHO this is not a good name, as TEvent is a class already provided (at least in Delphi/Lazarus) and moreover an "Event" in ObjectPascal already has a dual meaning (a classical Callback from an object and a synchronized "interrupt" generated by an asynchronous trigger (such as timer or mouse click), managed by an "EventQueue". So please don't introduce a forth meaning of "Event". -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On 02/17/2010 09:25 AM, Michael Van Canneyt wrote: > > I don't see a point in an event queue, since TCustomApplication is also > meant for non-event-driven (or queueing) applications; Of course. I only vote for a hook. If it is not used it's just a non-event-driven application (command line tool or nonpersistent CGI). > What's more event queues can take wildly different forms in terms of > implementation, so it's hard to create a catch-all hook for that. I do see this, and this is exactly why I think such a hook would be great (even if not that easily done). Having a standard type (class) for all events (similar to the exception type), would allow for a much more standardized management of the events. According to the topic of this thread a central logging of the events for debugging would be enabled, For the future I dream of enabling event-driven (queuing) threads, that each instantiate it's own event queue using an extension of the "nogiu" paradigm, I am working on, withing a GUI or NoGUI application. Imagine an extension of this to inter-thread-event firing, allowing for "parallel" loops -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote: Michael Schnell wrote: Of course the logging functions would need to be thread-safe ! This is another issue I wanted to raise about TEventLog. * Is it thread safe? At first glance I can't see that it is. It's only not safe when writing to a file. * When loging to file, no cached loging is used, so this will seriously slow down your application. If you debug something like the Visitor pattern, you generate a huge about of log entries. This can be remedied easily. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
Michael Schnell wrote: > > Of course the logging functions would need to be thread-safe ! This is another issue I wanted to raise about TEventLog. * Is it thread safe? At first glance I can't see that it is. * When loging to file, no cached loging is used, so this will seriously slow down your application. If you debug something like the Visitor pattern, you generate a huge about of log entries. tiOPF solves both of these, so we could steal ideas from there and implement it inside TEventLog. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
No comment on the idea of converting dynamically typed string constants at the first touch in realtime ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On Wed, 17 Feb 2010, Michael Schnell wrote: On 02/16/2010 05:38 PM, Joost van der Sluis wrote: And it is because I want to have a 'global' logging system available. But the application has to implement it. Of course the logging functions would need to be thread-safe ! IMHO it would be nice if TCustomapplication would have a hook for the event-queue, so that different event queue implementations (like TApplication and the (upcoming) TNoGUIApplication ) can be done as a plugin. I don't see a point in an event queue, since TCustomApplication is also meant for non-event-driven (or queueing) applications; What's more event queues can take wildly different forms in terms of implementation, so it's hard to create a catch-all hook for that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On 02/16/2010 05:38 PM, Joost van der Sluis wrote: > And it is because I want to have a 'global' logging system available. > But the application > has to implement it. > Of course the logging functions would need to be thread-safe ! IMHO it would be nice if TCustomapplication would have a hook for the event-queue, so that different event queue implementations (like TApplication and the (upcoming) TNoGUIApplication ) can be done as a plugin. In combination with the said logging functions, optionally enabling a global log of the queue events and exception events would be really nice to have ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Wed, Feb 17, 2010 at 11:15 AM, Marco van de Voort wrote: > Reject as far as I'm concerned. I'd like to see the RTL being in the system > encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted > RTLString. Vincent, is there a place in CCR for the run-time package? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Vincent Snijders said: > dmitry boyarintsev schreef: > > Reported: http://bugs.freepascal.org/view.php?id=15795 > > > > It's up to FPC team to accept or reject the package. > > Thanks, I will monitor the issue to see the outcome. Reject as far as I'm concerned. I'd like to see the RTL being in the system encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted RTLString. This sets a precedent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
