Hi,
I read there is a FPC target "Linux for x64_6432". Does FPC actually use the
extended register set for this target? Are there any benchmarks and
comparisons with i386 and x86-64 mode?
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepa
I am trying to cut down the time it takes to recompile fpc.
Is there a way to pass any thing to make, to tell it to skip building
the examples. I know COPYTREE to skip installing them, but I don't even
want to build them (after all, I am not using them). something like
"make all SKIP_EXAMPLES=
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed
the values.
Attached patch works here, and dump
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
Problem I have is how to deal with the open var param.
I need to be able to address the first (or other) byte of it
function ReadNext
Michael Van Canneyt wrote:
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
The main reason for this slowness is that that implementation (of
mine) reads debug info byte-by-byte from the input stream using
blockread(). I think this I/O the main performance bottleneck.
At that time I did not bothe
On Friday 13 November 2009 15:58:10 Michael Schnell wrote:
> So MSE-GUI creates it's own Widget set instead of using something like
> GTK. Is this really advantageous ?
>
Michael, you are joking, right? ;-)
Please join us on NNTP:
news://news.grid-sky.com/public.mseide-msegui.talk
to get answers t
Paul Ishenin wrote:
Florian Klaempfl wrote:
Probably something wrong with nested token replay.
Exactly. As I see, tscannerfile.startreplaytokens needs to be fixed.
It get the new buf and does preserve/restore the old. As result new
nested specialize brokes scanner.
I made a patch for this:h
Florian Klaempfl wrote:
Probably something wrong with nested token replay.
Exactly. As I see, tscannerfile.startreplaytokens needs to be fixed. It
get the new buf and does preserve/restore the old. As result new nested
specialize brokes scanner.
Best regards,
Paul Ishenin.
On 13 Nov 2009, at 15:39, Paul Ishenin wrote:
Jonas Maebe wrote:
I think he means that the rtl has to be compilable by the previous
release, so you have to exclude any enumerators you add during
bootstrapping.
Enumerators added using GetEnumerator method can't add problems with
compilatio
2009/11/13 Michael Van Canneyt :
>
>
> On Fri, 13 Nov 2009, Michael Schnell wrote:
>
>> So MSE-GUI creates it's own Widget set instead of using something like
>> GTK. Is this really advantageous ?
>
> Oh boy, this promises to start a long thread...
>
> ... which Jonas is likely to end if he gets fe
On Fri, 13 Nov 2009, Michael Schnell wrote:
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
Oh boy, this promises to start a long thread...
... which Jonas is likely to end if he gets fed up with it :-)
Michael.
Paul Ishenin schrieb:
> Hello, FPC developers' list
>
> I am trying to understand how to add an enumerator support to the fgl
> containers. Seems it is imposible.
>
> I need enumerator to return the same type as generic container. So I
> declared enumerator class as generic too. But how to use it
What should be done, to submit it to trunk?
Usually using bug tracker. But submit what? New enumerators for TBits?
Is yes then first let someone else decide (like Michael, Florian).
Sorry for unclear ask.
I don't need submit myself. I want to prepare good patch, which can be
submit, but to do
Hello, FPC developers' list
I am trying to understand how to add an enumerator support to the fgl
containers. Seems it is imposible.
I need enumerator to return the same type as generic container. So I
declared enumerator class as generic too. But how to use it inside the
generic container c
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Jonas Maebe wrote:
I think he means that the rtl has to be compilable by the previous
release, so you have to exclude any enumerators you add during
bootstrapping.
Enumerators added using GetEnumerator method can't add problems with
compilation. operator Enumerator of course will not compiler.
On 13 Nov 2009, at 15:06, Paul Ishenin wrote:
Dariusz Mazur wrote:
But should those enumerators exists in classes ?
For the basic containers I added enumerators since delphi have them.
How exclude enumerators for older compilers?
?
I think he means that the rtl has to be compilable by the
Dariusz Mazur wrote:
But should those enumerators exists in classes ?
For the basic containers I added enumerators since delphi have them.
How exclude enumerators for older compilers?
?
What should be done, to submit it to trunk?
Usually using bug tracker. But submit what? New enumerators for
Alexander Klenin pisze:
2009/11/11 Dariusz Mazur :
With this I have and question:
For me function FindNextRaw should be in protected section
But then we cant use them in enumerator, except when something like friend
classes can be used in FPC.
I only read about this concept, is it possibl
Zitat von Martin Schreiber :
On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote:
Michael Schnell wrote:
> Martin Schreiber wrote:
>> On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses somet
On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote:
> Michael Schnell wrote:
> > Martin Schreiber wrote:
> >> On Linux xlib and xft have utf-16 interfaces.
> >
> > What exactly are xlib and xft and why does MSE-GUI seemingly use those
> > while LCL seemingly uses something else ?
>
> Marti
Michael Schnell wrote:
> Martin Schreiber wrote:
>> On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses something else ?
Martin answered this already. But just to be clear, xlib and xft have
both utf-8
On Friday 13 November 2009 12:51:58 Michael Schnell wrote:
> Martin Schreiber wrote:
> > On Linux xlib and xft have utf-16 interfaces.
>
> What exactly are xlib and xft and why does MSE-GUI seemingly use those
> while LCL seemingly uses something else ?
>
xlib is the C-library used under Linux to c
Martin Schreiber wrote:
>>
> On Linux xlib and xft have utf-16 interfaces.
What exactly are xlib and xft and why does MSE-GUI seemingly use those
while LCL seemingly uses something else ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
On Friday 13 November 2009 10:16:46 Michael Schnell wrote:
>
> Why should the (future) lcl use "ANSIString". I suppose using ANSIString
> for UTF-8 data was just a nasty hack to do Unicode with the _current_
> FPC. (In contrast the MSE-GUI hack was using Widestring, which is less
> ambiguous and se
Florian Klaempfl wrote:
> Well, I guess you're talking about lazarus ;) I don't see yet however,
> if and how the ansistring abuse in the lcl will bite one ...
Why should the (future) lcl use "ANSIString". I suppose using ANSIString
for UTF-8 data was just a nasty hack to do Unicode with the _curr
26 matches
Mail list logo
