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 st
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> Sent: Tue, November 10, 2009 3:46:59 PM
> Subject: Re: [fpc-devel] LLVM Backend?
>
>
> On 10 Nov 2009, at 21:35, Samuel Crow wrote:
>
-snip-
> > Do the object-oriented features of FPC require name-demangled C bind
Hello again Jonas,
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> 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 people are working on an
> LLVM code generation backend
On Tue, Nov 10, 2009 at 3:53 PM, dmitry boyarintsev
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 target.
thanks,
dmitry
_
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 Steinmann
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 w
Vinzent Höfler wrote:
Vincent Snijders :
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
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 pos
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
th
Marco van de Voort schrieb:
> 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 t
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
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, 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
Hello Jonas,
(Replies inline.)
- Original Message
> From: Jonas Maebe
> To: FPC developers' list
> Sent: Tue, November 10, 2009 1:57:03 PM
> Subject: Re: [fpc-devel] LLVM Backend?
>
-snip-
> The main things that basically halted my work on the LLVM backend are:
> a) FPC does not pr
Vincent Snijders :
> 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 about checking the sta
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 the
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 b
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 comp
On Tuesday 10 November 2009 19:24:38 Michael Van Canneyt wrote:
>
> MSE boasts some 'great features'. Well, last time I checked
> (admittedly some time ago), MSE didn't even support 64-bits,
> while Lazarus does since many years.
>
It supports now Linux x86-64. I used about 110 hours for the adapti
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" differen
On Tuesday 10 November 2009 19:01:51 Luiz Americo Pereira Camara wrote:
> 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?
> >
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 con
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
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.
>
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
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".
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 F
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 drop this simple solu
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
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 perform
On 10 Nov 2009, at 15:05, Felipe Monteiro de Carvalho wrote:
But for GUI software the conversion speed impact is tiny, and the
head-ache caused be a string type whose encoding is not know is by far
much worse. Tons of string related code will stop working and need to
be adapted at the gain of a
On Tue, Nov 10, 2009 at 7:33 AM, Florian Klaempfl
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 that.
But for GUI
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 c
On Tue, Nov 10, 2009 at 3:50 PM, Jonas Maebe 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
___
fpc-devel mailli
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 wondering
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 helpe
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
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 i
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
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 st
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 hea
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 let'
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
___
fpc-de
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
Hello,
Von: Martin
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 h
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
encodin
>
> - 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 Unicode
Hello,
> Von: Martin
> 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 and the sa
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 type
48 matches
Mail list logo
