Hi,
For the people who don't know it already, how Unicode is handled in MSEgui for
FPC 2.4:
- All GUI relevant string parameters and variables and all DB-Field strings
are of type msestring, all characters are of type msechar.
- MSEgui has a set of file handling routines with parameters of
Hello,
Von: Martin laza...@mfriebe.de
Just to make sure I don't to anything silly.
When an application crashes, it usually (at least in Lazarus) dumps a
stacktrace to the console.
I used to use stabs, and the stacktrace was dumped in less than a
second. Now I have switched to dwarf
- There is only one encoding in MSEgui framework, it is the same on all
platforms.
Which is performance wise neither a good decision.
- In the majority of cases the fast and convenient character access by index
can be used. This is important for beginners.
- The current FPC
In our previous episode, Martin Schreiber said:
- The current FPC UnicodeString is fast, simple, has little overhead and is
well tested.
Do you have any benchmark data on the overhead that delphi adds ? Because I
don't think it is much slower if all strings are initialized on the same
encoding
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
Hello,
Von: Martin laza...@mfriebe.de
Just to make sure I don't to anything silly.
When an application crashes, it usually (at least in Lazarus) dumps a
stacktrace to the console.
I used to use stabs, and the stacktrace was dumped in less than
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for
functionality that you hopefully won't need anyway.
Jonas
___
On Tue, 10 Nov 2009, Jonas Maebe wrote:
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for functionality that
you hopefully won't need anyway.
Correct.
But
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug input has
been encapsuled in the two ReadNext() methods in the file mentioned. It should
be easy to make them to read from a (static?) buffer that is filled blockwise;
note that a static buffer may give
Micha Nelissen schreef:
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug
input has been encapsuled in the two ReadNext() methods in the file
mentioned. It should be easy to make them to read from a (static?)
buffer that is filled blockwise; note that a
Paul Ishenin wrote:
3. RawByteString type (an ansi string type which does not perform any
codepage conversions) with compiler support.
A great idea ! I would have requested this if it would not be already
planned :).
-Michael
___
fpc-devel maillist
Paul Ishenin wrote:
4. Most of codepage convertion methods and string type convertion
methods (ansistring = unicodestring = widestring)
Does this mean that the compiler already automatically calls the
appropriate conversion, but the code that actually performs it is not
yet implemented in the
Martin Schreiber wrote:
Performance and simplicity. MSEgui does not need the overhead of
multi-encoding/multi-charsize. At the moment msestring=UnicodeString for FPC
2.4 which is perfect. I fear FPC will drop this simple solution where it was
ahead of Delphi.
Hmmm. I suppose with Linux
On 10 Nov 2009, at 11:57, Michael Van Canneyt wrote:
But let's start by improving efficiency, the MT issue can follow
later :-)
I disagree. I think correctness should always be more important than
efficiency, especially for RTL functions (and in particular when it's
about debugging
On 10 Nov 2009, at 08:35, dmitry boyarintsev wrote:
There're 2 ways to define indirect symbol by the compiler:
tai_const with type aitconst_indirect_symbol
or
tai_directive with asd_indirect_symbol
either way produces identical assembler output:
.indirect_symbol %symbol_name
So i'm
On Tue, Nov 10, 2009 at 3:50 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
I think simply that I forgot that one way was already available when I added
the other way :) It's fine to remove either one.
hmm... I'll try to make the patch.
thanks,
dmitry
I don't see why using D2009 strings would hurt that much.
If there is a compiler option to encode string constants as utf-16 or
maybe an additional plain 16 Bit String type, that encoding would
automatically be used for the Strings and thus all have the same
encodings and in fact are reference
On Tue, Nov 10, 2009 at 7:33 AM, Florian Klaempfl
flor...@freepascal.org wrote:
- There is only one encoding in MSEgui framework, it is the same on all
platforms.
Which is performance wise neither a good decision.
Could be, if are writing a specialized command line tool or something like
Michael Schnell wrote:
Paul Ishenin wrote:
4. Most of codepage convertion methods and string type convertion
methods (ansistring = unicodestring = widestring)
Does this mean that the compiler already automatically calls the
appropriate conversion, but the code that actually performs
Vincent Snijders wrote:
Micha Nelissen schreef:
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug
input has been encapsuled in the two ReadNext() methods in the file
mentioned. It should be easy to make them to read from a (static?)
buffer that is filled
Martin Schreiber schrieb:
On Tuesday 10 November 2009 12:45:26 Michael Schnell wrote:
Martin Schreiber wrote:
Performance and simplicity. MSEgui does not need the overhead of
multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
FPC 2.4 which is perfect. I fear FPC will
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say you
will not notice the small difference. But
Martin Schreiber escreveu:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say you
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring routine won't get additional checks.
and more
Hello,
I'd like to help with the experimental LLVM backend if anyone is interested.
It's been years since I've used Pascal though, so perhaps my familiarity with C
and C++ on the LLVM end will be beneficial.
While we're on the subject, LLVM has a very powerful optimizer that, when used
in
On Tue, 10 Nov 2009, Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
Where? A pure unicodestring routine won't get additional checks.
What is a pure unicodestring routine?
and more complicated address calculation.
Where? Adding 16 instead of 12 makes no difference.
The major difference will be
Martin Schreiber schrieb:
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
Where? A pure unicodestring routine won't get additional checks.
What is a pure unicodestring routine?
No other string types being involved especially things like RawByteString.
and more complicated
On Tuesday 10 November 2009 20:20:06 Florian Klaempfl wrote:
OK, so you say that the processing of the new and the current
UnicodeString and therefore the RTL and compiler procedures are identical
with exception of the initialization of 4 bytes with a constant?
Well, two times two byte ;)
On 10 Nov 2009, at 19:28, Samuel Crow wrote:
I'd like to help with the experimental LLVM backend if anyone is
interested. It's been years since I've used Pascal though, so
perhaps my familiarity with C and C++ on the LLVM end will be
beneficial.
Thanks for the offer!
While we're on
Vincent Snijders vsnijd...@vodafonevast.nl:
Micha Nelissen schreef:
Allocating that buffer on the stack isn't sufficient?
That's not easy when the exception is raised in case of a stack overflow.
In case of a stack overflow *anything* using the stack is doomed. But if we're
talking
Hello Jonas,
(Replies inline.)
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, November 10, 2009 1:57:03 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
The main things that basically halted my
In our previous episode, Michael Schnell said:
multi-encoding/multi-charsize. At the moment msestring=UnicodeString for
FPC
2.4 which is perfect. I fear FPC will drop this simple solution where it
was
ahead of Delphi.
Hmmm. I suppose with Linux (using utf-8 for the GUI interface
Marco van de Voort wrote:
Neither do I.
While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.
Just to make a small point: the choice
In our previous episode, thaddy said:
Marco van de Voort wrote:
While I think it would be best to use native encoding on all platforms as
much as possible, that is an opinion. However not using native encoding for
general processing is nuts. So we need the UTF8 type anyway.
Just to make
On 10 Nov 2009, at 21:35, Samuel Crow wrote:
The current way to implement pointer arithmetic in LLVM is to use an
i64 for all instances of pointers
We can't do that at the high level, since then all pointer fields in
records etc would become 64 bit. And the low level currently assumes
In our previous episode, Jonas Maebe said:
With an LLVM backend, there will obviously be a dependency on LLVM
(either as a library or as an installed tool chain) and hence on its
dependencies, but it would be nice if we could be compatible with as
many different LLVM releases as
Vinzent Höfler wrote:
Vincent Snijders vsnijd...@vodafonevast.nl:
Micha Nelissen schreef:
Allocating that buffer on the stack isn't sufficient?
That's not easy when the exception is raised in case of a stack overflow.
In case of a stack overflow *anything* using the
On 10 Nov 2009, at 23:00, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
With an LLVM backend, there will obviously be a dependency on LLVM
(either as a library or as an installed tool chain) and hence on its
dependencies, but it would be nice if we could be compatible
Ivo Steinmann wrote:
Hello all
I started some wiki for dynamic loading libraries support discussion.
http://wiki.freepascal.org/Dynamically_loading_headers
I already added an experimental implementation. If you have got some
ideas, whises and criticism, don't hesitate to write.
-Ivo
On Tue, Nov 10, 2009 at 3:53 PM, dmitry boyarintsev
skalogryz.li...@gmail.com wrote:
hmm... I'll try to make the patch.
here's the one: http://bugs.freepascal.org/view.php?id=15050
Removing tai_const with indirect_symbol doesn't seem to harm the
generated asm code at all, at least for i386
Hello again Jonas,
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, November 10, 2009 3:46:59 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
I don't see any problem at all with announcing that
On Tuesday 10 November 2009 21:38:33 Marco van de Voort wrote:
The only problem is the db-aware part and the few other widgets that can
have 10 elements and more, like treeview. There mass conversion can
hurt, e.g. when loading the data into the widget.
That's the reason why MSEgui stores
42 matches
Mail list logo
