On Wed, 21 Oct 2009, Sergei Gorelkin wrote:
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
or better yet, because it is more strict
On Thu, 22 Oct 2009, Martin Schreiber wrote:
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
On Thu, 22 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Hm. I like this direction of thinking, yes...
Hm. I like that after 100 mails of 'yes, I like them', 'no, I don't like
them' we finnaly moved to the initial idea of the tread - design and
implementation discussion
On Thu, 22 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Don't forget the remark by Sergei Gorelkin, that in fact a single
call could be enough.
In fact a single call could not be compatible with delphi solution.
That is so, but none of what is discussed is compatible
On Tue, 27 Oct 2009, Florian Klaempfl wrote:
Paul Ishenin schrieb:
I have compared what d2010 TObject has and found a few differences:
1. Dispatch method is virtual
2. new method: class function UnitName: string;
3. new method: function Equals(Obj: TObject): Boolean; virtual;
4. new method:
On Tue, 27 Oct 2009, Graeme Geldenhuys wrote:
Hi,
I submitted a minor patch for the 'fpdoc' tool. Could this be merged
with the v2.3.1 branch as well, so that it is available in the next
stable FPC release?
http://bugs.freepascal.org/view.php?id=14917
No. The tag for 2.4.0 releas is
On Tue, 27 Oct 2009, Vincent Snijders wrote:
Michael Van Canneyt schreef:
On Tue, 27 Oct 2009, Graeme Geldenhuys wrote:
Hi,
I submitted a minor patch for the 'fpdoc' tool. Could this be merged
with the v2.3.1 branch as well, so that it is available in the next
stable FPC release?
http
On Wed, 28 Oct 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
On the other hand, UnitName may come in handy for the Lazarus IDE.
And this is the most difficult thing amoung other new methods :)
I am trying to get UnitName from the RTTI but have some problems:
1. If I call
On Wed, 28 Oct 2009, Graeme Geldenhuys wrote:
Hi,
While testing fpGUI DocView, I came across the following bug.
http://www.freepascal.org/docs-html/rtl/sysutils/createguid.html
In the See Also section, link is CreateGUID. Well, that means See
Also is pointing right back at the current
On Wed, 28 Oct 2009, Paul Ishenin wrote:
Paul Ishenin wrote:
I am trying to get UnitName from the RTTI but have some problems:
...
Few questions now:
a) Why TypeInfo(TObject) TObject.ClassInfo?
b) Why TypeInfo(TPersistent) = TPersistent.ClassInfo?
No idea why but it is the same in delphi
On Wed, 28 Oct 2009, Thaddy wrote:
TObject should NEVER -xcuse me for shouting - contain rtti information
And we don't propose to do so :)
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, 28 Oct 2009, Felipe Monteiro de Carvalho wrote:
On Wed, Oct 28, 2009 at 4:51 PM, Vincent Snijders
vsnijd...@vodafonevast.nl wrote:
Well, there is still is:
http://lazarus-ccr.sourceforge.net/fpcdoc/rtl/ctypes/csize_t.html
The docs could be out-dated, csize_t doesn't compile in FPC
On Thu, 29 Oct 2009, Vincent Snijders wrote:
Michael Van Canneyt schreef:
The descriptions is completely wrong.
Please post a bugreport.
Done:
http://bugs.freepascal.org/view.php?id=14932
Vincnet
Thank you, Vincnet :-)
Michael.
___
fpc
On Sat, 7 Nov 2009, Martin wrote:
On
http://www.freepascal.org/docs-html/rtl/classes/tcomponent.componentstate.html
the following description is found
csInline The component is being loaded as part of a frame
Now looking at the code, I end up with the impression, that csInline is
On Sat, 7 Nov 2009, Martin wrote:
Mattias Gaertner wrote:
On Sat, 07 Nov 2009 03:00:42 +
Martin f...@mfriebe.de wrote:
On
http://www.freepascal.org/docs-html/rtl/classes/tcomponent.componentstate.html
the following description is found
csInline The component is being loaded as
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
Hello,
Von: Martin laza...@mfriebe.de
Just to make sure I don't to anything silly.
When an application crashes, it usually (at least in Lazarus) dumps a
stacktrace to the console.
I used to use stabs, and the stacktrace was dumped in less than
On Tue, 10 Nov 2009, Jonas Maebe wrote:
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for functionality that
you hopefully won't need anyway.
Correct
On Tue, 10 Nov 2009, Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote:
Did you look into the code in cpstrnew branch? I did.
And which changes are exactly the reason for your concerns?
More checks
Where? A pure unicodestring
On Fri, 13 Nov 2009, Michael Schnell wrote:
So MSE-GUI creates it's own Widget set instead of using something like
GTK. Is this really advantageous ?
Oh boy, this promises to start a long thread...
... which Jonas is likely to end if he gets fed up with it :-)
Michael.
On Sat, 14 Nov 2009, Martin wrote:
I am trying to cut down the time it takes to recompile fpc.
Is there a way to pass any thing to make, to tell it to skip building the
examples. I know COPYTREE to skip installing them, but I don't even want to
build them (after all, I am not using them).
On Sat, 14 Nov 2009, Martin wrote:
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed the
On Fri, 13 Nov 2009, Martin Schreiber wrote:
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:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 11:16, Michael Van Canneyt wrote:
I don't think that the thread-safety is something to worry about at this time;
As you remark, the code was already not thread-safe. But it is something to
keep in mind.
At the very least
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 12:19, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
I can't follow here. There was an undocumented problem in a unit, and now that
it has been identified and sort of made worse, there is no need to tell our
On Thu, 26 Nov 2009, Graeme Geldenhuys wrote:
Hi,
I previously raised this issue, but nothing came from that message thread.
http://lists.freepascal.org/lists/fpc-devel/2009-August/017296.html
To recap, here is the problem...
I noticed that on newer Ubuntu Linux systems that the name of
On Thu, 26 Nov 2009, Marco van de Voort wrote:
In our previous episode, Graeme Geldenhuys said:
the ideal solution - forcing the user to manually create a
libfbclient.so symbolic link to the versioned on. And to do that, they
must have root privileges!
Possible solutions:
On Fri, 27 Nov 2009, Graeme Geldenhuys wrote:
OK, below is one example of a patch, but there are alternative methods
too, hence I am first posting here in the mailing list before I
officially put something in Mantis.
In the example below (which does work) I simply test for the newest
major
On Mon, 30 Nov 2009, Paul Ishenin wrote:
Hello, FPC developers' list.
This weekend Mattias has implemented an option for the IDE to use FPC
resources for projects and packages. Loading of forms from such resources
were made before so there are no more limitations to start use them instead
On Mon, 30 Nov 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Some questions:
1. Isn't it lazarus that eats the error ?
no
2. Is the error you show here a FPCres error ?
If 2 is correct (and I think it is), the compiler has no power over what
fpcres outputs to
screen.
First
On Mon, 30 Nov 2009, Paul Ishenin wrote:
Michael Van Canneyt wrote:
Are you doing this on windows or on linux ? Can you provide a small test
program, so I can test ?
On windows. Small test is in the attachment.
I found a hint.
When Lazbuild is used to build the project, fpcres doesn't
Strange,
I thought I'd fixed this problem a long time ago ??
I'll have another look.
Michael.
On Mon, 7 Dec 2009, Graeme Geldenhuys wrote:
Hi,
Attached is a partial patch for 'utils/debugsvr/debugserverintf.pp'
unit. This unit is cannot be compiled at the moment, but the attached
patch
On Tue, 8 Dec 2009, Graeme Geldenhuys wrote:
2009/12/7 Michael Van Canneyt mich...@freepascal.org:
I'll have another look.
Thanks Michael. Like I said, the patch fixes most of the compiler
errors, but the last 5 erros expect different types which I'm not sure
how to fix - the current
On Tue, 8 Dec 2009, Graeme Geldenhuys wrote:
2009/12/8 Michael Van Canneyt mich...@freepascal.org:
No, it uses the simpleipc unit.
There was an old version of the debugintf/server units, but they should no
longer be used; I think you're using the old versions.
I was looking at the GTK1
On Tue, 15 Dec 2009, Seth Grover wrote:
I just ran across this:
http://bugs.freepascal.org/view.php?id=12984
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=14145
And noticed that it is not present in either the 2.4.0 rc1 branch or
the tags/release_2_4_0 tag.
Is it to late
On Mon, 4 Jan 2010, Stefan Kisdaroczi wrote:
hi list,
the code below compiled and worked with fpc 2.2.x.
With fpc 2.4.0 compilation fails with Division by zero.
8
program divsucc;
begin
writeln( 256 DIV succ(255) );
end.
Well, Succ(255) is probably evaluated as a byte, in
On Wed, 6 Jan 2010, Marco van de Voort wrote:
In our previous episode, Juha Manninen said:
- big units
- type casting (in the worst case)
- ...
The right choice depends on the application.
Abstract base classes and interfaces are recommended by many but actual
projects end up copying
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 12:42:23 Florian Klaempfl wrote:
Juha Manninen schrieb:
Still, best solution has been to put everything into one big file. And
still, I don't like that compiler forces such a thing.
The compiler forces you many
On Wed, 6 Jan 2010, Juha Manninen wrote:
On keskiviikko, 6. tammikuuta 2010 13:14:18 Michael Van Canneyt wrote:
Why ? Every class in 1 file is perfectly possible with include files, and 1
big unit file.
Ok, include files seem to solve this problem.
I don't know why they are not commonly
On Wed, 6 Jan 2010, Michael Schnell wrote:
Include files - just like conditional defines - totally mess up all
code tools.
Is this true for the newest versions of Delphi, too ? I seem to remember
rumors about lots of IDE improvements.
Well, not yet in D2009 as far as I remember, but I
On Sun, 10 Jan 2010, Honza wrote:
Hi all,
as a side effect of some other task, there is available an initial
unit for unmarshalling data from GIR files, which are installed with
the various gobject-introspection-* packages. Result of such load is a
(tree) data structure with the same
On Thu, 14 Jan 2010, Jonas Maebe wrote:
On 12 Jan 2010, at 19:12, Thomas Nelson wrote:
I seem to have come across a minor problem and don’t know how to fix it.
Utilizing the \examples\odbc\testodbc.pp module with FPC 2.2.4 everything
compiles fine
When I upgraded to FPC 2.4.0 I get an
On Fri, 15 Jan 2010, Nikolai Zhubr wrote:
15.01.2010 10:50, Florian Klaempfl:
What's the point of being so carefull about unreadable PPUs?
Simply because it means that something really strange happened. Maybe it
is only a wrong compiler version but it could be also a corrupted file
system
On Tue, 19 Jan 2010, Graeme Geldenhuys wrote:
Hi,
In the file rtl/unix/dynlibs.inc there is the following definition.
Type
{ using PtrInt here is compliant with the other platforms }
TLibHandle = PtrInt;
Shouldn't that rather be PtrUInt type? After
On Tue, 19 Jan 2010, Daniël Mantione wrote:
Op Tue, 19 Jan 2010, schreef Graeme Geldenhuys:
Michael Van Canneyt wrote:
Why should it be better ? It doesn't really matter anyway.
PtrUInt has a larger range than PtrInt (allowing full access to memory
address range). Plus, I don't think
On Wed, 20 Jan 2010, Michael Schnell wrote:
Do you see any problems with using the libc function defined in the RTL
libc.pp ?
You should not use it. It's linux-x86 only, and meanwhile quite outdated.
It's definitely not maintained to match the latest libc.
Michael.
On Tue, 26 Jan 2010, Graeme Geldenhuys wrote:
Hi,
Speaking of language syntax in another thread it got me thinking.
Being around FPC for a few years now I have read many messages and saw
patches regarding language extensions etc...
Then today by pure accident while searching for Modula-2
On Fri, 29 Jan 2010, Juha Manninen wrote:
Because FPC does not support semicolon before else :-)
Ok, I remembered it connects to the first IF when there is semicolon.
Apparently I remembered wrong...
It means there is no ambiguity and the patch can be applied without breaking
any code.
Or,
On Tue, 9 Feb 2010, Graeme Geldenhuys wrote:
Hi Michael,
I updated my fpcdocs repository from r625 (pre 2.4.0 release) to r634 (post
2.4.0 release), but still found a bug in documentation and missing
information related to FPC 2.4.0
1) Wrong Information:
---[ ref.tex line 1340
On Tue, 9 Feb 2010, Nikolai Zhubr wrote:
Hello people,
Apparently there is some problem with bugtracker. Yesterday I tried to create
an account, but never got a confirmation email. I then tried a lost
password feature, just in case, but got no reasult either. Mantis keeps
boycotting me
On Fri, 12 Feb 2010, Joost van der Sluis wrote:
Hi all,
See here the code from TStrings.SaveToFile:
Procedure TStrings.SaveToFile(const FileName: string);
Var TheStream : TFileStream;
begin
TheStream:=TFileStream.Create(FileName,fmCreate);
SaveToStream(TheStream);
TheStream.Free;
end
On Mon, 15 Feb 2010, Graeme Geldenhuys wrote:
Hi,
Is there a parameter or something in fpdoc that can output in the generated
help the supported interfaces of a class?
For example:
Something like the output generated by JavaDoc in the section All
Implemented Interfaces
On Mon, 15 Feb 2010, Joost van der Sluis wrote:
Hi all,
I want to add (abstract) logging functionality to TCustomApplication. I
see three options:
One:
Add a public TEventLog property to TCustomApplication. Then deratives of
TCustumApplication can return a TEventLog or a derivate of it. I
On Tue, 16 Feb 2010, Joost van der Sluis wrote:
On Tue, 2010-02-16 at 10:35 +0100, Martin Schreiber wrote:
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
On Wed, 17 Feb 2010, Michael Schnell wrote:
On 02/16/2010 05:38 PM, Joost van der Sluis wrote:
And it is because I want to have a 'global' logging system available.
But the application
has to implement it.
Of course the logging functions would need to be thread-safe !
IMHO it would be
On Wed, 17 Feb 2010, Michael Schnell wrote:
On 02/17/2010 09:37 AM, Graeme Geldenhuys wrote:
This is another issue I wanted to raise about TEventLog.
Is the name TEventLog set ?
Yes.
The name stems from the Windows 'Event Viewer' system logging facility.
The class exists since 8 years,
On Wed, 17 Feb 2010, Michael Schnell wrote:
On 02/17/2010 09:25 AM, Michael Van Canneyt wrote:
I don't see a point in an event queue, since TCustomApplication is also
meant for non-event-driven (or queueing) applications;
Of course. I only vote for a hook. If it is not used it's just
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote:
Luiz Americo Pereira Camara wrote:
The point is that the TFPColor constants are inconsistently defined.
I see your point and agree. Some colors have both high and low byte set,
some other colors do not.
@Mattias
What is the 48bit value for
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote:
Michael Van Canneyt wrote:
As defined by fpImage unit.
colMaroon : TFPColor = (Red: $8000; Green: $; Blue: $; Alpha:
alphaOpaque);
This is *incorrect*. It should be:
colMaroon : TFPColor = (Red: $8080; Green: $; Blue
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote:
Luiz Americo Pereira Camara wrote:
Assuming that, giving a color in 24bit RGB (one byte per channel) where
$00 means no color $FF full color, if a channel is on the middle ($80 =
128) it would be equivalent to $8000 in the 48bit format, right?
On Wed, 17 Feb 2010, Graeme Geldenhuys wrote:
Michael Van Canneyt wrote:
You happen choose to use the ratio as the basis of your definition.
Someone else may decide on some other definition. Who is right ?
Like I said, you must have a 48-bit definition of Maroon.
Only then you can
On Thu, 4 Mar 2010, Michael Schnell wrote:
On 03/04/2010 03:37 PM, Jonas Maebe wrote:
Add {$linklib pthread}
Great !!!
That is the solution.
I did
{$IFDEF UNIX}{$IFDEF UseCThreads}
{$linklib pthread}
{$ENDIF}{$ENDIF}
I suppose something like this should be added to the automatic
On Thu, 4 Mar 2010, Jonas Maebe wrote:
On 04 Mar 2010, at 16:18, Michael Van Canneyt wrote:
This is actually quite strange and probably a bug in the cthreads unit.
It should contain the {$linklib pthread} clause instead of loading the
pthreads library manually, that's why we have
On Wed, 10 Mar 2010, Paul Ishenin wrote:
Hello, FPC developers' list
Looking at the next topic
http://forum.lazarus.freepascal.org/index.php/topic,8436.0.html I see that
fcl-res is missing .tlb resource handling. I think it is pretty easy to add
it - just register a handler for .tlb and
On Fri, 12 Mar 2010, Paul Ishenin wrote:
Hello, FPC developers' list.
I know at the moment we have the next problems which cause subj don't work:
1. gdb does not supports borland fastcall calling convention (delphi calls it
register though)
2. fpc does not write debug info for properties
On Tue, 16 Mar 2010, Jonas Maebe wrote:
On 16 Mar 2010, at 08:44, Graeme Geldenhuys wrote:
Under Linux the following information is missing, yet this information is
displayed in the Windows version of FPC.
It's unrelated to Linux vs Windows. Those options are enabled/disabled per
On Tue, 23 Mar 2010, Graeme Geldenhuys wrote:
Marco van de Voort het geskryf:
For the same reason why the Unix rtl is not a Windows emulation. We are
writing a multiplatform compiler and rtl, not an emulation.
If only that was true... I can highlight a few places where Windows
emulation
On Thu, 25 Mar 2010, Graeme Geldenhuys wrote:
On 25 March 2010 17:32, Marco van de Voort mar...@stack.nl wrote:
2.2 doesn't seem to know out params
(yes it does, but probably only in Delphi mode)
I thought it strange too. I couldn't see a clear syntax error, and yes
I have used out
On Mon, 29 Mar 2010, Alexander Bauer wrote:
I've exact the same Problem.
It seems that the daylight saving offset is only calculated once on program
start.
Is there a method to update that ?
No. The InitLocalTime procedure is private to the implementation of the unix
unit. We can make it
On Mon, 29 Mar 2010, Carsten Bager wrote:
No. The InitLocalTime procedure is private to the implementation of the unix
unit. We can make it public, please post a bugreport for this.
Do you know if it would be nessery to call DoneLocalTime before caling
InitLocalTime.
As far as I can see
On Wed, 31 Mar 2010, Jonas Maebe wrote:
On 31 Mar 2010, at 20:01, Seth Grover wrote:
The documentation
(http://www.freepascal.org/docs-html/ref/refsu56.html) says A
constant argument is passed by reference if its size is larger than a
pointer. It is passed by value if the size is equal or
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
On 4 May 2010 10:11, Florian Klaempfl flor...@freepascal.org wrote:
Because it has no advantage over a win32 executable (it is very unlikely
that the compiler needs more than 2 or 3 GB and a native win64 compiler
is slower due to bigger memoy
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
Hi Michael,
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/docs/
The FCL documentation for the DB unit has some formatting mistakes (pdf
version of docs). In the PDF document, some code examples do not wrap, and
simply go of the edge of the page.
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 09:46, Michael Van Canneyt wrote:
Cross-compiling is OK for small mobile devices, but not for mature platforms and
daily development.
Why not?
Because of 2 reasons:
1. you can't debug properly. And with that I mean an efficient
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 10:16, Graeme Geldenhuys wrote:
Jonas Maebe het geskryf:
Cross-compiling is OK for small mobile devices, but not for mature platforms and
daily development.
Why not?
Because it doesn't always work.
I run 64-bit FPC under
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 10:44, Michael Van Canneyt wrote:
I had the same experience as Graeme. Admittedly, a couple of years ago.
I never found out why the generated binaries did not work. They simply
refused to run, and immediatly exited. (both from
On Tue, 4 May 2010, Florian Klaempfl wrote:
@Florian
I believe you develop mostly under Windows. Maybe the FPC slowness should
be resolved before Delphi releases a 64-bit compiler?
This cannot be resolved. A 64-Bit compiler has a bigger memory footprint
because FPC uses a lot of pointers
On Tue, 4 May 2010, Jonas Maebe wrote:
On 04 May 2010, at 13:56, Jonas Maebe wrote:
i386-i386 compiler compiling itself:
user0m8.180s
sys 0m0.694s
x86-64-i386 compiler compiling itself:
user0m8.096s
sys 0m0.736s
And i386-i386 compiler compiling itself (again using the
On Tue, 4 May 2010, Graeme Geldenhuys wrote:
Florian Klaempfl het geskryf:
No. It actually proves that using 32 bit executables (and installer
packages!) on 64 bit linux is a pain. On windows, we can cover with two
installers Win2k (no idea about Win98) up to Win7 regardless if 32 or 64
On Tue, 4 May 2010, Andrew Brunner wrote:
On Tue, May 4, 2010 at 10:09 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Cross-compilers can be just as multi-threaded as native ones. This is a
completely orthogonal feature.
True statement but I fear does not address the issue at hand.
The problem is in supporting the 'depecated' and other modifiers.
I have added support for that, but apparently, it breaks parsing
in other cases (the implementation is rather messy).
Please add bug reports for this, using small code samples.
Also, it is not necessary to report that the
On Fri, 14 May 2010, Mattias Gaertner wrote:
On Fri, 14 May 2010 14:33:57 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
Marco van de Voort het geskryf:
1) I would particularly be interested if there is a difference between 2.4.1
(say a week old maximally) and 2.5.1 (likewise).
On Fri, 14 May 2010, Graeme Geldenhuys wrote:
Hi,
I tried using FPC 2.5.1 today to see how compatible is our application with
it compared to FPC 2.4.1
I got stacks of the following errors. Why is this change forced in FPC
2.5.1? TBulkInvoiceRateListForm class is a descendant of
On Fri, 14 May 2010, Mattias Gaertner wrote:
On Fri, 14 May 2010 16:52:30 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On 14 May 2010 16:41, Mattias Gaertner wrote:
I can send you my 49 smaller patches. But I doubt that would help.
Personally, I would have preferred that
On Mon, 17 May 2010, Graeme Geldenhuys wrote:
Michael Van Canneyt het geskryf:
You only need var/out when you want to change the instance pointer, i.e.
switch to another instance. And I count FreeAndNil() among this. (.Free
on the other hand is still possible, but not recommended).
If you
On Wed, 19 May 2010, Luiz Americo Pereira Camara wrote:
Until a few moments ago i would say yes because it seems logical and fpc
raises an exception when trying to set the value programatically.
But while investigating why TAutoIncField.ReadOnly always returns false, i
found that,
On Wed, 19 May 2010, Marco van de Voort wrote:
In our previous episode, Graeme Geldenhuys said:
Marco van de Voort het geskryf:
I'm against. This is a sliding slope. Michael agreeing to this surprises me
a bit.
Michael was the one that suggested it to Joost and myself. :) The usage of
On Wed, 19 May 2010, Joost van der Sluis wrote:
On Wed, 2010-05-19 at 16:59 +0200, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
I don't care about such schemes being used in code that is not Delphi compat
(fpgui, fpweb etc). I wouldn't like
On Wed, 19 May 2010, Marco van de Voort wrote:
While that solves at least the worst compatibility issues. I still think it
is a weak and redundant attempt.
If the current situation is so horribly dire that you can't really do
without it, such a bandaid is not enough.
IMHO this is some not
On Wed, 19 May 2010, Marco van de Voort wrote:
In our previous episode, Vincent Snijders said:
@Michael van Canneyt
Have we come to a decision about Observer support in FPC base classes?
This would obviously help what I am doing now as well - but I guess
something like that will not make
On Thu, 20 May 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
the state of the object) and also keeps no state (the list is also in
Observable)
Observable and Observer go hand in hand. We're talking about both.
Specifically, I want to add observable
In our previous episode, Michael Van Canneyt said:
It's not because you don't see a need, that others don't have it;
there is no point in discussing that, we will never agree on that.
Just like I don't discuss religion with people.
Well, there's your precedent problem, right there. Those
On Thu, 20 May 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Observable and Observer go hand in hand. We're talking about both.
Specifically, I want to add observable to TPersistent.
People having object frameworks based on that class will really thank
On Thu, 20 May 2010, Helmut Hartl wrote:
Am 20.05.10 10:29, schrieb Graeme Geldenhuys:
Joost van der Sluis het geskryf:
1) Ignore Marco and implement it any way. I think you have just as
much say as Macro on what goes into the FPC.
thread yet. But here you are going too far. Way too far.
On Thu, 20 May 2010, Jonas Maebe wrote:
On 20 May 2010, at 10:46, Helmut Hartl wrote:
But fundamential changes in an stability release ?
All changes are always committed first to trunk. It is indeed unlikely that a
change like the one under discussion currently, if performed, would
On Thu, 20 May 2010, Florian Klaempfl wrote:
michael.vancann...@wisa.be schrieb:
I need a solution that works with current GUI, current libraries and
whatnot. What you propose is re-doing the work of 10 years, which is
obviously not feasable.
Can you give a real world example what you
On Thu, 20 May 2010, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Thu, 20 May 2010, Florian Klaempfl wrote:
michael.vancann...@wisa.be schrieb:
I need a solution that works with current GUI, current libraries and
whatnot. What you propose is re-doing the work of 10 years
On Wed, 2 Jun 2010, Graeme Geldenhuys wrote:
Hi Michael,
Any idea when you'll get around to committing that Observer code? At
the moment I'm using my own observer implementation (based on old code
you sent me months ago) for a few new fpGUI features. I've created an
experimental branch in
On Thu, 10 Jun 2010, Adem wrote:
On 2010-06-10 00:11, German Gentile wrote:
2010/6/9 Adem listmem...@letterboxes.org
mailto:listmem...@letterboxes.org
So, what I am getting at is this: Is there such a list/platform
where only architectural/design issues (no commit details, no
On Thu, 10 Jun 2010, Graeme Geldenhuys wrote:
Op 2010-06-10 13:45, Vincent Snijders het geskryf:
I think it would be better to revert it and apply the changes from r14005, so
that
it can be merged more easily.
Can I simply change the 'lEquals' to 'aequals' in a new commit, or must one
do
On Thu, 10 Jun 2010, Jonas Maebe wrote:
What is the coding standards in FPC?
In general: http://wiki.freepascal.org/Coding_style
As you'll notice, many things are not defined, such as identifier naming.
There are no fixed rules for those things, but it is recommended to keep
things
901 - 1000 of 2514 matches
Mail list logo
