Hi,
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has the situation changed in the meantime?
Does anybody know if Delphi supports Unicode resource
Am 29.04.2011 08:52, schrieb Jonas Maebe:
On 29 Apr 2011, at 09:43, Martin Schreiber wrote:
In 2008 there was a thread about FPC and Unicode resoure strings with the
conclusion that FPC does not support them.
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg10327.html
Has
Am 04.04.2011 07:29, schrieb Michael Van Canneyt:
On Mon, 4 Apr 2011, LacaK wrote:
But It seems to me, that DataChanged is now called 2 times
First in TDataSet descendants in SetFieldData method (see
bufdataset.pas, dbf.pas, paradox.pp, meds.pp) and second in above
mentioned place.
So it
On Thursday 17 March 2011 09:54:02 Jonas Maebe wrote:
Hello,
Finally I'm not alone anymore in repeating this over and over again:
http://twitter.com/kylix_rd/statuses/48210052770836480
Byvalue or byreference for const parameters is defined in Delphi 7 language
manual on page 12-1, it seems
On Thursday 24 February 2011 08:02:20 LacaK wrote:
So also here we can see, that FieldDef.Size is expected to be number of
characters not bytes.
So IMHO logical conclusion will be say, that TFieldDef.Size for string
fields has same menaing as Field.Size, so it is number of characters
(so
On Thursday 24 February 2011 09:49:51 michael.vancann...@wisa.be wrote:
Agreed. In MSEgui tmsestringfield.size is the maximum allowed character
count for the field. 0 = no limit. tmsebufdataset stores string data as
UnicodeString instead to use a fixed record layout.
But here you
On Thursday 24 February 2011 10:16:43 michael.vancann...@wisa.be wrote:
But here you implicitly assume that you have a fixed number of bytes per
character. You should always be explicit about such things, since this
is a non-trivial assumption.
I don't understand.
tmsebufdataset
On Sunday, 30. January 2011 12.13:21 Florian Klämpfl wrote:
Actually I think anything about a ten percent slower compiler will
people make cry ... And as far as I understand, for projects with a lot
of units it will be even worse, right?
I cry if FPC doesn't compile at least ten percent
On Wednesday, 12. January 2011 23.05:02 Juha Manninen wrote:
Martin Schreiber kirjoitti maanantai 10 tammikuu 2011 19:22:49:
On Monday, 10. January 2011 16.27:19 Marco van de Voort wrote:
And there are three such cases
- normal FPC and Delph 2007- code : ansistring(0)
- Lazarus
On Thursday, 13. January 2011 18.57:00 Hans-Peter Diettrich wrote:
The implementation can choose any model. Different models can be
implemented as well, so that the final decision about the new standard
can be delayed, until the models can be tested in real world applications.
One model has
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
So where is error ?
1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
-or-
2. Is it wrong in implementation of TSQLConnectors, which write data
into record buffer (of TStringField) and do not convert them always
On Wednesday, 12. January 2011 14.27:14 LacaK wrote:
Yes, sounds logicaly to me.
Then you propose same way for TStringField ? (internaly store as
UnicodeString UTF-16 and also TStringField.Text should return
UnicodeString instead of String ?
It is done so in MSEgui fork of sqldb.
In case you
On Monday, 10. January 2011 16.27:19 Marco van de Voort wrote:
And there are three such cases
- normal FPC and Delph 2007- code : ansistring(0)
- Lazarus : ansistring=utf8
- Delphi 2009+ UTF16.
- fpGUI: ansistring = utf-8
- MSEgui: existing FPC UnicodeString = utf-16
Martin
On Tuesday, 16. November 2010 14.52:12 Paul Breneman wrote:
I'd like to take the minimal distros and add a simple option to use
MSEide and it supports debugging from what I understand. Then maybe
extending that with remote debugging would be the next item.
MSEide is ready to work with remote
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
Nowhere is the Delphi behaviour guaranteed, not even by Delphi.
Well, I can always argue that FPC tries to clone/mimic Delphi behaviour
in many ways... it's that little FPC design goal called delphi
compatibility. Think
On Tuesday, 26. October 2010 13.22:27 Anton Kavalenka wrote:
Yes, windows only.
But they fully understand bonuses from FPC and Lazarus but really hate GDB.
Their last argument - we need assembly-line stepping debugger like in
Delphi.
???
Works with gdb, see MSEide example:
On Tuesday, 26. October 2010 13.47:22 Graeme Geldenhuys wrote:
Op 2010-10-26 13:22, Anton Kavalenka het geskryf:
Their last argument - we need assembly-line stepping debugger like in
Delphi.
This is actually supported in MSEide, I did it the other day (View
Assembler and use 'Next
On Tuesday, 26. October 2010 15.07:31 Graeme Geldenhuys wrote:
The CPU
window doesn't work at all though, where it did under 32-bit Linux.
http://opensoft.homeip.net/~graemeg/mseide_debug_windows.png
Plase check if 'Project'-'Options'-'Debugger'-'Target'-'Processor' is set
to 'i386'
On Tuesday, 26. October 2010 16.14:50 Graeme Geldenhuys wrote:
The problem is then in the MSEide template projects (issue is probably in
svn repository too, because the default ones are not changed locally). I
went Project New From Template console.prj. By default it is set it
i386 instead
On Friday, 22. October 2010 22.40:55 Andrew Brunner wrote:
Looking to get some resolution to an immediate problem with postgres
component I have...
Have a look to MSEgui lib/common/db/mpqconnection.pp, it supports blobs by
mapping to bytea.
http://developer.berlios.de/projects/mseide-msegui/
On Saturday, 23. October 2010 13.11:01 Michael Van Canneyt wrote:
On Fri, 22 Oct 2010, Andrew Brunner wrote:
Looking to get some resolution to an immediate problem with postgres
component I have...
Field definitions for blob can be mapped to bytea and enable support
for blob data as I
Am 19.10.2010 09:37, schrieb Michael Van Canneyt:
[...]
Currently all we got from Hans Peter were unmanageable patches
supposedly fixing things that were not broken or in need of fixing.
If he had first done some smaller things - take your pick in the bugtracker
- and we had seen that this
On Tuesday, 19. October 2010 15.42:30 Alexander Klenin wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and strings.
Hmm, strange records and pchars
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least this is certainly true for FPC on Windows case.
Do you remember the factor 10 compiling speed advangage of Delphi7
On Tuesday, 19. October 2010 16.42:19 Alexander Klenin wrote:
Do you remember the factor 10 compiling speed advangage of Delphi7
compared with FPC 2.4?
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
I do. I also remember that one of the goals of DoDi's previous
On Tuesday, 19. October 2010 17.17:04 Graeme Geldenhuys wrote:
Op 2010-10-19 17:06, Martin Schreiber het geskryf:
core aware compiler without a team of highest skilled fulltime developers
working several years...
Why do you think we are not that already? :-)
Aha! Maybe that's the reason
On Friday, 8. October 2010 17.55:55 José Mejuto wrote:
Attached is the example. One form that load a menu which opens a new
form which display a table in a grid. You will need to change the
password setup, and maybe database (I'm using aliases instead full
path), and of course the sql line.
On Monday, 11. October 2010 11.15:15 José Mejuto wrote:
MS I converted the example to MSEgui, works OK.
So or the problem is in LCL or I'm suffering some kind of poltergeist.
Or in SQLDB. MSEgui has a forked SQLDB which has completely rewritten parts.
Martin
On Friday, 8. October 2010 11.16:44 José Mejuto wrote:
Relationship
MainSecond form Datamodule
+--+ +--++---+
| | | SQLQuery |+--- SQLConnection --+
|
|Button--|| || | | |
+--+ ++--+---
On Wednesday, 6. October 2010 13.49:59 José Mejuto wrote:
Hello FPC,
I think I can see your point, but from the end user point of view
this is not a possibility. How to tell to the user, Remeber you must
call beginglobal... and notifyglobal... and finally endglobal... when
you create forms
On Thursday, 7. October 2010 17.25:28 José Mejuto wrote:
Hello FPC,
Thursday, October 7, 2010, 8:27:23 AM, you wrote:
MS Maybe you mix up component creation order and form/datamodule creation
order? MS I wrote about form/datamodule creation order.
The datamodule is created just in program
On Thursday, 7. October 2010 20.46:54 José Mejuto wrote:
Thank you, I'll try to gather more information from Lazarus list, but
if that's the case it completly defeats the advantages of a datamodule
and/or the presence of a published Active property in the SQLQuery (as
it is only valid if it
On Tuesday, 5. October 2010 17.24:09 José Mejuto wrote:
Hello FPC,
Tuesday, October 5, 2010, 4:08:08 PM, you wrote:
As you can see the Loaded event is called (marked with some //-)
before calling GlobalFixupReferences,
MS Not if GlobalLoaded is set.
Yes, but it is not set, because
On Tuesday 05 October 2010 00:37:44 José Mejuto wrote:
Hello FPC,
I find a problem that I'm unable to resolve, with my limited skills.
In TReader when a property is a TClass it is being added to be
resolved after all components are loaded, but the Loaded call is
performed before this fixup,
On Tuesday 05 October 2010 13:55:53 José Mejuto wrote:
if not Assigned(GlobalLoaded) then begin --
for i := 0 to FLoaded.Count - 1 do
TComponent(FLoaded[i]).Loaded;//
end;
finally
if not
...@freepascal.org schreef:
Am 13.09.2010 13:47, schrieb Martin Schreiber:
On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote:
Am 13.09.2010 11:15, schrieb Martin Schreiber:
Delphi 7 FPC
Exe size: 3131392 3689304
Code
Hi,
Some numbers about the MSEide exes compiled as testcase in
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
System:
win2000, AMD Athlon XP 3000+, 1GB RAM
Delphi 7 FPC
Exe size: 3131392 3689304
Code:
On Monday, 13. September 2010 12.57:14 Adem wrote:
Martin,
Could I have a copy of this exact setup --unless it is too big to send.
What do you need?
The source is here:
http://developer.berlios.de/svn/?group_id=11520
The compiler commands are here:
On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote:
Am 13.09.2010 11:15, schrieb Martin Schreiber:
Delphi 7 FPC
Exe size: 3131392 3689304
Code: 2128524 2138240
Data: 752085
On Monday, 13. September 2010 14.12:38 Graeme Geldenhuys wrote:
Op 2010-09-13 13:47, Martin Schreiber het geskryf:
I can not use resource strings because FPC resource strings are not
unicode capable AFAIK.
Probably related to your choice of UCS-2 - I don't really know the specific
issues
Am 12.09.2010 00:20, schrieb Graeme Geldenhuys:
Now this is weird! Anybody else spotted the difference? Delphi seems
to compile +-28000 lines less that FPC! Florian, I presume it's the
same machine with the same MSEgui source code revision? What would be
the reason for that?
Would that (lines
On Sunday, 12. September 2010 10.12:59 Florian Klämpfl wrote:
Agreed. My opinion is that before we start to implement difficult and
error-prone multi-threading into FPC we should find out why the hell
Delphi 7 can compile so much faster
Because of the same reason why it seems to take
On Sunday, 12. September 2010 10.29:32 Florian Klämpfl wrote:
And that results in a discrepancy of factor 5..10? I can't believe it.
Digging out 1.0.10 and using some extreme example:
C:\fpc\tests\webtbsc:\pp 1.0.10\bin\win32\ppc386.exe tw2242 -O2
Free Pascal Compiler version 1.0.10
Am 12.09.2010 10:12, schrieb Florian Klämpfl:
The 2.x register allocator is more robust (no more internalerrors 10),
it is small (basically 2k lines, compiler/rgobj.pas) and it generates
reasonable register allocations on all types of CPUs (remember, FPC
supports CPUs with high register
On Sunday, 12. September 2010 18.29:34 Florian Klämpfl wrote:
Please take it with humor. :-)
As long as the compiler itself builds on a reasonable machine in less
than 10 seconds, I'am happy :)
Yup, I know. But there are people who use FPC for other tasks than compiling
FPC and there are
On Friday 10 September 2010 17:43:59 Adem wrote:
Sometime ago, there was a brief mention of multi-threading FPC would be
counter productive because compilation process was mostly disk IO bound
--this is what I understood anyway.
I wanted to check to see if disk IO was really limiting
On Saturday, 11. September 2010 11.32:38 Jonas Maebe wrote:
So yes, FPC is slower than Delphi. Would parallelising FPC reduce the speed
gap?
Because the gap is so big I think not substantial.
Given that (please correct me if I am wrong):
- FPC bottleneck is disk IO and not compiler logic and
On Saturday, 11. September 2010 12.25:14 Juha Manninen (gmail) wrote:
One would think Delphi and FPC need the same disk IO?
I read the threads. My guess is also that the slowness comes from searching
and writing many files in big directory structures. It is slow even if the
files are cached.
On Saturday, 11. September 2010 18.37:49 Graeme Geldenhuys wrote:
On 11 September 2010 16:12, Mattias Gaertner wrote:
Martin, can you give a comparison between win32 and Linux 32?
Add to that Martin, I know MSEgui is compilable with FPC and
Delphi. Is MSEgui compilable with Kylix 3 too?
On Saturday, 11. September 2010 16.12:10 Mattias Gaertner wrote:
Maybe dcc32 likes the MSEgui sources.
Or maybe FPC does not like MSEgui sources. ;-)
Martin, can you give a comparison between win32 and Linux 32?
I don't have a working Kylix 3 environment at the moment. IIRC dcc32 on Linux
On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote:
What machine? Because with hot disk cache, I just build MSEide in about
10 s (15 s cold) on W7 64 Bit:
The same as for all other tests,
win2000, AMD Athlon XP 3000+, 1GB RAM
...
Linking mseidefp.exe
308574 lines compiled, 10.6
On Sunday, 12. September 2010 01.31:43 Dimitri Smits wrote:
And why does the Delphi commandline compiler (dcc32) not need this IDE
assistance?
it does. Delphi IDE passes extra assumptions/directories that the
commandline tool does not know about (for instance $(DELPHI)/Projects/Bpl).
On Saturday, 11. September 2010 21.10:20 Florian Klämpfl wrote:
Anyways, before this ends in an endless discussion: if anybody is
interested in improving FPC compilation speed (for my needs is
sufficient) and have a look at fillchar and, have a look at FPC's unit
loading algorithm (not the
On Wednesday 09 June 2010 11:30:21 Graeme Geldenhuys wrote:
Op 2010-06-09 11:02, Florian Klaempfl het geskryf:
interpretation of bounds, the current behaviour is perfectly valid for
any other uses.
Not as I see it, and described in the bug report. Think of the pixel
screen/grid like the
On Wednesday 09 June 2010 15:31:27 Graeme Geldenhuys wrote:
Op 2010-06-09 14:32, Martin Schreiber het geskryf:
TRect has been defined in order to communicate
rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...):
And X11 (XLib) was intelligent enough to foresee the ambiguity
On Friday 28 May 2010 08:48:05 Graeme Geldenhuys wrote:
Anyway, I was hoping to get this in the next FPC release because I want to
implement something major in fpGUI that requires this. If not 2.4.2, I will
have to delay this feature in fpGUI too. What is the expected (I know it
might be a
On Friday 28 May 2010 13:46:07 Martin Schreiber wrote:
Warning:
When I tried Corba interface delegation to an interface property with FPC
trunk and MSEgui this week I got SIGSEGV's. I made no bug report because I
was not able to reproduce the problem with a simple test program up to now,
I
On Wednesday 19 May 2010 12:20:23 Graeme Geldenhuys wrote:
Hi,
Is the following bugfix (original target was 2.4.0) going to make it into
FPC 2.4.2?
I'm about to implement something in fpGUI and would really like to use the
Observer pattern and interface delegation to attach the Observer
On Wednesday 17 February 2010 09:15:53 Marco van de Voort wrote:
Reject as far as I'm concerned. I'd like to see the RTL being in the system
encoding. (IOW UTF-8 on at least FreeBSD/Linux) using an abstracted
RTLString.
Aren't filenames on Linux an array of bytes without any encoding by
On Monday 15 February 2010 21:45:33 Joost van der Sluis wrote:
I think option two is the best one. Then I can use the TEventLog for
daemon and web applications. But I'm really interested in the opinion of
the Lazarus and MseIDE people.
What is the advantage to integrate log facility into
On Monday 08 February 2010 10:53:00 Michael Schnell wrote:
On 02/05/2010 07:00 PM, Martin Schreiber wrote:
MSEgui does not use the libc unit.
Of course it does not, as in the msesys unit the same code (just
external ) as in libc is available and thus introduced the same
potential
On Friday 05 February 2010 14:40:25 you wrote:
I finally succeeded in getting a proof of concept noguiapplication
project compiled and running using the Lazarus IDE.
Seemingly, the timer event is working correctly.
It still uses the depreciated old libc unit.
Martin, can we work together
On Monday 25 January 2010 17:16:59 Michael Schnell wrote:
@Martin:
what is the complicated thread save stuff with sys_semdestroy()
necessary for ?
Would it not be useful to use a Futex instead of a sema ?
Possible, I don't touch such code if it works - or if I think it works. ;-)
Do you
On Friday 22 January 2010 14:39:51 Michael Schnell wrote:
mselibc:
function m_sigprocmask(__how:longint; var SigSet : TSigSet;
var oldset: Tsigset):longint;cdecl;external clib name
'sigprocmask';
FPC RTL singnalh.inc:
function sigprocmask(__how:longint; var SigSet : TSigSet;
On Wednesday 20 January 2010 12:29:58 Michael Schnell wrote:
When I try to define the functionFpsigprocmask in that way myself I
get some type conflicts when calling it with Martin's code. (I'll try to
solve this when I am able to point it to the proper RTL function.
You can use the minimal
On Wednesday 20 January 2010 21:22:10 Marco van de Voort wrote:
That's still no reason to not use the supported routines. One can even
simply recompile the RTL to have the normal routines use libc (a feature
that is in production for e.g. OS X)
I trust more in libc than in FPC routines, libc
On Friday 13 November 2009 12:51:58 Michael Schnell wrote:
Martin Schreiber wrote:
On Linux xlib and xft have utf-16 interfaces.
What exactly are xlib and xft and why does MSE-GUI seemingly use those
while LCL seemingly uses something else ?
xlib is the C-library used under Linux
On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote:
Michael Schnell wrote:
Martin Schreiber wrote:
On Linux xlib and xft have utf-16 interfaces.
What exactly are xlib and xft and why does MSE-GUI seemingly use those
while LCL seemingly uses something else ?
Martin answered
On Friday 13 November 2009 15:58:10 Michael Schnell wrote:
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
Michael, you are joking, right? ;-)
Please join us on NNTP:
news://news.grid-sky.com/public.mseide-msegui.talk
to get answers to
On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
So please don't destroy this ideal solution by dropping current FPC
UnicodeString in favour of the Delphi string which is complicated,
Who says that? If you don't mess with code pages, the only different
you'll might see is that
On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote:
What are the differences of AnsiString and RawByteString?
Ansistring: system encoding
System encoding at compile time or run time?
___
fpc-devel maillist -
On Tuesday 10 November 2009 19:08:45 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
On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote:
I try to prove the exciting statement. How can I build a startup compiler
for the cpstrnew branch or
I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew
branch compiler dir should work using 2.2.4/2.4.0
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
Free Pascal Compiler version 2.3.1 [2009/11/01] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for
On Wednesday 11 November 2009 15:57:28 Paul Ishenin wrote:
Martin Schreiber wrote:
On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote:
What rtl did you use? You need one from the branch.
Compiling the cpstrnew rtl with fixes_2_4 does not work:
1. Build compiler executable
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
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks and more complicated address calculation. OK, you can say you
will not notice the small difference. But
On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote:
Where? A pure unicodestring routine won't get additional checks.
What is a pure unicodestring routine?
and more complicated address calculation.
Where? Adding 16 instead of 12 makes no difference.
The major difference will be
On Tuesday 10 November 2009 20:20:06 Florian Klaempfl wrote:
OK, so you say that the processing of the new and the current
UnicodeString and therefore the RTL and compiler procedures are identical
with exception of the initialization of 4 bytes with a constant?
Well, two times two byte ;)
On Tuesday 10 November 2009 21:38:33 Marco van de Voort wrote:
The only problem is the db-aware part and the few other widgets that can
have 10 elements and more, like treeview. There mass conversion can
hurt, e.g. when loading the data into the widget.
That's the reason why MSEgui stores
On Monday 09 November 2009 16:34:52 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Will there be a simple reference counted WideString on all platforms as
the current FPC UnicodeString is?
Why does there need to be a widestring type if there is unicodestring
On Saturday 24 October 2009 18:32:32 JoshyFun wrote:
Hello Martin,
Saturday, October 24, 2009, 10:42:27 AM, you wrote:
MS What do you recommend, should MSEide parse the gdb watch results and
run MS another query in order to get the values of var parameters? How
does Lazarus MS solve the
On Friday 23 October 2009 22:09:30 you wrote:
Martin Schreiber wrote on Fri, 23 Oct 2009:
Is it as designed that the displayed value of a var parameter is the
address instead the value?
It's because nobody bothered to submit a patch to GDB yet to add
support for var parameters
Hi,
x64 Suse 11.1, the program:
program gdbvarparam;
{$ifdef FPC}{$mode objfpc}{$h+}{$endif}
{$ifdef mswindows}{$apptype console}{$endif}
uses
sysutils;
procedure test(var par1: integer);
begin
end;
var
int1: integer;
begin
int1:= 123;
test(int1);
end.
The debug session:
Hi,
There were changes in the TComponent base functionality in FPC trunk recently.
Please note that I do not use FPC trunk for MSEide+MSEgui so I do not test
this modifications. Please be extremely careful with changes in low level
opjpas code because it can have big consequences.
Please test
On Thursday 08 October 2009 17:36:44 Joost van der Sluis wrote:
I want to know if the current implementation is usefull for the existing
application-frameworks like Lazarus and MSEIde. If that's so I'll maybe
merge it to fpc 2.3.1.
MSEide has its own implementation of
Hi,
linux-i386 Suse 11.1, binutils 2.19.51-15.1, the program:
program gdbthread;
{$mode objfpc}{$h+}
uses
cthreads,sysutils;
begin
end.
The compile - debug session:
m...@linuxca:~/proj/msegui/testcase/FPC/2_2_4/gdbthread ppc386 -gl
gdbthread.pas
Free Pascal Compiler version 2.2.4
On Friday 09 October 2009 12:33:51 Michael Schnell wrote:
MSE provides creating a nogui application that handles the message
queue without complex external stuff but in Linux uses sem_wait() to
wait in case of an empty message queue and signals for posing events. (I
don't know how they do
On Friday 09 October 2009 13:49:14 Jonas Maebe wrote:
On 09 Oct 2009, at 13:44, Martin Schreiber wrote:
What is wrong? Bigger gui-programs are working.
Seems to be unrelated to FPC:
http://forums.opensuse.org/programming-scripting/412939-gdb-unable-debug-ap
plication.html
Here is a hint
On Friday 09 October 2009 14:18:37 Jonas Maebe wrote:
On 09 Oct 2009, at 14:11, Martin Schreiber wrote:
That means the linker removes libpthread.so and gdb can't work
without?
There is nothing to remove by the linker in case of your FPC program,
because the cthreads unit does
On Friday 09 October 2009 16:43:08 Jonas Maebe wrote:
On 09 Oct 2009, at 16:22, Martin Schreiber wrote:
It was not caused by a bug in binutils but the new binutils with the
bugfix
With which bugfix?
https://bugzilla.novell.com/show_bug.cgi?id=471901
And are you certain that only
On Tuesday 15 September 2009 15:31:36 Thaddy wrote:
afaik widestrings are reference counted in Delphi. PWideChars not.
According my experience, the Delphi7/Kylix3 documentation and this article:
http://edn.embarcadero.com/article/21301
WideStrings are now reference counted. In Windows, the
On Tuesday 15 September 2009 11:49:13 Florian Klaempfl wrote:
Who says that? What is not supported? Which issue report? FPC 2.3.1
claims to support the UnicodeString type fully and it can be that bad
because e.g. MSE is using it afaik.
Correct, it is enabled for MSEide+MSEgui SVN trunk which
On Tuesday 15 September 2009 12:56:08 Graeme Geldenhuys wrote:
Who says that? What is not supported?
This I found myself:
* Unicode+Variants... varUString type.
By Google'ing for some D2009 unicode examples and searching the FPC
source. Here I list a few that I found in under 5 minutes:
On Tuesday 15 September 2009 14:34:52 Jonas Maebe wrote:
I don't think that the default source code encoding has ever been
changed. And the way to specify it is also quite old already.
Wasn't a string constant containing a character #127 treated as widestring
earlier?
Martin
On Tuesday 15 September 2009 15:21:54 Martin Schreiber wrote:
On Tuesday 15 September 2009 15:07:48 Jonas Maebe wrote:
On 15 Sep 2009, at 14:54, Michael Schnell wrote:
Martin Schreiber wrote:
On Windows widestring is actual a
not reference counted OLE-string.
How can decent
On Tuesday 15 September 2009 18:04:33 Luiz Americo Pereira Camara wrote:
In my view, to get the fpc unicode support in a good state would be
necessary to implement the encoding field in the string type so
converting strings can be done system independently (seems to be the
case of cpstr
On Thursday 10 September 2009 19:42:22 Ivo Steinmann wrote:
Florian Klaempfl schrieb:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
well, nobody seems to know it... eg. if you go through code in rtl
On Saturday 12 September 2009 10:07:55 Mattias Gaertner wrote:
On Sat, 12 Sep 2009 09:33:11 +0200
Martin, I hope you mean Data=ID and Code=nil.
Yup, you are right, thanks for correcting.
Martin
___
fpc-devel maillist -
On Saturday 12 September 2009 12:14:07 Jonas Maebe wrote:
Or do you use this information only for display or code completion
purposes (so you always want the parameters in left-to-right order)?
In that case, I don't think that's possible with rtti.
:-(
Bad news for MSEide. MSEide uses RTTI
201 - 300 of 513 matches
Mail list logo
