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
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?
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
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 notic
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
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)
>
>
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
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 s
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 fict
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+\)*.*
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
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.o
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
>
> 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
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
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
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 pointe
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 compi
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
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'
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 o
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
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 colGr
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
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
F
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
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,
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-b
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?
La
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: $00
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
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);
>
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
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: $808
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 Ma
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
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
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
> > avai
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
assum
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-de
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 Pereir
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
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
_
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.
> >
>
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/lis
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:
$8
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:
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 segmentati
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
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
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
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,
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
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
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
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 you
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
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 nic
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
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
_
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
61 matches
Mail list logo
