IT appears that during compilation (not the whole time, but some brief
moment) FPC locks the fpc.cfg.
So far that is expected. while fpc reads it, it must not change.
But it seems the lock also prevents others from reading.
On w32 Vista / fpc 2.6.2
I started 2 compilations (almost at the same
It is probably my fault somewhere, since I do not know the exact
procedure to be followed.
BUT:
In a checkout of
http://svn.freepascal.org/svn/fpcbuild/trunk in C:/FPC/SVN/build_trunk/
PATH=C:/FPC/SVN/build_trunk/install\binw32
cd C:/FPC/SVN/build_trunk/fpsrc
// a starting native 2.6.2
...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It is probably my fault somewhere, since I do not know the exact
procedure to be followed.
BUT:
In a checkout of
http://svn.freepascal.org/svn/fpcbuild/trunk in C:/FPC/SVN/build_trunk/
PATH=C:/FPC/SVN/build_trunk/install\binw32
cd C:/FPC/SVN/build_trunk/fpsrc
// a starting native 2.6.2
I suspect this to be an issue with the new 2.7.1 encoding. If someone
could please review...
Some background fist.
I was looking into a report of a user, where the IDE (Lazarus) would not
show the debug-line-info (blue dots in gutter), for some files (but work
for others)
fpc svn 25364
On 25/08/2013 14:11, Paul Ishenin wrote:
25.08.13, 20:44, Martin пишет:
To find some info I added debugln as follows.
Note the part
PInteger(ASource)[0], // just some part of the string, for verification
PInteger(ASource)[1], // on 2.7.1 Encoding ? // on 2.6.2 length
argh 1 ... a mistake
On Monday 19 August 2013 11:28:25 Michael Van Canneyt wrote:
It should not take more than an hour to implement.
Maybe some additional minutes for the implementation of an efficient and
precise timer queue. ;-)
Martin
___
fpc-devel maillist - fpc
On Monday 19 August 2013 11:55:37 Michael Schnell wrote:
On 08/19/2013 11:51 AM, Martin Schreiber wrote:
Maybe some additional minutes for the implementation of an efficient
and precise timer queue. ;-)
_MANY_ thanks for the support, making me feel that I am not completely
insane.
BTW
In ParseCompilationUnit line 579 / trunk (form within last 7 days)
extended_opcode_length := ReadULEB128();
for i := 0 to extended_opcode_length-2 do
ReadNext();
I have a case where that goes wrong. the length is well over 1 million
(obviously wrong)
In
fpc revision 25146 (windows 32 bit internal linker or -XE)
It seems that fpc does for some variable produce a DW_AT_location that
no GDB (tested various from 6.3 to 7.5 on 32 bit win) understands. I do
of course not know, if gdb is wrong, or fpc.
In Lazarus is a small app
On 22/07/2013 20:41, Jonas Maebe wrote:
On 22 Jul 2013, at 21:02, Martin laza...@mfriebe.de wrote:
fpc revision 25146 (windows 32 bit internal linker or -XE)
[dwarf errors]
May be related to the same change that caused
http://bugs.freepascal.org/view.php?id=24722
I've seem a couple
anyone knows *all* the different ways that function names may be mangled
(for the linker)?
I asked because this is sometime the only info returned by gdb (if there
is no debug info). And it could be useful to parse it.
It used to be Unit_class_$__function$...
On 24/06/13 14:25, Jonas Maebe wrote:
You should not try to parse the mangled name, because FPC's name
mangling is a one-way process at this time (and always has been until
now). If the mangled name's length gets close to 250 characters, the
end will be replaced by a CRC of the name
) with the Segger
J-Link debugger which is built-in in the inexpensive demo board.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Thursday 23 May 2013 11:06:52 Michael Schnell wrote:
On 05/23/2013 10:50 AM, Martin Schreiber wrote:
Or the gdbserver runs on the PC and communicates with a debug interface
hardware. MSEide uses this approach to debug AVR32 code with the AVR
ONE! debugger and ARM chips (for example
On 16/05/2013 17:24, Jonas Maebe wrote:
On 16 May 2013, at 17:43, Martin wrote:
using rev 24475 the below fails. It works using 2.6.0
Afaik it should work? dynamic types (such as TDynIntArray ) should be
initialized?
Yes. The RTTI for that type seems to be completely messed up in current
I have 2 matching reports (but so far unable to reproduce myself)
- both are 64 bit
- at least one is linux and uses gdb 7.5.1
I believe the other is linux too, not sure what gdb, (and he tested
on win (not sure 64 or 32bit) where it did not happen)
[ this may point to a linker issue
On 14/05/2013 11:03, Martin wrote:
possible: http://bugs.freepascal.org/view.php?id=14399
I am a bit lost:
The bug says GDB always steps *into* the interface (depite it should
step over)
But at:
http://sourceware.org/ml/gdb/2009-04/msg8.html
When encountering such a stub, gdb
On 13/05/2013 07:47, Michael Van Canneyt wrote:
On Sun, 12 May 2013, Martin wrote:
I have not tested it at runtime I assume it depend on a being
initialized with an instance.
Question, is that allowed by intention? That is can I trust that it
will be supported by future fpc versions
I know a property read/write to a member of a record, if that record is
a field of the class.
I tested the following code, it seems fpc also allows that for classes.
type
TFoo = class
protected
cn: Integer;
end;
TForm1 = class(TForm)
private
a:TFoo;
public
property b:
On Sunday 17 March 2013 21:44:02 Florian Klaempfl wrote:
Am 06.03.2013 14:16, schrieb Martin Schreiber:
On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote:
On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On
Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix
It seems that in FPC 2.6.2 the dwarf reading code in LnfoDwrf is broken.
It always gives a run-error 131
compiled below example with
-MObjFPC -Scghi -O1 -gw2 -gl -gh -vewnhi
and boom
program Project1;
{$mode objfpc}{$H+}
begin
TObject.Create;
end.
it prints
Heap dump by heaptrc unit
1
On 16/03/2013 09:55, Jonas Maebe wrote:
On 16 Mar 2013, at 02:35, Paul Ishenin wrote:
16.03.13, 1:54, Martin wrote:
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT=-gl
-O2
No, it does not work.
It definitely should work
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT=-gl
-O2
Fatal: Compilation aborted
An unhandled exception occurred at $004A7A0E:
ERangeError: Range check error
$004A7A0E line 2638 of scanner.pas
$004AA76D line 3944 of
On 16/03/2013 01:35, Paul Ishenin wrote:
16.03.13, 1:54, Martin wrote:
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT=-gl
-O2
No, it does not work. Testsuite has many failures too when the
compiler is built with -Cr.
Why
On 16/03/2013 02:13, Martin wrote:
On 16/03/2013 01:35, Paul Ishenin wrote:
No, it does not work. Testsuite has many failures too when the
compiler is built with -Cr.
Why this is a problem for you?
It is not a problem.
But it did work (or at least compile itself) for a long time now
The below make may not be exactly the documented way.
And also my starting compiler was 2.6.0 (and should be 2.6.2).
So failure is on my side. But I expect that if it failed, it still
should not crash.
I am not sure in which step it was, when it crashed.
trunk_build is the build binaries from
On Monday 04 March 2013 09:26:53 Vittorio Giovara wrote:
Martin made a point that delphi7 is faster better and whatever than fpc...
so what?
Don't use fpc if you don't like it, or send patches to improve it ;)
You probably might know, I am the author of MSEide+MSEgui:
http://sourceforge.net
On 04/03/2013 04:54, Boian Mitov wrote:
Here is example:
Parallel execution with selection of executor:
for i := 0 to AMaxScaleIndex - 1 do
begin
APerIterationLocations.Add( TRTDynamicListTVLImageRect.Create() );
AExecutionTask.Add( AExecutor.Execute(
procedure()
begin
On 04/03/2013 05:00, Boian Mitov wrote:
One thing for sure, I probably will very much never need to declare
TThread inherited classes. I can use a single anonymous method for
that, thanks to the ability of the anonymous method to capture local
and member variables.
This is something not doable
On 04/03/2013 05:57, Alexander Klenin wrote:
On Mon, Mar 4, 2013 at 2:38 PM, Martin laza...@mfriebe.de wrote:
Closures, do not need to be written/declared in the middle of other code
(in-line)
Strictly speaking, they do not. However, if the closures are required
to be named,
their expressive
On 04/03/2013 06:06, Boian Mitov wrote:
It may be a good idea to analyze the current Delphi implementation.
In essence the anonymous method expands to a class and interface.
The interface Execute method has the parameters of the anonymous
function. and the corresponding interface has the
to stop adding features
soon because 1.1^50 = 117.4. ;-)
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 04/03/2013 12:51, Sven Barth wrote:
If you guys would read what I wrote in one of my first answers to
Vasiliy in this thread than you would know that I want him to
implement this possiblity as well... but after all, who reads the
mails of some strange computer science student who just
On Monday 04 March 2013 07:08:25 Martin Schreiber wrote:
Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC
counterpart which is especially surprising for Delphi because Delphi
widestrings are not reference counted.
Some more tests, starting MSEide, loading
On 04/03/2013 14:09, Alexander Klenin wrote:
On Mon, Mar 4, 2013 at 10:34 PM, Martin laza...@mfriebe.de wrote:
Nevertheless, I agree what the implementation plan can be detailed even
further:
1) Anonymous procedures *without* closures -- basically, just another
syntax for nested procedures
On 04/03/2013 14:49, Sven Barth wrote:
Am 04.03.2013 15:42, schrieb Martin:
but (4) is powerful enough to really make functional-style programming
practically
I can live with that. I find it odd so that as is used in the
reverse order compared to current use.
The use of as is based
On 04/03/2013 16:05, Alexander Klenin wrote:
Anonymous functions (with good syntax, of course) fall in this category.
The world recognized that fact -- rather slowly, to be sure, but
remember that whiles and fors
also took decades to be accepted as standard constructs.
I am not going to ask for
in background if main event loop is idle.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 04/03/2013 16:05, Alexander Klenin wrote:
Both lambda and as keywords are quite debatable, of course.
IMHO the existing procedure/function keywords should be kept. But with
the requirement of using a defined type
Foo( function as TVisitor; Result := x+5 end; );
or
Foo( function as
and does the highlighting in background if main event loop
is idle.
And how much time is spent on the highlighting on Linux
and Windows?
About 2/3 on booth. I need to instrument the code in order to get more precise
numbers.
Martin
___
fpc-devel maillist
On Monday 04 March 2013 14:54:01 Mattias Gaertner wrote:
On Mon, 4 Mar 2013 14:50:17 +0100
Martin Schreiber mse00...@gmail.com wrote:
On Monday 04 March 2013 07:08:25 Martin Schreiber wrote:
Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their
FPC counterpart which
On 04/03/2013 19:16, Alexander Klenin wrote:
function NAME(PARAMS): RETURNTYPE as EXPRESSION
IMHO that is not a good idea. It adds an additional construct, that every
reader must know how to read. It does not add/save enough to be needed.
I agree, it is borderline, and needs to be
On 04/03/2013 19:16, Alexander Klenin wrote:
See above. The omission of Result := is IMHO not desirable.
Are you sure? Note that *any* useful single-statement function will
start exactly like this
If a = x then Result := 4 else Result := 5;
Single statement, but starts different. And is
On 04/03/2013 22:16, Sven Barth wrote:
The above is NOT an anonymous function. It is a reference to a term.
I am not voting for it, but IF it was done, then it should have its
own keyword.
It would not allow for var, type or anything (and it will only work
for functions, not procedures.)
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote:
Op Sun, 3 Mar 2013, schreef Martin Schreiber:
BTW, a significant percentage of the time is waiting for FPC compiling
because FPC normally crashes without -B.
I think you should focus your efforts on getting those bugs fixed
and can
fix it once and for all :)
No, I mean MSEide. MSEide is a more complex application than the compiler it
seems. :-)
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
http://gitorious.org/mseide-msegui
Command line Kylix 3:
dcc -D+ -Aclasses=Classes -Adateutils
Am 02.03.2013 11:11, schrieb Martin Schreiber:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come as a surprise.
On Windows FPC linking time of MSEide
On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote:
On Sun, 3 Mar 2013, Martin Schreiber wrote:
On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch
On 04/03/2013 01:47, Boian Mitov wrote:
Strongly disagree.
Anonymous methods are a critical feature of any mother language, and
allow vast improvements of the code and the readability. I recently
started rewriting our libraries with anonymous methods and that alone
allowed for cutting over
on a separate line
(which I would consider a very special case)
- the place of declaration also does not change the line count.
-Original Message- From: Martin
Sent: Sunday, March 03, 2013 7:38 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Delphi anonymous methods
On 04/03/2013 01:47
On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote:
IMHO Martin Schreiber is doing a great job using these comparisons and
some improvements could be made in FPC... but he is making a mistake
in their approach of how to present FPC's defects.
I am not so sure about this... I know
, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a
benchmark on Linux too.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote:
Am 01.03.2013 22:40, schrieb Martin Schreiber:
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote:
I did a quick test on win32, it seems to be a little bit smaller than
2.6.2:
02.03.2013 10:09 5.774.848 mseide.exe
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
Martin
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Compiled with which FPC version?
trunk.
??? MSEgui compiles with trunk?
It is mostly unicodestring centric, so that shouldn't be such a surprise?
MSEgui has an own
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers is that it is the linking
stage that needs speedup. This does not really come
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote:
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote:
On Sat, 2 Mar 2013, Martin Schreiber wrote:
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote:
Anyway, what seems obvious from your numbers
6'026'259 mseidefp.exe
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote:
Am 01.03.2013 18:33, schrieb Martin Schreiber:
Hi,
In order to have a good benchmark for FPC
Expect the next release to be even slower.
Will it produce better code instead?
Martin
___
fpc
If the RTL is compiled with optimization then same functions may not
have a stackframe. Of course that is intended. But...
Within the list of those is at least one (probably both of the following:
Procedure fpc_assert(Const
Msg,FName:Shortstring;LineNo:Longint;ErrorAddr:Pointer);
revision 23621
Win 32 / Vista
RTL build with OPT=-gl -gw -godwarfsets -O-1
compiler build with OPT=-gl -O3 -Or -CpPENTIUMM -OpPENTIUMM
Lazarus -WC -gh -Criot -gw2 -godwarfsets -O-1 -gt
The following line crashes with SigSegV
writestr(BaseConf, AType,':',
' IMode=',
On 07/02/2013 07:14, Michael Ring wrote:
One more thing, do you know why ExecuteCommand is defined as protected
and not public in GDBMIDebugger? I need to send some extra commands to
GDB to make the remote connection, using ExecuteCommand is an elegant
way to do this. But the method is
On 07/02/2013 23:51, Michael Ring wrote:
Index: debugger/debugger.pp
===
--- debugger/debugger.pp(revision 40204)
+++ debugger/debugger.pp(working copy)
@@ -3304,6 +3304,7 @@
const
OLD_GDB_DBG_NAME = 'GNU
semaphore.
MSEgui has a semaphore implementation. On Linux it uses the libc interface, on
Windows an own implementation with a windows event object,
lib/kernel/windows/msesysintf1.pas. Works so far, but with sync mechanics one
never knows...
Martin
___
fpc
On 05/02/2013 22:14, Michael Ring wrote:
I have integrated openocd debugger class as a child of the gdbmi
debugger classes, basic code upload debugging now works for me in
lazarus, still has some rough edges, this is why I am seeking for
support by the arm-embedded hackers here in fpc-devel.
On 27/01/2013 14:42, Alexander Klenin wrote:
On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin paul.ishe...@gmail.com wrote:
27.01.13, 1:43, Sven Barth wrote:
Based on the results of the for-in-index thread I've decided to come
up with a draft for the Tuple type which is thought by many people to
On Friday 25 January 2013 09:07:27 Michael Van Canneyt wrote:
Once more: simple is beautiful.
Free pascal becomes less so with each of these features.
Agreed. I even would say it becomes more by removing some of the
existing features. ;-)
Martin
On 20/01/2013 18:50, Jonas Maebe wrote:
It looks like a gdb issue (from dwarfdump; readelf -g can show similar
information):
Ah yes. objdump does that on win too.
Thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Since I don't know the fpc cdoebase, I can not check this myself.
I suspect it is a gdb issue. But if it is not to much work, maybe
someone who does know fpc dwarf generation can check that it is not fpc?
I got the following source:
type TFoo = array [0..191] of integer;
and in gdb
On 16/01/2013 13:06, Ludo Brands wrote:
Perhaps a Hint or Warning when inline is used in the declaration
could avoid these mistakes.
+1 for a hint in those cases.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Having recently asked about and learned that it is mainly a hint about
performance. I have now another question about this hint:
project1.lpr(6,9) Hint: Mixing signed expressions and longwords gives
a 64bit result
Actually not so much about the hint, as about the fact that in the below
On 14/01/2013 13:54, ik wrote:
On Mon, Jan 14, 2013 at 3:11 PM, Martin laza...@mfriebe.de wrote:
Actually not so much about the hint, as about the fact that in the below
example fpc extends the operands to 64 bits.
program Project1;
var
x: cardinal;
i, j: integer;
begin
i:= x or j
end
On 14/01/2013 14:10, Jonas Maebe wrote:
That said, the compiler contains an optimization pass that tries to
remove 64 bit widenings on 32 bit platforms in case it turns out they
were not necessary. It will also catch the above example and the
generated code will only contain a 32 bit
On 14/01/2013 15:27, Hans-Peter Diettrich wrote:
Martin schrieb:
On 14/01/2013 13:54, ik wrote:
On Mon, Jan 14, 2013 at 3:11 PM, Martin laza...@mfriebe.de wrote:
Actually not so much about the hint, as about the fact that in the
below
example fpc extends the operands to 64 bits.
program
On 14/01/2013 15:52, Jonas Maebe wrote:
On 14 Jan 2013, at 16:44, Martin wrote:
This is casting a set of bits (neither signed, nor unsigned - a set
is not a number at all) into a number. This only needs to have a
definition, if it should cast to signed or unsigned type.
It has to be signed
, sorry for the impertinence, how do resource strings fit in the
string handling scenario of Free Pascal trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
of
a technical context. Like in we had this topic a thousand times and
maybe it's better we shut up about it now before we get moderated.
Correct. :-)
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
with -Fcutf8
unicodestringvar:= 'Best'#228'tigung';
produces a different result on fixes_2_6 and trunk? I assume in trunk there
will be a compile error? We use this form of character constants in MSEgui to
have the sources in pure ASCII.
Martin
___
fpc-devel
, please accept my apology, but I need to decide if FPC is still the
right tool for my purposes.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
such a tool.
But now we are off topic.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote:
On 05 Jan 2013, at 12:53, Martin Schreiber wrote:
So compiled with -Fcutf8
unicodestringvar:= 'Best'#228'tigung';
produces a different result on fixes_2_6 and trunk? I assume in trunk
there will be a compile error
On 01/01/2013 13:18, Jonas Maebe wrote:
On 15 Dec 2012, at 19:35, Martin wrote:
I am trying to figure out how to do that, or what I do wrong. I found a page
about $codepage, but it did not help
http://wiki.freepascal.org/LCL_Unicode_Support
I didnt find the fpc specific page, if exists (I
On 01/01/2013 14:24, Jonas Maebe wrote:
On 01 Jan 2013, at 15:14, Martin wrote:
On my hardware it is normally all fine, but fails if I add the $codepage. I
could spent a lot of work boiling that down to a sample. But given that I
couldn't even find the docs what I really should expect
On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
On 01 Jan 2013, at 15:14, Martin wrote:
On my hardware it is normally all fine, but fails if I add the $codepage.
I could spent a lot of work boiling that down to a sample. But given that
I couldn't even find the docs what I really
On Tuesday 01 January 2013 16:44:28 Jonas Maebe wrote:
On 01 Jan 2013, at 16:31, Martin Schreiber wrote:
On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
Without a {$codepage xxx} directive, string constants containing
characters
#127 remain exactly as they appear in the source
On Tuesday 01 January 2013 16:54:21 Martin Schreiber wrote:
So
UnicodeStringVariable:= 'abcdäüö';
always will call a conversion function?
And how works
{$codepage 8859-1}
...
UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074;
?
Martin
, and the codepage directive has no influence.
{$codepage utf8}
...
UnicodeStringVar:= 'abcd'#228#252#246;
Does it store 'abcdäüö' in trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
at
compiletime independent if they contain codepoints 255?
Has somebody a link to Embarcadero documentation about the matter? I assume
FPC trunk does exactly the same as Delphi XE3 with strings?
Thanks for your patience, Martin
___
fpc-devel maillist - fpc
On Wednesday 26 December 2012 11:20:35 Florian Klämpfl wrote:
Am 26.12.2012 06:07, schrieb Martin Schreiber:
Hi,
Does any body work on a LLVM backend for Free Pascal?
Thoughts?
The counterpart of what you want: tries to generate great code at any
cost while being maintainable and having
On Wednesday 26 December 2012 12:41:42 Sven Barth wrote:
On 26.12.2012 05:42, Martin Schreiber wrote:
Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.
AFAIK Delphi 7 does not need such an approach so I hope
be accepted. (I myself would use it ;))
It would unfortunately blow up the code base again.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking
On Monday 24 December 2012 10:23:00 Sven Barth wrote:
Am 24.12.2012 07:48 schrieb Martin Schreiber mse00...@gmail.com:
On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Do you know how RTTI will be encoded?
I would
Writing this from my laptop I do not currently have all the various
checkouts to look at the exact changes myself. But enquiring based on
the reports I have read.
http://bugs.freepascal.org/view.php?id=23523
From FPC trunk r23202 log:
* Include regdef.inc only if XMLREG is defined
On 24/12/2012 12:17, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
too. So if somebody implements non ASCII identifiers because he needs a
second source Delphi compiler it will be merged because the addition does not
break existing code. I assume utf-8 identifiers
On 24/12/2012 13:05, Marco van de Voort wrote:
In our previous episode, Martin said:
Hm that makes it easy to have an incomplete list, that could later
become a problem
half-width spaces etc..., control chars (RTL/LTR...), currently unused
codepoints (that could become anything in future
. Not in the near future but
the primary goals are defined already:
- Back to the roots.
- Add the necessary to build the most productive universal programming
language.
- Remove the not necessary.
- Produce at least as good code as Delphi 7.
- Compile at least as fast as Delphi 7.
Martin
On Monday 24 December 2012 17:45:34 Henry Vermaak wrote:
On Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote:
BTW, I actually think about to fork Free Pascal. Not in the near future
but the primary goals are defined already:
- Back to the roots.
What are the roots?
- Add
501 - 600 of 1515 matches
Mail list logo
