Op Tue, 2 Dec 2008, schreef Michael Schnell:
I supposed one of the main intentions for the move to Unicode was the ability
to support Chinese above all. So they did not seem to have been content with
what was done before.
Is anybody from China here to offer the footage ?
It is not the
Op Tue, 2 Dec 2008, schreef Alexander Klenin:
On Fri, Nov 28, 2008 at 07:59, Daniël Mantione
[EMAIL PROTECTED] wrote:
One time, during a programming contest, the jury had written their solution
to a problem in Java. A 10MB output file had to be written. Their
implementation took about 15
Op Mon, 1 Dec 2008, schreef Felipe Monteiro de Carvalho:
The real world problem is (as Florian wrote): Some platforms have no
choice, because they only support 'ansi'.
This one is trivial to solve. Lazarus supports utf-8 everywhere,
including Windows 98 which doesn't support unicode. All
Op Fri, 28 Nov 2008, schreef Leonardo M. Ramé:
Hi, does anyone knows if somebody is working on something like Pascal
Applets, similar to Java Applets or Flash, but made in Object Pascal.
I need this to be able to record microphone sound through the browser, and I
know the only way to do
Op Fri, 28 Nov 2008, schreef dmitry boyarintsev:
How about writing a browser plugin? You should be able to do that in Pascal.
You may have to do some pioneering work, making the Netscape plugin API
available in Pascal, otherwise it should work and be cross-platform.
is that the API?
Op Thu, 27 Nov 2008, schreef Felipe Monteiro de Carvalho:
On Thu, Nov 27, 2008 at 1:17 PM, Marco van de Voort [EMAIL PROTECTED] wrote:
Besides the pure language problem, there is also the library problem. Java
and .NET are more than just a bytecode specification, there are also vast
standard
Op Tue, 25 Nov 2008, schreef David Finkelstein:
Since nobody responded to my entry Distracting Scan Lines or Slow Display in Full
Screen Mode that I posted on November 11th, let me put it a
different and very blunt way:
GoToXY, Clrscr, Clreol, Write, and Writeln that worked fine in Turbo
Op Sun, 23 Nov 2008, schreef listmember:
What I had in mind wasn't to store the string data in UTF-32 (or UCS-4); it
would still be UTF-8 or whatever.
I am only considering in memory representation being UTF-32 (or UCS-4).
This way, loading from and saving to would hardly be affected, yet
Op Sun, 23 Nov 2008, schreef listmember:
On 2008-11-23 14:10, Daniël Mantione wrote:
Therefore, any other encoding is a waste of memory and does not gain you
any speed. For that reason, I don't see the compiler switch from 8-bit
processing either.
I nearly fully agree with you.
Except
Op Sun, 23 Nov 2008, schreef Jonas Maebe:
On 23 Nov 2008, at 13:31, Daniël Mantione wrote:
For an IDE, this is a little bit more complicated. I.e. searching for a ç
in a source file needs to find both the composed and the decomposed
variant, and in the case of UTF-8, this character can
Op Sun, 23 Nov 2008, schreef Marco van de Voort:
In our previous episode, Martin Schreiber said:
[ Charset ISO-8859-1 unsupported, converting... ]
On Sunday 23 November 2008 13.44:02 Mattias Gaertner wrote:
But RTTI only contains published classes, does it not?
AFAIK there are some more
Op Sun, 23 Nov 2008, schreef JoshyFun:
Combined and uncombined strings are different things for different
tasks, the only common point is that both have the same visual
representation, but unicode function CharAt (or alike) over
uncombined string must never report the combined character as a
Op Fri, 21 Nov 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
Full Unicode support is for FPC 2.4. If you need it today, widestrings are
your best option.
Is it? Because that might mean yet another 2.2 fixes branch release to fix
up the delay that this
Op Fri, 21 Nov 2008, schreef Felipe Monteiro de Carvalho:
On Thu, Nov 20, 2008 at 9:05 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
There will be a real UTF8string, i.e. ansistring with UTF-8 encoding as part
of type information, this will help Lazarus users to get rid of the
utf8encode
Op Fri, 21 Nov 2008, schreef Michael Schnell:
If your point is that there is no way to allow for legacy code to be used
with a String type that holds UTF8 code and that it is not possible (or
desirable) to allow for code used in simple occasions that is understandable
to someone who does
Op Thu, 20 Nov 2008, schreef Graeme Geldenhuys:
All that crap just to load a simple text file that contains unicode
content!!! :-( And the other problem is that the hack above assumes
the files content is UTF-8 encoded. If the content is UTF-16 encoded,
you need yet another hack. :-(
As far
Op Thu, 20 Nov 2008, schreef Graeme Geldenhuys:
On Thu, Nov 20, 2008 at 11:12 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Ok, two questions for the example above:
- how do you maintain backward compatibility?
- how do you load a plain old ansi file?
If the file is UTF-8 or ANSI, the
Op Thu, 20 Nov 2008, schreef Graeme Geldenhuys:
On Thu, Nov 20, 2008 at 11:37 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
FPC supports Unicode, in 2.3.x is the UnicodeString type available being a
ref. counted utf-16 string on all platforms.
OK, I'll try to switch fpGUI's TfpgString
Op Thu, 20 Nov 2008, schreef Michael Schnell:
If you want to help, we need to implement the Delphi 2009 encoding aware
string type, both runtime support as well as the compiler support.
A previous discussion showed that this also breaks a lot of old code and is
not really nice.
As I
Op Thu, 20 Nov 2008, schreef Bernd Mueller:
Felipe Monteiro de Carvalho wrote:
I would like to hear of others actually have a better proposal for Lazarus.
sorry, I have no idea since I am doing primarily embedded stuff. Speed and
backward compatibility are the most important factors to
Op Thu, 20 Nov 2008, schreef Michael Schnell:
The file is assumed to be in system encoding (which can be UTF-8). Support
for reading of other encodings has not been decided on about yet and is not
part of the initial plan.
What is system encoding regarding different OS, locale, ... ?
Op Thu, 20 Nov 2008, schreef Felipe Monteiro de Carvalho:
So, what kind of support could be implemented in Free Pascal to
improve things for Lazarus and it´s users?
Maybe a real UTF8String?
There will be a real UTF8string, i.e. ansistring with UTF-8 encoding as
part of type information,
Op Thu, 20 Nov 2008, schreef Michael Schnell:
Isn't this the same??
I understand that D2009 uses dynamic code information, while my suggestion is
based on several different (static) types.
As I understand it is static.
type cp850string=ansistring(CP_850);
Op Thu, 20 Nov 2008, schreef Martin Friebe:
Daniël Mantione wrote:
Op Thu, 20 Nov 2008, schreef Felipe Monteiro de Carvalho:
So, what kind of support could be implemented in Free Pascal to
improve things for Lazarus and it´s users?
Maybe a real UTF8String?
There will be a real UTF8string
Op Wed, 12 Nov 2008, schreef Bernd Mueller:
Unicode support in FPC?
Sorry for jumping in. I am not so much interested in Unicode because I mostly
use shortstrings and ansistrings for performance reasons. But may be it is
worth to look how the gcc people have solved these issues.
They
Op Tue, 11 Nov 2008, schreef Michael Schnell:
There will have full compatibility with old code. It quite likely FPC will
have a Win32 platform where string=ansistring and a WinNT platform where
string=unicodestring. Other platforms will be decided on a case by case
basis, i.e. there is
Op Tue, 11 Nov 2008, schreef Michael Schnell:
IMO widestrings with precomposed characters, just like ansistrings, can
fullfill the needs of a newcomer. That there exists decomposed characters,
surrogates, and more, does not need to be explained in chapter 1 of a
programming for
Op Tue, 11 Nov 2008, schreef Michael Schnell:
Remember that an individual code point does not nessacerally represent what
a user would consider a character. ...
Again, there is no compatible handling of this with good old ANSIStrings,
anyway, so there is not friendly old school way that a
Op Tue, 11 Nov 2008, schreef Michael Schnell:
Surely this is allowed and works correctly under D2009, otherwise I
really misunderstood Unicode support in D2009.
In D2009, String is WideString, and the VCL API is done with this
(Wide)String. So this of course works. With Lazarus things are
Op Tue, 11 Nov 2008, schreef Luiz Americo Pereira Camara:
Jonas Maebe escreveu:
If people want to rely on what they are used to in non-unicode
environments, then they cannot directly use unicode strings. They'll first
have to assign it or typecast it to a non-unicode string and then operate
Op Sat, 8 Nov 2008, schreef ABorka:
Hi,
I'm converting a Delphi program to FPC/lazarus and I did hit a snag with an
asm code part (win32, latest fpc and lazarus svn trunk is used).
I know it is probably simple to fix, but I cannot seem to be able to figure
it out:
function something(s
Op Thu, 6 Nov 2008, schreef Graeme Geldenhuys:
On Thu, Nov 6, 2008 at 11:57 AM, Henry Vermaak [EMAIL PROTECTED] wrote:
1) 'case' by string and type http://prismwiki.codegear.com/en/Case_(keyword)
Did you not know that this is supported in FPC (for some time now).
;-) And it's not just
Op Tue, 4 Nov 2008, schreef Michael Schnell:
Are there other than historical reasons that FPC is this self-contained ?
(I suppose compiling speed is an issue here, so a GCC compatible parser
might only be an additional tool provided by the FPC team, but I'd really
love to use this for my
Op Tue, 4 Nov 2008, schreef Michael Schnell:
If you want to have _really_ good optimization, have to solve a a really
complex or non-standard problem, you of course are lost with OpenMP and need
to use more appropriate methods. Supposedly will not use FPC here but a more
low-level
Op Tue, 4 Nov 2008, schreef Michael Schnell:
The point is those compilers cannot provide it because of (a) technical
limitations,
I don't think this is true. GCC can compile Java which I think is an object
language in a similar extend as Object pascal is. And it seems to be
similarly
Op Mon, 3 Nov 2008, schreef Florian Klaempfl:
Michael Schnell schrieb:
IMHO any technology that enables FPC to compile a loop like (using
Oxygen syntax):
for parallel i := 0 to 10 do begin
a[i] := a[i] + b[i];
end;
in a way that it on a multicore processor runs as fast as the
appropriate
Op Mon, 3 Nov 2008, schreef Florian Klaempfl:
Well, those tests even don't take care of thread starting time :)
Threads are started at application startup, in fact my command lines were:
[EMAIL PROTECTED] ~]$ OMP_NUM_THREADS=1 ./stream_omp
[EMAIL PROTECTED] ~]$ OMP_NUM_THREADS=8
Op Mon, 3 Nov 2008, schreef Daniël Mantione:
[EMAIL PROTECTED] stream]$ OMP_NUM_THREADS=2 numactl --physcpubind=0,4
./stream_omp
[EMAIL PROTECTED] stream]$ OMP_NUM_THREADS=2 numactl --physcpubind=0,4
./stream_omp
Copy/paste error. Correct command lines are:
[EMAIL PROTECTED] stream
Op Mon, 3 Nov 2008, schreef Peter Popov:
Unfortunately, the utility of multicore systems has been largely exagerated
by their manufacturers. The main problem is that multiple cores share the
same memory bandwith. As a result it is highly unlikely that one can have
COMPLEX programs running
Op Tue, 28 Oct 2008, schreef Thaddy:
Or maybe a new switch: COMPUTATIONALLYWRONG_MATHEMATICALLYCORRECT ON/OFF?
Although an assumed standard, lot´s of modern calculations depend on a mod
being able to assume a negative value.
There is no need for such a switch. No programs needs it, because
Op Thu, 23 Oct 2008, schreef Michael Schnell:
The compiler definitively eats no ucs-2 encoded sources.
I did check several times: My source file looks like this when I open it with
Ultra-Edit and tell to show it in Hex:
FF FE 75 00 6E 0069 00 74 00 20 00 55 00 6E 00 ..u.n.i.t. .U.n.
Op Thu, 23 Oct 2008, schreef JoshyFun:
Hello Michael,
Thursday, October 23, 2008, 1:46:48 PM, you wrote:
More importantly, most of such routines will be implicitely tied to a
certain language or language group already.
MS Which kind of UCS2 based function do you think are tied to a
MS
Op Thu, 23 Oct 2008, schreef JoshyFun:
Hello Daniël,
Thursday, October 23, 2008, 5:34:59 PM, you wrote:
DM Don't overexagerate, this is true with plain ASCII as well. Non-English
DM software exists already for over 5 decades and nothing has stopped us to
DM write code that performs the
Op Fri, 3 Oct 2008, schreef Graeme Geldenhuys:
On Fri, Oct 3, 2008 at 2:31 AM, Joao Morais [EMAIL PROTECTED] wrote:
Because a Pascal compiler parses the interface section of an unit only once,
That would make sense. And probably the reason why FPC and Delphi are
such fast compilers
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Who says that? UTF-16 is simply chosen because it has features (supporting
all characters basically) ANSI doesn't?
Sorry, my message was unclear and I got somewhat
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Fri, Sep 26, 2008 at 9:12 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
For me the speed of input/output is less relevant, this is limited by disk
speed anyway. It's the speed of processing that should be decisive.
That's highly dependant
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
On Fri, Sep 26, 2008 at 10:43 AM, Michael Schnell [EMAIL PROTECTED] wrote:
It's no different then UTF-16 if you want to do it properly. In both you
have to look out for surrogates.
Is UTF-16 Widestring in FPC (and Delphi 200x ? ) not done
Op Fri, 26 Sep 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
That's highly dependant on what you application does! If your
application primarily parses text files, it's relevant. :-)
Shortstrings ansistrings won't go away. You'll still be able to code
Op Fri, 26 Sep 2008, schreef Marco van de Voort:
In our previous episode, Dani?l Mantione said:
as I know D2009 (I think) handles this correctly, but I have no idea
how.
Let me put it like this: Someone writing a Russian/Arabic/Japanese spell
checker does not have to handle surrogates with
Op Fri, 26 Sep 2008, schreef Graeme Geldenhuys:
Taking a step back from Free Pascal and Tiburon How do other
frameworks handle string encodings etc... Frameworks like Java, Qt
etc... Can't we learn something from them as well? Both Java and Qt
run on multiple platforms, read/write to
Op Thu, 18 Sep 2008, schreef Graeme Geldenhuys:
Hi,
How far will Unicode support go in FPC when it is one day implemented?
type
TMyåClaß = class(TObject)
public
property Nãàm: unicodestring read ;
end;
Never say never, but the compiler uses
Op Sun, 14 Sep 2008, schreef Jonas Maebe:
On 14 Sep 2008, at 14:49, Markus Beth wrote:
this patch rewrites code of ArrayRTTI and fpc_Copy to allow the compiler to
generate faster code (at least on i386).
The change in ArrayRTTI yields a performance gain of ~4% for our real world
Op Fri, 12 Sep 2008, schreef listmember:
This search needs to be NOT case-sensitive.
How can you do this?
Is it doable if TCharacter (or wahtever you call it) has no 'langauge'
attribite?
'I am on FoolStrasse' versus 'I am on FoolStraße' is not a upper/lower
case issue. Strasse and
Op Tue, 26 Aug 2008, schreef Graeme Geldenhuys:
On Tue, Aug 26, 2008 at 12:15 AM, JoshyFun [EMAIL PROTECTED] wrote:
returns exactly the same string (WinXP FPC 2.2.2), as this functions
seens to not be implemented right now I started to work in some
functions for this job at least for the
Op Tue, 26 Aug 2008, schreef Graeme Geldenhuys:
On Tue, Aug 26, 2008 at 9:19 AM, Graeme Geldenhuys
[EMAIL PROTECTED] wrote:
project. Maybe we could use something there - it's written in Object
Pascal as well? The LPTK project used a BSD license.
I had a quick look at the LPTK project
Op Tue, 26 Aug 2008, schreef Graeme Geldenhuys:
On 8/26/08, Daniël Mantione [EMAIL PROTECTED] wrote:
defined as a word (2 bytes), so that means it's only UCS2 compliant
and not full Unicode UTF-16 (which is what we want).
For uppercasing/lowercasing it is correct to define a Unicode char
Op Tue, 26 Aug 2008, schreef ik:
Also many languages such as Hebrew Arabic and more does not have
upper/lower case thingy (Arabic have for most but not all chars 3
types of appearing one at the beginning of the word/next to a non
combined char), one in the middle of the chars (combined on
Op Tue, 26 Aug 2008, schreef Felipe Monteiro de Carvalho:
Hello,
I read the code for UTF8Encode and UTF8Decode routines and they seam
to suppose that the widestring encoding is UCS-2! Instead of UTF-16
Is this the expected behavior or is it only partially implemented?
It is a broken
Op Wed, 13 Aug 2008, schreef Vincent Snijders:
It easier to change the message parser if you change it, than to design a
protocol for more computer friendly messages.
It's not about what is less work. It's about what has the
best compatibility, the best maintainability, the best
Op Sun, 10 Aug 2008, schreef Michael Van Canneyt:
After I get the hrtimer header converted if you want it I can send it to you
for review and inclusion in the libc *.inc files.
Feel free to do so; Like I said, we accept patches.
Note that libc use is limited to i386-linux.
This is not
Op Sun, 10 Aug 2008, schreef Boian Mitov:
Hi Daniel,
Thank you!
As I mentioned I am very new, and still don't know the exact rules of the
purpose of specific units. I am not sure if the timers are available on other
systems than Linux yet. I am sure there is some form of equivalent. I
Op Thu, 31 Jul 2008, schreef Michael Schnell:
The reason is that the cache coherency algorithms don't scale.
This again is a software problem.
Cache coherency algorithms are implemented in hardware.
If the task to do allows it the software needs to be written in a way that
the cache
Op Thu, 31 Jul 2008, schreef Boian Mitov:
Stupid me, to 20 years ago when I studied Fortran 77, I thought it was
obsolete :-)
I hope they at least have loops now, and who knows, it may even support
Hmm Hmm... recursion :-D .
No, Fortran is still in big use, and yes it is obsolete.
Op Thu, 31 Jul 2008, schreef Vinzent Höfler:
Op Thu, 31 Jul 2008, schreef Boian Mitov:
Stupid me, to 20 years ago when I studied Fortran 77, I thought it was
obsolete :-)
I hope they at least have loops now, and who knows, it may even support
Hmm Hmm... recursion :-D .
No, Fortran is
Op Wed, 30 Jul 2008, schreef Graeme Geldenhuys:
Does FPC have any any functions that work correctly with surrogate
pair used by UTF-16?
Likely, because I doubt FPC has routines, other than UTF-8 - UTF-16
conversion, that need to bother with surrogate pairs. I.e. the following
code is
Op Wed, 30 Jul 2008, schreef Boian Mitov:
Hi Joost,
Actually the trend started probably ~10-15 years ago with the DSP processors.
Then along came Transmeta, and the Itanium, then there ware the GPUs
including from NVidia, and there is PlayStation 3. They all use this type of
approach.
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
Hi,
A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
UTF-8 as the internal string encoding. He noticed that the File Dialog
which displays the file sizes with thousand separators were totally
blank. On further
Op Tue, 29 Jul 2008, schreef Micha Nelissen:
Daniël Mantione wrote:
is no proper solution, MBCS requires it to be a string rather than a char,
but compatibility requires it to be a char. Which means you are
Isn't a string backward compatible with a Char?
No. A char can be automatically
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
As a workaround, it can be converted into a normal breaking space. There is
no proper solution, MBCS requires it to be a string rather than a char, but
compatibility
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort [EMAIL PROTECTED] wrote:
This is what the Russian user had to revert to, using a normal $20
(space) character. But seeing that Delphi is now going to be fully
Unicode compliant, surely we
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort [EMAIL PROTECTED] wrote:
same boat. I don't see any point in waiting for Delphi, after all, we
may NOT look at their implementation anyway!
No, but we can try to keep compability.
Is
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:45 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
The developers haven't talked about it yet, but I can imagine we will have
some target platforms where sizeof(char)=1, which would provide for 100%
compatibility
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
Good. MSEIDE is quiet a bit ahead because it made the switch to
widechar/strings from the start.
Pity FPC could do such a bold move. ;-) Imagine how much less work
Martin would have had to do.
True. Because of the influence of Lazarus, the
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
So back to my original question :)
Due to ThousandSeparator being a Char type, is using a normal space
($20) the only available option for Russian users, using the current
RTL implementation? Though this might cause issues in text
Op Tue, 29 Jul 2008, schreef Bee:
So FPC plans to always be worse off than Delphi. :-( I really think
playing 'catchup' with somebody like Delphi is not a good thing. They
have different goals as far as I can see, plus their future doesn't
look bright (for a very long time now). Delphi
Op Tue, 29 Jul 2008, schreef Bee:
Could you show me the advantage of having an incompatible string
implementation in FPC 2.4, which will be out after highlander?
Boost the usage of Unicode in FPC that would boost the usage of FPC itself.
Unicode is one of the most demanded features (beside
Op Fri, 18 Jul 2008, schreef Craig Peterson:
??? wrote:
1. Why not use dummy class like class tmyenum(tobject) e: myenumtype;
end;?
(extra typing is something like (objects[i] as tmyenum).e instead of
typecasting, but you can [have to] Free it: it's normal object)
Why would
Op Thu, 17 Jul 2008, schreef Micha Nelissen:
Graeme Geldenhuys wrote:
Simple one liners like the following:
inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots,
itm.CountSlots);
or
FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots +=
itm.CountSlots;
now has to
Op Thu, 17 Jul 2008, schreef Graeme Geldenhuys:
On Thu, Jul 17, 2008 at 9:09 AM, Jonas Maebe [EMAIL PROTECTED] wrote:
Or
with FDayList[itm.WeekDayNum].Rows[itm.Timeslot] do
AvailableSlots:= AvailableSlots+itm.CountSlots;
No that's one language construct I wish Object Pascal could do
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
It compiles without issues under FPC 2.2.3 and prior. What is wrong
with using Include() to add to a set? I do it all the time, plus
WindowAttribute is a read/write property, unlike the compiler error in
2.0.4 where you could use Include()
Op Wed, 16 Jul 2008, schreef Daniël Mantione:
2.3 prevents you form taking the address of a property, because that way you
can read/write its value directly, circumventing the getter/setter. So you
cannot use the @ operator, but neither can you pass properties to var
parameters. Include
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation detail
should be hidden and this can/should be allowed
Op Wed, 16 Jul 2008, schreef Ales Katona:
I think this is also same in Delphi, but I agree that passing pure properties
(without getter/setter) to var should possibly be reduced to warning or even
hint.
This was discussed before and rejected.
The reason is that a change in implementation
Op Mon, 2 Jun 2008, schreef Florian Klaempfl:
all, if you use Random(), you want something random, yet many
developers make the common mistakes of not calling Randomize() or
calling it to often. If FPC handled that for us, nobody would every
make those mistakes again!
People might want to
Op Mon, 2 Jun 2008, schreef Michael Van Canneyt:
People might want to start with a defined randseed to reproduce behaviour.
This implies createguid should not call randomize automatically either, it
prevents you having deterministic behaviour, especially in a program where
guids and normal
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Friday 29 February 2008 10.07:29 Daniël Mantione wrote:
Ideally from my point of view would be if the resourcestrings are stored
in utf-8 if the unit is compiled with -Fcutf8 and decoded by utf8decode
for widestring assignment on runtime
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Sunday 02 March 2008 10.22:32 Daniël Mantione wrote:
Regarding code generation, there is a difference between ansistrings and
resourcestrings, since with a resourcestring load, the compiler must look
into the resourcestring tables to find
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Sunday 02 March 2008 14.09:47 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Sunday 02 March 2008 10.22:32 Daniël Mantione wrote:
Regarding code generation, there is a difference between ansistrings
Op Sun, 2 Mar 2008, schreef Florian Klaempfl:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences _only_ the interpretation of string constants when converting
them to unicode.
Right. Try to compile the (utf-8 encoded) file without specifying a
Op Sun, 2 Mar 2008, schreef Martin Schreiber:
On Sunday 02 March 2008 18.48:01 Daniël Mantione wrote:
Op Sun, 2 Mar 2008, schreef Florian Klaempfl:
What did I wrong?
I'am not sure how this could be made working just a remark: -Fcutf8
influences _only_ the interpretation of string
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current FPC to have unicode or wide resourcestrings?
Thanks,
Resourcestrings are ansistrings, so the answer
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.25:18 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
On Friday 29 February 2008 09.02:02 Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Martin Schreiber:
Hi,
Is there a way in current
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Memory access. What happens is that the non-packed version causes more
cache misses. A cache miss costs many cycles on a modern cpu, a misaligned
read just costs an extra memory access (which is fast if cached) on x86,
and extra load
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead unaligned will simulate an unaligned load with two loads and some
rotation etc. On the ARM, where every mnemonic can rotate operands, this is
isn't that bad of a penalty.
Therefore, I wouldn't be surprised that even on ARM, arrays
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Daniël Mantione wrote:
Op Fri, 29 Feb 2008, schreef Christian Iversen:
Instead unaligned will simulate an unaligned load with two loads and
some rotation etc. On the ARM, where every mnemonic can rotate operands,
this is isn't that bad
Op Tue, 26 Feb 2008, schreef Luiz Americo Pereira Camara:
Yury Sidorov wrote:
The patch removes packed record for some platforms.
IMO packed can be removed for all platforms. It will gain some speed.
I'd like to understand more this issue.
Why are non packed records faster?
Cache
Op Thu, 28 Feb 2008, schreef Micha Nelissen:
Daniël Mantione wrote:
To my knowledge there is no problem with the current implementation. Endian
conversion is already the reponsibility of the programmer. Therefore I
don't see a need for changes on the compiler side.
Jonas said the bits
Op Thu, 28 Feb 2008, schreef Jonas Maebe:
On 28 Feb 2008, at 08:19, Daniël Mantione wrote:
As long as the compiler is consistent between platforms, it is okay.
Differences between little/big endian are acceptable because this is the
only situation where we require the coder to manually
Op Thu, 28 Feb 2008, schreef Vinzent Hoefler:
On Thursday 28 February 2008 09:16, Daniël Mantione wrote:
Memory access. What happens is that the non-packed version causes
more cache misses.
Please elaborate. If the (unaligned) data is crossing a cache-line, thus
causing two full cache
Op Thu, 28 Feb 2008, schreef Yury Sidorov:
Yes, but if you have an array of them (as we have in this case),
considerably more of these records will fit in the cache. Therefore you
will have considerably less cache misses. This becomes even more serious
when the processor in question does not
101 - 200 of 556 matches
Mail list logo
