Jonas Maebe schrieb:
On 19 Jun 2008, at 13:53, Boian Mitov wrote:
This functionality works in all versions of Delphi 5-2007. We support
them all, and we have done so for years. We have no problems to
compile with such optimizations turned off.
One final time: please read the comments to
Boian Mitov schrieb:
Here is a code sniped that sows just one example of the problem:
This is a very simple example of how important the order really is:
Unfortunatly, I can quote only from the german delphi help: Wenn Sie
die Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als
Boian Mitov schrieb:
Hi Florian,
FLock is not interface. There is no error with the FLock.
To which instance is WriteLock an interface? FLock?
WriteLock is interface, and I have to destroy it before I destroy the
FLock. The order of destruction is obviously crucial.
The error is the
Boian Mitov schrieb:
Michael,
I never call Free() on interfaced object. I surely know that if I have
used interfaces for the last 10 years or so ;-) .
See my other mail. You do a WriteLock:=FLock.StopLock(); call. Every
interface is associated with a class instance. With which class
Boian Mitov schrieb:
Hi Marco,
You are wrong. They mean expression not block!
This path of the discussion is useless. As soon as you make WriteLock a
global/static var, delphi behaves the same as fpc: it creates a temp.
ref. which is only cleaned at procedure exit.
- Original Message - From: Florian Klaempfl
[EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, June 19, 2008 6:42 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
Boian Mitov schrieb:
Hi Marco,
You
Florian Klaempfl schrieb:
Jonas Maebe schrieb:
The behaviour you are counting on is a side effect of an optimisation,
not a behaviour by design.
Oh, btw: fpc 2.2.2rc1 behaves with -O2 like delphi :) Without -O2 like
2.2.0 :)
Add: I just realized that Peter implemented this some time ago
Boian Mitov schrieb:
Thank you! I will see to get the 2.2.2rc1 and compile with the switch
:-) . I will validate if it behaves the same way and will let you know
:-) . I am very excited that there could be a ready solution :-) .
I still recommend that you think about changing your design,
Sean McIlwain schrieb:
The following code fails to compile in Delphi mode but successfully
compiles in objfpc mode:
type
TEnum = (a, b, c);
var
AValue: TEnum;
AObject : TObject;
implementation
initialization
AObject := TObject(AValue);
Could this be supported in the Delphi mode as
Marco van de Voort schrieb:
Now this topic came back to my attention. So before we will start
our work I want to ask some questions.
Did in the meantime perhaps somebody already started to add QNX as a
target?
Afaik 1.0.x had qnx support so this would be a good start. I'll see if I
find
Marco van de Voort schrieb:
You can peek at it for structures and types. But even then, since they are 5
year old, you need to check them against current versions in the headers.
IMHO it shouldn't have been added to SVN, no file from that dir is reusable
as it is.
It's still easier to check
The
next operation will have to delete all files again, and commit real ones.
... which is no problem.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Marco van de Voort schrieb:
Read this and the reactions, and weep:
http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a
I don't agree on the point that good mt support is a matter of
Mehmet Erol Sanliturk schrieb:
For that reason , I consider such a problem is in the domain of
operating systems .
FPC is able to generate such programs . Therefore in my opinion
it is not a vital problem to solve this problem WITHIN the FPC.
This is
Marco van de Voort schrieb:
Eg only allow the parallel or async keyword (I personally do not care
which) on an otherwise normal procedure and then another
procedure/keyword isfinished(x)? which checks whether the 'parallel'
procedure x has finished. With minimum (ie no) checking for whether the
Vinzent Höfler schrieb:
[...]
Because it's so simple we could then announce that we support
parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did
come along eg in Delphi or some other of the languages mentioned, we
could take a view as to whether we'd support it.
Sorry, but
Mattias Gaertner schrieb:
On Thu, 31 Jul 2008 11:02:28 +0200
Florian Klaempfl [EMAIL PROTECTED] wrote:
Before we discuss endless about useless stuff, I'll make a proposal
for a first addition: support of the synchronized keyword. It does no
more than protecting a procedure automatically
Michael Schnell schrieb:
Now you suggest that all procedures an instance of this kind of class
are protected and thus thread-safe by definition.
They aren't but it makes things easier. Just look at the linux kernel:
it's smp support started also with BKL: the Big Kernel Lock
Micha Nelissen schrieb:
Florian Klaempfl wrote:
Further, it allows an additional symbol to be given
procedure p;synchronized mycriticialsection;
Any suggestions about doing it better?
How to avoid deadlocks?
Indeed, I'am open to any suggestions :) Just an idea: maybe a global
call tree
Micha Nelissen schrieb:
Florian Klaempfl wrote:
Michael Schnell schrieb:
Now you suggest that all procedures an instance of this kind of class
are protected and thus thread-safe by definition.
They aren't but it makes things easier. Just look at the linux kernel:
it's smp support started
Boian Mitov schrieb:
Jonas,
Thank you!
I disagree with your definition of what is optimisation,
Well, and this is exactly the point were you are wrong (as proved by
several code samples you ignored) and that's why Jonas reacted the way
he did.
Mehmet Erol Sanliturk schrieb:
Dear Sirs ,
(1)
I searched in http://wiki.freepascal.org/;
the phrase internal errors to find information
about Free Pascal generated internal
error messages . There did NOT exist
any information about this subject .
The user should not hit any internal
Mehmet Erol Sanliturk schrieb:
Dear Sirs ,
I am sorry that in my message with subject
Free Pascal Internal Error ( 200 212 283 )
I forgot to say that I modified error handling
step of Free Pascal ( FPC ) to allow it to continue
up to a specified number of errors significantly
greater than
Martin Schreiber schrieb:
There are no pseudo terminals on win32, I must use pipes. The current 2.0.3
RTL does not flush output on writeln if the filehandle is a pipe (2.0.2
does!). So the IDE target console window is unusable on win32 with FPC 2.0.3
RTL and works OK with FPC 2.0.2 RTL.
;-)
JoshyFun schrieb:
Hello fpc-devel,
A few days ago I had posted here and in the bugtracker a new
Utf8ToUnicode function http://bugs.freepascal.org/view.php?id=11791
This is just curiosity, it has not been committed to the wustrings.inc
due non interest, not important, bad format, it should pass
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
counted utf-16 string. On non-windows, widestring is mapped to this
JoshyFun schrieb:
Hello Florian,
Saturday, August 30, 2008, 1:37:42 PM, you wrote:
FK I've continued to work on support of an unicodestring type in fpc. It's
FK currently in an svn branch at:
FK http://svn.freepascal.org/svn/fpc/branches/unicodestring
FK and will be merged later to trunk. The
Graeme Geldenhuys schrieb:
On Sat, Aug 30, 2008 at 4:07 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
I don't know what is core, so would you mind forwarding the related
messages to this group?
Not really, we had enough useless and time wasting discussions about this.
Still doesn't answer my
Adriaan van Os schrieb:
Interface definitions
--
@@ -86,9 +92,10 @@
Level : 2
Class : (24) Nil
Procsym : (26) SymId 57
- File Pos : 1 (94,10)
+ File Pos : 1 (3411,10)
For the record, File Pos changes and is crc'ed.
Adriaan van Os schrieb:
Florian Klaempfl wrote:
Adriaan van Os schrieb:
Interface definitions
--
@@ -86,9 +92,10 @@
Level : 2
Class : (24) Nil
Procsym : (26) SymId 57
- File Pos : 1 (94,10)
+ File Pos : 1 (3411,10
Martin Schreiber schrieb:
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk
Martin Schreiber schrieb:
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
This should be fixed.
Thanks, FPC and MSEide compile now.
Attached an emergency patch that I could load the MSEgui forms, not finished
and not tested.
Thanks.
Is TTypekind = (... tkInterfaceRaw
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour of ansistring and widestring
was very useful, I'd like
Martin Schreiber schrieb:
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring
Ivo Steinmann schrieb:
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
Which ones? Really, I want to know :)
___
fpc-devel maillist -
peter green schrieb:
3: Use an automatic reference counting system either implemented in the
compiler (the delphi/fpc way) or implemented using a very powerfull
operator overloading system (the C++ way, last I checked freepascal did
not have sufficiant operator overloading capabilities to
Martin Schreiber schrieb:
On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote:
Trunk 11723 does not compile:
Trunk or unicodestring branch? Strange, because here it works?
Unicodestring branch, sorry, I should change the directory name of my switched
checkout. Does your
Jonas Maebe schrieb:
On 09 Sep 2008, at 21:37, Florian Klaempfl wrote:
Even C++'s is not good enough to do a ref. counted string in an
efficient way. Just consider the [...] operator which needs to
distinguish between reads and writes to avoid unncessary unique calls.
Can't you have
Marco van de Voort schrieb:
In our previous episode, Ivo Steinmann said:
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages. Of course I dont like this one:
S :=
Graeme Geldenhuys schrieb:
Remember, Unicode support is much more that simply storing and
displaying text. You have various encodings, RTL or LTR direction etc.
I can't see how a simple type can keep track of all such information
- but then, I don't know the internals of FPC either. ;-)
How
listmember schrieb:
compiler guys all the same} and ask, instead, to give us
reference-counted 4-byte (actually, preferably 6-bytes) per cell
arrays/strings.
What's wrong with an dyn. array of DWord?
Much like what's wrong with dynamic array of Word (as opposed to
Widestring) or with
Markus Beth schrieb:
Hi,
latest profiling of one of our FPC applications showed ReadInteger (in
rtl/objpas/sysutils/sysformt.inc) to be a performance bottleneck. Using
Pos(Fmt[chpos],'1234567890')0 to check if Fmt[chpos] is a digit is
somewhat time consuming. I replaced it with two char
Marco van de Voort schrieb:
In our previous episode, listmember said:
else
DrawCaption(0,0,AsUTF8(Caption), flags);
end;
In other words where is the benefit from OOP in this ?
IMO, both are deficient as they both assume that a string block (text)
is either RTL or LTR.
The
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk
Daniël Mantione schrieb:
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
Daniël Mantione schrieb:
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
Daniël Mantione schrieb:
Op Sun, 14 Sep 2008, schreef Florian Klaempfl:
Daniël Mantione schrieb:
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
Martin Schreiber schrieb:
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I have a crash in MSEide startup in a procedure finalization section:
[...]
I saw that you merged unicodestring
Martin Schreiber schrieb:
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote:
Martin Schreiber schrieb:
I tried with trunk, same result. The problem is probably that the second
constant string parameter has a wrong reference count. It is initially 0
instead of -1. The incref call
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical newsgroup.
They raised an issue about distinct types. I tried the following
example under FPC and unexpectedly, FPC doesn't raise any errors!
If you
Graeme Geldenhuys schrieb:
On Thu, Sep 18, 2008 at 10:11 AM, Michael Van Canneyt
[EMAIL PROTECTED] wrote:
And it is also very annoying because
Type
MyString = type string;
Const
AString = 'something';
Var
M : MyString;
begin
M:=AString;
end.
Will no longer compile if you are too
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical newsgroup.
They raised an issue about distinct types. I tried the following
example under
Graeme Geldenhuys schrieb:
eg: #2
type
MyType = type Double;
MyOtherType = type Double;
Otherwise, what's the different between a alias type (eg #1) and a
distinct type (eg #2)??
As I said: overloading. It means: compatible but not equal. If you want
distinct: use as said, classes,
Yury Sidorov schrieb:
Yes. But it works only partially. For example the following code is
not compilable:
Well, I wouldn't know either what you expect :)
I expect that compiler will choose DoTest with ansistring parameter in
that case.
What rule do you apply to say this?
//--
type
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types
Yury Sidorov schrieb:
Yes. But it works only partially
Graeme Geldenhuys schrieb:
On Thu, Sep 18, 2008 at 3:40 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
What rule do you apply to say this?
Compiler treats '1234' as ansistring constant. Therefore ansistring
overload must be choosen here.
No, '1234' is taken as generic string constant
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types
Yury Sidorov schrieb:
We discussed this once and concluded, that something like this hurts
more than it helps because an overloaded assignment operator allows
the compiler always to mess really around :)
Maybe.
But you stated that it is possible to create fully functional utf8string
type
Inoussa OUEDRAOGO schrieb:
Hi
This program prints tkUString. Is this by design or should it had
print tkWString ?
No, this is currently by design. In 2.3 widestring is a synonym for
unicodestring on non windows systems. Only on windows, widestring is a
special string being compatible with
Graeme Geldenhuys schrieb:
Hi,
Yes I know we have had lengthy discussions about this before.
Everybody (whoever they might be) keeps saying that UTF-16 was chosen
for Tiburon's UnicodeString because it makes significant speed gains
when calling the Windows API based on UTF-16 - compared to the
Graeme Geldenhuys schrieb:
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 mixed up between ANSI
Graeme Geldenhuys schrieb:
On Fri, Sep 26, 2008 at 9:04 AM, Graeme Geldenhuys
[EMAIL PROTECTED] wrote:
So has anybody actually done a timing comparision? Do you have your
test code available? Do you have your results published? I'm
interested to see the timing results using different
Graeme Geldenhuys schrieb:
On Fri, Sep 26, 2008 at 9:27 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Being honest, imo UTF-8 is only a hack to get unicode on platforms like
unix.
I don't know where you get that information,
Rather simple: initially in unicode 1.0 there was only a 16 bit
Mehmet Erol Sanliturk schrieb:
Dear Sirs ,
Please add such fixes to the bug tracker (http://bugs.freepascal.org/)
so it won't get lost.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Lukas Gradl schrieb:
Marco van de Voort schrieb:
In our previous episode, Lukas Gradl said:
At the moment, I'm developing on a i386 Linux machine. For some
servers I need x86_64 binaries, so I have a second machine with
x86_64 linux I use just for compiling.
It would be great to compile
Florian Klaempfl schrieb:
What I could not find was, how to create that ppcross386. I remember
it worked with a previous 2.2.0 install, but since I switched to 2.3.1
I couldn't get it to work.
I'am working on a patch to fix this. For now do
make all CPU_TARGET=i386 FPC=fpc
Should be fixed
Karl-Michael Schindler schrieb:
Hi
I have some suggestions regarding the use of viewvc for publishing the
svn repository to the web.
1) update to viewvc 1.06. CHANGELOG:
http://viewvc.tigris.org/source/browse/viewvc/trunk/CHANGES?rev=HEAD
Since ViewVC 1.0.6 is not yet in the ubuntu
Graeme Geldenhuys schrieb:
Hi,
Could anybody using 64bit FPC under Windows comment on this? I'm only
now able to setup 64bit FPC under Linux, but haven't had the
opportunity to run 64bit Windows and FPC for that matter. I thought
64bit support in FPC was done and dusted? [for Linux and
Daniël Mantione schrieb:
The issue might be the UCS-2 encoding of your source, perhaps try to
feed the compiler UTF-8, I didn't even know the compiler accepts UCS-2,
it may not work correctly.
The compiler definitively eats no ucs-2 encoded sources.
Michael Schnell schrieb:
A decent system should be able to do the necessary conversions
automatically:
This is a simplified view which ignores the resource wasting of this
apporoach not visible in the academical example below. The conversion
utf-8-utf-16 is a very expensive operation and the
Michael Schnell schrieb:
The conversion
utf-8-utf-16 is a very expensive operation and the compiler has to
insert it all over the place and people would cry about the performance
of their programs.
Of course I do agree.
If you want to care about performance you need to know what to do:
Michael Schnell schrieb:
More importantly, most of such routines will be implicitely tied to a
certain language or language group already.
Which kind of UCS2 based function do you think are tied to a
language(group) ?
Bidi stuff? You are aware of the fact that unicode strings can
Michael Schnell schrieb:
Bidi stuff? You are aware of the fact that unicode strings can contain
e.g. bidi markers?
Sorry, never heard of bidi :(
http://www.unicode.org/reports/tr9/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Dmitry Lizorkin schrieb:
Hello!
I was surprised to find out that the expression (-1 mod 3) yields -1 in
Free Pascal. On the other hand, Pascal ISO 7185:1990, section 6.7.2.2)
explicitly defines the `mod' operation such that 0 = i mod j j.
What do i miss here?
That FPC never claims to be
Dmitry Lizorkin schrieb:
That FPC never claims to be iso compliant. -1 mod 3 evalutes to -1 for
most modern programming languages.
Thank you for the clarification. A pity that FPC has no iso conformance
mode.
Well, it doesn't seem a big pity else somebody would have made one ;)
Michael Schnell schrieb:
Maybe it would be good to first start the OpenMP library part - a unit
providing some functions to easily use light weight threads.
I just read that as of v4.2, GNU C supports OpenMP by language
constructs (seemingly preprocessor directives). When looking at the
Michael Schnell schrieb:
I don't see how Mandelbrot requires OpenMP. One can easily launch n
threads depending on the number of the available cores.
(We are discussing this in the German Lazarus Forum right now...)
I feel that OpenMP is never _required_ to optimize a problem, but just
Daniël Mantione schrieb:
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
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 GNU C construct:
#pragma ocm_parallel
Michael Schnell schrieb:
For a big vector operation the number of used threads should be
adapted to the memory architecture,
With the C #pragma opm_ this can be done statically by the
programmer using the schedule keyword, defining chunks (there seem
to be more sophisticated ways
Peter Popov schrieb:
I hope this will helps the discussion.
Thanks for this well written explanation. If you've precise ideas how OP
could be extended to solve the mentioned problems, I'd to be happy to
know them and we can also discuss if it can be implemented.
Michael Schnell schrieb:
And writing parallel together with for is just adding a single
keyword. Providing easy support for common tasks (such as exploiting the
benefit of an SMP system) is exactly what everybody expects from a
decent programming language.
... and as said before, helps
Mattias Gaertner schrieb:
On Mon, 03 Nov 2008 16:29:01 +0100
Michael Schnell [EMAIL PROTECTED] wrote:
Great and you really believe this accelerates a program? Starting a
thread takes a lot of time and such loops are usually memory
throughput bound.
OK, I should not have used 10 as the
Michael Schnell schrieb:
If you want to have good multicore scaling you are lost with OpenMP.
As I said, that is my POV, too.
I did not start this discussion for preaching for OpenMP. In fact I know
close to nothing about it. My starting point were the rather poor
results for FPC in the
Michael Schnell schrieb:
You still didn't show any example which shows the real power of parallel
which cannot be solved by a T(Pooled)Thread.Create and
T(Pooled)Thread.WaitFor statements.
As I said several times, I don't suggest that any other implementation
(be it OpenMP or whatever)
Thaddy schrieb:
I consider parallel as syntactic sugar:
- the same effect can be achived by some thread classes
- it gives the compiler no opportunity to generate better code
- the use cases are limited, it is nothing being used hundred of times
in a typical program
- it solves none of the real
Felipe Monteiro de Carvalho schrieb:
On Tue, Nov 4, 2008 at 8:10 AM, Marco van de Voort [EMAIL PROTECTED] wrote:
Well, I gave up PIC24 since they don't contain motorcontrol,
I've always wanted to know what does a microcontroller with
motorcontrol is supposed to do different from a normal
Michael Schnell schrieb:
Moving things in the language without a notable advantage which can be
solved by a library is not a good thing.
Don't you think ease of use _is_ a notable advantage of a programming
language ?
It is. But as pointed out, parallel does not solve any of the
Dmitry Lizorkin schrieb:
I agree, no real life need.
Except probably for my 150 students to whom i can no longer recommend
FPC as a reference implementation.
Hopefully they won't be schocked when being hit by another real world
programming language implementing mod like it is implemented in
Sergei Gorelkin schrieb:
Hello,
The attached patch fixes two opcodes generated by i386 internal assembler.
The first one fixes the mov ax, word ptr [somevar] command which was
generated without $66 prefix (reported by freepascal.ru forum user,
don't know if it is in bugtracker).
The second
Michael Schnell schrieb:
I set no special options in FPC
Lazarus does.
and I don't use WideString at all.
UTF-8 fits perfectly in the standard String type.
Some conversions are correct or seem to be correct in that case.
It has been already pointed out several times that lazarus
Graeme Geldenhuys schrieb:
On Tue, Nov 11, 2008 at 6:21 PM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
Some conversions are correct or seem to be correct in that case.
It has been already pointed out several times that lazarus abuses the
anstring type to store utf-8 and this breaks several
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that does
not make difference using constant parameters or not for double types.
So is
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
While discussing if is worth using const parameters for string and
double types in a Lazarus bug report (
http://bugs.freepascal.org/view.php?id=12642 ), it was noticed that
does not make
Luiz Americo Pereira Camara schrieb:
Jonas Maebe escreveu:
On 16 Nov 2008, at 14:52, Florian Klaempfl wrote:
Luiz Americo Pereira Camara schrieb:
Maybe the documentation
(http://www.freepascal.org/docs-html/ref/refsu50.html#x126-13300011.4.4)
can be modified to clarify this since
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size is 4.
Don't forget that this makes an extra memory access.
I
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization opportunity:
pass by reference a 8 bytes parameter when the pointer size
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
Florian Klaempfl escreveu:
Luiz Americo Pereira Camara schrieb:
My point was that this could be a missing optimization
Alexander Klenin schrieb:
On Mon, Nov 17, 2008 at 05:39, Florian Klaempfl [EMAIL PROTECTED] wrote:
No, just look at the actual assignment:
i:=v;
By const/reference it generates 5 instructions, by value only 4. The rest is
entry code. If you've only one access, passing by reference might have
Graeme Geldenhuys schrieb:
Hello again,
We are seeing more and more hacks being applied to projects trying
to scramble around the missing FPC feature - no built-in Unicode
supporting.
A simple example in Lazarus Loading a UTF-8 encoded file into a TMemo.
Normally you would write code as
501 - 600 of 1078 matches
Mail list logo
