In our previous episode, LacaK said:
> > Policy wise, I merge revisions for utils, packages and the higher level
> > units of RTL like sysutils and classes if they are a couple of weeks old
> > (3-4 weeks), but I usually leave big changes a bit longer.
> >
> ok it is answer to my question ;-)
>
Policy wise, I merge revisions for utils, packages and the higher level
units of RTL like sysutils and classes if they are a couple of weeks old
(3-4 weeks), but I usually leave big changes a bit longer.
ok it is answer to my question ;-)
So we can expect backporting after approx. month
S
In our previous episode, LacaK said:
> >> explicitly asked by sb ?
> >
> > Trivial bugfixes especially in the RTL or packages are often
> > backported (though we now have the additional difference in the
> > buildsystem).
> Yes I am here speaking mostly about packages.
> And when happens this bac
Sven Barth wrote / napísal(a):
Am 03.05.2012 08:39, schrieb LacaK:
Hi,
I have question indirectly related to this subject ;-)
If there are fixed some bugs in trunk (2.7.1 now) can we expect that
they will be backported in some of next stable release 2.6 (2.6.2,
2.6.3)?
If yes , are there any r
Am 03.05.2012 08:39, schrieb LacaK:
Hi,
I have question indirectly related to this subject ;-)
If there are fixed some bugs in trunk (2.7.1 now) can we expect that
they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)?
If yes , are there any rules which bugs are / can be / wil
Hi,
I have question indirectly related to this subject ;-)
If there are fixed some bugs in trunk (2.7.1 now) can we expect that
they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)?
If yes , are there any rules which bugs are / can be / will be backported ?
(Now I am not spe
Paul Ishenin schrieb:
02.05.12 18:18, Graeme Geldenhuys wrote:
So instead of jumping around with various delphi versions (a bit of D7
and a bit of 2009 etc), maybe start from the oldest delphi version
(eg: D7) and move towards the newest?
Maybe you can teach us how to do this by sending appro
Tomas Hajny schrieb:
On Wed, May 2, 2012 12:27, Hans-Peter Diettrich wrote:
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
The solution is so easy: don't mark it as deprecated.
I also have a clear opinion about Delphi compatibility: Every FPC
version must be c
On 2 May 2012 15:59, Paul Ishenin wrote:
> ...
> Details about these new features can be found at
> http://wiki.freepascal.org/FPC_New_Features_2.6.0
Thanks Paul. I didn't know (or forgot) about these links. This would
be helpful in creating a wiki matrix page of FPC vs Delphi features.
If I get
On Wed, May 2, 2012 at 11:47 AM, Martin Schreiber wrote:
> On 02.05.2012 15:41, Marcos Douglas wrote:
>>
>>> This last one is bad advice, this code will break as soon as they switch to
>>> 2.6.3. Which, presumably, eventually they will.
>>>
>>> If you really want to avoid the messages, it is bette
On 02.05.2012 10:47, michael.vancann...@wisa.be wrote:
>
>
> Or you can simply ignore the warnings, which is by far the easiest
> option.
> I can't believe people are making such fuss over a couple of warnings.
>
MSEide+MSEgui compiles without FPC warnings and notes. I assume other
FPC users also m
On 02.05.2012 15:41, Marcos Douglas wrote:
>
>> This last one is bad advice, this code will break as soon as they switch to
>> 2.6.3. Which, presumably, eventually they will.
>>
>> If you really want to avoid the messages, it is better to use TBookmark,
>> GetBookmarkData and FreeBookmark.
>> That
02.05.12 21:32, Graeme Geldenhuys wrote:
Maybe the FPC core team will be so kind as to create a new "FPC
features since xxx" page on the wiki (similar to what I have done for
Lazarus).
From the anouncement of FPC 2.6.0 which was posted to this mail list:
Changes that may break backwards compa
On Wed, May 2, 2012 at 5:47 AM, wrote:
>
>
> On Wed, 2 May 2012, Martin Schreiber wrote:
>
>> On 01.05.2012 17:37, Michael Van Canneyt wrote:
As written before, in MSEgui I'll define a "bookmarkty" type, so
MSEgui users
have "bookmarkty" in order to avoid the warning. FPC and
On 2 May 2012 13:55, Mattias Gaertner wrote:
>
> Please don't feed the trolls.
By no means did I mean to troll. It was a legit statement, and
something that confuses the hell out of FPC developers like myself.
For example: tiOPF branched off version 3 so as to support Delph
2009+ support inclu
On Wed, May 2, 2012 12:27, Hans-Peter Diettrich wrote:
> Marco van de Voort schrieb:
>> In our previous episode, Hans-Peter Diettrich said:
>>> The solution is so easy: don't mark it as deprecated.
>>>
>>> I also have a clear opinion about Delphi compatibility: Every FPC
>>> version must be compati
On Wed, 02 May 2012 18:49:13 +0800
Paul Ishenin wrote:
> 02.05.12 18:18, Graeme Geldenhuys wrote:
>
> > So instead of jumping around with various delphi versions (a bit of D7
> > and a bit of 2009 etc), maybe start from the oldest delphi version
> > (eg: D7) and move towards the newest?
>
> May
02.05.12 18:18, Graeme Geldenhuys wrote:
So instead of jumping around with various delphi versions (a bit of D7
and a bit of 2009 etc), maybe start from the oldest delphi version
(eg: D7) and move towards the newest?
Maybe you can teach us how to do this by sending appropriate patches? We
wil
On 2 May 2012 09:00, Hans-Peter Diettrich wrote:
> To the user this means "not compatible with D7 nor D2009" :-[
+1000
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
On 1 May 2012 23:48, Hans-Peter Diettrich wrote:
> Simply specify the Delphi version, to which FPC 2.6.1 should be compatible,
> then the rest is clear.
In a way I agree here... It is damn confusing when just saying "delphi
compatible". Delphi is NOT a product that is standing still any more,
so
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
The solution is so easy: don't mark it as deprecated.
I also have a clear opinion about Delphi compatibility: Every FPC
version must be compatible to a Delphi version. A mix of incompatible
features from different D
On 02.05.2012 10:47, michael.vancann...@wisa.be wrote:
>> For users who do not want to see the "deprecated" warnings in
>> fixes_2_6 do
>>
>> In MSEide+MSEgui:
>>
>> Use "bookmarkty" instead of "TBookmarkStr" for bookmark variables.
>>
>> In Lazarus:
>>
>> Use "string" instead of "TBookmarkStr" fo
On Wed, 2 May 2012, Martin Schreiber wrote:
On 01.05.2012 17:37, Michael Van Canneyt wrote:
As written before, in MSEgui I'll define a "bookmarkty" type, so
MSEgui users
have "bookmarkty" in order to avoid the warning. FPC and Lazarus
probably
can't do the same because of Delphi compatibility
On 01.05.2012 17:37, Michael Van Canneyt wrote:
>> As written before, in MSEgui I'll define a "bookmarkty" type, so
>> MSEgui users
>> have "bookmarkty" in order to avoid the warning. FPC and Lazarus
>> probably
>> can't do the same because of Delphi compatibility. Suggestion:
>> remove "deprecate
In our previous episode, Hans-Peter Diettrich said:
> The solution is so easy: don't mark it as deprecated.
>
> I also have a clear opinion about Delphi compatibility: Every FPC
> version must be compatible to a Delphi version. A mix of incompatible
> features from different Delphi versions is use
02.05.2012 15:00, Hans-Peter Diettrich wrote:
To the user this means "not compatible with D7 nor D2009" :-[
It is both compatible with D7 and some D2009 features.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, 2 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Simply specify the Delphi version, to which FPC 2.6.1 should be
compatible, then the rest is clear.
There is no such version.
2.6.1 is in many ways D7 compatible, but also has a lot of D20O9 compatible
features.
Michael Van Canneyt schrieb:
Simply specify the Delphi version, to which FPC 2.6.1 should be
compatible, then the rest is clear.
There is no such version.
2.6.1 is in many ways D7 compatible, but also has a lot of D20O9
compatible features.
I wonder what "in many ways" here means?
To the
Il 01/05/2012 22:05, Sven Barth ha scritto:
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real
On 01.05.2012 20:17, Mattias Gaertner wrote:
On Tue, 01 May 2012 15:05:57 +0200
Sven Barth wrote:
[...]
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|off|error)}
* on: MSGID will be e
On 01.05.2012 22:03, Sven Barth wrote:
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of h
On 01.05.2012 20:15, Giuliano Colla wrote:
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Ma
On Tue, 01 May 2012 15:05:57 +0200
Sven Barth wrote:
>[...]
> You can locally disable warnings by using the $warn directive (not
> documented yet it seems, but available in 2.6.0).
>
> It looks like this:
>
> {$warn MSGID (on|off|error)}
>
> * on: MSGID will be emitted as a warning
> * off: M
Il 01/05/2012 17:08, Michael Van Canneyt ha scritto:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As al
On 1 May 2012 12:11, Martin Schreiber wrote:
> Thanks Graeme, I wanted to write something similar but do not dare.
I always speak my mind (here and in my personal life) - no point in
beating around the bush. This might offend some sensitive readers, but
I get my point across as I see it.
--
R
On Tuesday, 1 May 2012, Michael Van Canneyt wrote:.
>
> On Tue, 1 May 2012, Graeme Geldenhuys wrote:
> As I said, the matter is under discussion on Core. Discussions take time.
> Marco's and my mail just crossed, that's all.
I simply wanted to highlight the fact that those emails gave contradic
On Tue, May 1, 2012 at 12:23 PM, Martin Schreiber wrote:
> On Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote:
>> On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
>> > Michael Van Canneyt schrieb:
>> >> Well, then they'll have to live with the warning.
>> >>
>> >> And this is the point of ha
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote:
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first pla
On Tuesday 01 May 2012 17:08:55 Michael Van Canneyt wrote:
> On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
> > Michael Van Canneyt schrieb:
> >> Well, then they'll have to live with the warning.
> >>
> >> And this is the point of having the warning in the first place. Make
> >> people aware of a
On Tue, May 1, 2012 at 12:08 PM, Michael Van Canneyt
wrote:
>
>
> On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
>
>> Michael Van Canneyt schrieb:
>>
>>> Well, then they'll have to live with the warning.
>>>
>>> And this is the point of having the warning in the first place. Make
>>> people aware
On Tue, 1 May 2012, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make people
aware of a coming change.
As already mentioned in this thread, a mere hint about "may
On Tuesday 01 May 2012 17:42:51 Hans-Peter Diettrich wrote:
> Michael Van Canneyt schrieb:
> > Well, then they'll have to live with the warning.
> >
> > And this is the point of having the warning in the first place. Make
> > people aware of a coming change.
>
> As already mentioned in this thread,
Michael Van Canneyt schrieb:
Well, then they'll have to live with the warning.
And this is the point of having the warning in the first place. Make
people aware of a coming change.
As already mentioned in this thread, a mere hint about "may change
somehow, in the next version" is of no real
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
What do you suggest to avoid the warning?
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on
On 01.05.2012 15:19, Martin Schreiber wrote:
On Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
What do you suggest to avoid the warning?
You can locally disable warnings by using the $warn directive (not
documented yet it seems, but available in 2.6.0).
It looks like this:
{$warn MSGID (on|o
On Tuesday 01 May 2012 15:05:57 Sven Barth wrote:
> > What do you suggest to avoid the warning?
>
> You can locally disable warnings by using the $warn directive (not
> documented yet it seems, but available in 2.6.0).
>
> It looks like this:
>
> {$warn MSGID (on|off|error)}
>
Thanks, but I think t
On 01.05.2012 13:57, Martin Schreiber wrote:
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is no
On Tuesday 01 May 2012 14:48:48 Michael Van Canneyt wrote:
> On Tue, 1 May 2012, Martin Schreiber wrote:
> > On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
> >> On 01.05.2012 13:50, Martin Schreiber wrote:
> Anyway, the change is undone, we're back on TBookmarkStr.
> TBookMarkStr is no
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 12:51:39 Michael Van Canneyt wrote:
As I wrote to Graeme:
These things take time, and you should allow for this.
Remember, FPC is a hobby project for the core team.
I have currently 2 paying jobs to make ends meet,
but do tr
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is
On Tuesday 01 May 2012 13:50:49 Sven Barth wrote:
> On 01.05.2012 13:50, Martin Schreiber wrote:
> >> Anyway, the change is undone, we're back on TBookmarkStr.
> >> TBookMarkStr is now marked deprecated. Revision 21155.
> >
> > Thank you very much. That means it is not possible to work with fixes_2
On 01.05.2012 13:50, Martin Schreiber wrote:
Anyway, the change is undone, we're back on TBookmarkStr.
TBookMarkStr is now marked deprecated. Revision 21155.
Thank you very much. That means it is not possible to work with fixes_2_6
without "deprecated" warnings? TDataset.Bookmark is of type TBo
On Tuesday 01 May 2012 12:51:39 Michael Van Canneyt wrote:
>
> As I wrote to Graeme:
> These things take time, and you should allow for this.
>
> Remember, FPC is a hobby project for the core team.
> I have currently 2 paying jobs to make ends meet,
> but do try to squeeze in as much FPC as I possi
On Tue, 1 May 2012, Martin Schreiber wrote:
On Tuesday 01 May 2012 11:52:07 Graeme Geldenhuys wrote:
On 30 April 2012 14:22, Marco van de Voort wrote:
What is the decision of FPC-core?
Still the same. I'm waiting till it is suffiently tested to merge it
back.
OK, am I understanding this
On Tuesday 01 May 2012 11:52:07 Graeme Geldenhuys wrote:
> On 30 April 2012 14:22, Marco van de Voort wrote:
> >> What is the decision of FPC-core?
> >
> > Still the same. I'm waiting till it is suffiently tested to merge it
> > back.
>
> OK, am I understanding this correctly. One core member, Mic
On Tue, 1 May 2012, Graeme Geldenhuys wrote:
On 30 April 2012 14:22, Marco van de Voort wrote:
What is the decision of FPC-core?
Still the same. I'm waiting till it is suffiently tested to merge it back.
OK, am I understanding this correctly. One core member, Michael, say
there is no d
On 30 April 2012 14:22, Marco van de Voort wrote:
>>
>> What is the decision of FPC-core?
>
> Still the same. I'm waiting till it is suffiently tested to merge it back.
OK, am I understanding this correctly. One core member, Michael, say
there is no decision yet (revert or keep). Then another co
In our previous episode, Martin Schreiber said:
> > > >
> > > > What about 2.6.1, will change in a few days too?
> > >
> > > When it is sufficiently tested or when I give up waiting. (typically 6-8
> > > weeks).
> >
> > I strongly recommend to revert the type of TDataSet.Bookmark to
> > TBookmarkSt
In our previous episode, Alexander Klenin said:
> On Fri, Apr 27, 2012 at 20:28, Marco van de Voort wrote:
> > Calling a virtual(!) method when a bookmark is no longer needed allows to do
> > other things too, like releasing something with db handles, and allows
> > descendents of TDataset to do s
On Mon, 30 Apr 2012, Martin Schreiber wrote:
On Monday 30 April 2012 13:40:43 Marcos Douglas wrote:
I strongly recommend to revert the type of TDataSet.Bookmark to
TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of
TDataSet.Bookmark = tbytes in FPC 2.7.1 only.
What is the decisio
On Monday 30 April 2012 13:40:43 Marcos Douglas wrote:
> >> I strongly recommend to revert the type of TDataSet.Bookmark to
> >> TBookmarkStr in FPC 2.6.1 (fixes_2_6) and to change type of
> >> TDataSet.Bookmark = tbytes in FPC 2.7.1 only.
> >
> > What is the decision of FPC-core?
>
> I think is
On Mon, Apr 30, 2012 at 1:56 AM, Martin Schreiber wrote:
> On Thursday 26 April 2012 06:58:01 Martin Schreiber wrote:
>> On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote:
>> > In our previous episode, Marcos Douglas said:
>> > > > Done, trunk r21037. Affected were tdataset and bufdatas
On Thursday 26 April 2012 06:58:01 Martin Schreiber wrote:
> On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote:
> > In our previous episode, Marcos Douglas said:
> > > > Done, trunk r21037. Affected were tdataset and bufdataset (conversion
> > > > between Pbufbookmark and tbytes).
> > >
On Fri, Apr 27, 2012 at 20:28, Marco van de Voort wrote:
> Calling a virtual(!) method when a bookmark is no longer needed allows to do
> other things too, like releasing something with db handles, and allows
> descendents of TDataset to do such things.
Did you consider declaring TBookmark an int
On 4/27/2012 03:45, Ivan Bobyr wrote:
PS:
If the main advantage of FPC over C/C++ is its automatic memory management then
we should obviously use it, correct ?
FWIW and as late to the conversation as it is, i must add that it isn't memory
management that's the big plus for pascal languages...
On Thu, Apr 26, 2012 at 5:35 AM, Graeme Geldenhuys
wrote:
> On 26 April 2012 06:58, Martin Schreiber wrote:
>>
>> I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr
>> in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in
>> FPC 2.7.1 only.
>
>
>
On Friday 27 April 2012 11:33:50 Jonas Maebe wrote:
> marcov wrote on Fri, 27 Apr 2012:
> > In our previous episode, Ivan Bobyr said:
> >> But it's difficult to object to the below Martin's statement:
> >> --
> >> Please change TDataset.Bookmark to tbytes = array of byte if you
> >>
marcov wrote on Fri, 27 Apr 2012:
In our previous episode, Ivan Bobyr said:
But it's difficult to object to the below Martin's statement:
--
Please change TDataset.Bookmark to tbytes = array of byte if you absolutely
need to change it in fixes_2_6 so we have a bookmark type wit
In our previous episode, Ivan Bobyr said:
> But it's difficult to object to the below Martin's statement:
> --
> Please change TDataset.Bookmark to tbytes = array of byte if you absolutely
> need to change it in fixes_2_6 so we have a bookmark type with automatic
> memory management
But it's difficult to object to the below Martin's statement:
--
Please change TDataset.Bookmark to tbytes = array of byte if you absolutely
need to change it in fixes_2_6 so we have a bookmark type with automatic
memory management again.
PS:
If the main advantage of FPC over C/C
On 26 April 2012 06:58, Martin Schreiber wrote:
>
> I strongly recommend to revert the type of TDataSet.Bookmark to TBookmarkStr
> in FPC 2.6.1 (fixes_2_6) and to change type of TDataSet.Bookmark = tbytes in
> FPC 2.7.1 only.
Macro wants feedback, well here is some... I fully agree with Martin.
On Wednesday 25 April 2012 21:43:30 Marco van de Voort wrote:
> In our previous episode, Marcos Douglas said:
> > > Done, trunk r21037. Affected were tdataset and bufdataset (conversion
> > > between Pbufbookmark and tbytes).
> >
> > What about 2.6.1, will change in a few days too?
>
> When it is s
In our previous episode, Marcos Douglas said:
> > Done, trunk r21037. Affected were tdataset and bufdataset (conversion
> > between Pbufbookmark and tbytes).
>
> What about 2.6.1, will change in a few days too?
When it is sufficiently tested or when I give up waiting. (typically 6-8
weeks).
_
On Wed, Apr 25, 2012 at 1:52 PM, Marco van de Voort wrote:
> In our previous episode, Marco van de Voort said:
>> > If creating the patch is the issue, I'm volunteering ;)
>>
>> You can do it, if not, I will in the coming days.
>
> Done, trunk r21037. Affected were tdataset and bufdataset (convers
In our previous episode, Marco van de Voort said:
> > If creating the patch is the issue, I'm volunteering ;)
>
> You can do it, if not, I will in the coming days.
Done, trunk r21037. Affected were tdataset and bufdataset (conversion
between Pbufbookmark and tbytes).
_
Jonas Maebe schrieb:
Graeme Geldenhuys wrote on Wed, 25 Apr 2012:
On 25 April 2012 11:08, Ludo Brands wrote:
I understand. Just wanted to clarify that, to my knowledge, all 3rd
party
dataset descendants and some other programs using bookmarks are
affected by
a change that wanted to minim
On Wed, 25 Apr 2012, Marco van de Voort wrote:
In our previous episode, Ludo Brands said:
that is increasingly happening, with the first D7 supports
disappearing)
The underlying problem is that the Delphi Tbookmark definition migrated from
the simple record tag to something that holds (or c
In our previous episode, Ludo Brands said:
> > that is increasingly happening, with the first D7 supports
> > disappearing)
> >
> The underlying problem is that the Delphi Tbookmark definition migrated from
> the simple record tag to something that holds (or can hold) the state of the
> record.
> Yes, for instance if there are external resources like
> cursors or locks coupled to it, and it is not just a matter
> of freeing that single block of memory.
>
...
> Afaik the assumption that it is /modeled/ as managed is
> simply wrong. It is currently modeled as NOT managed, it is
> just
In our previous episode, Graeme Geldenhuys said:
> Ah yes, the core developers live by different rules to all of use.
Graeme, please stick to the topic, and leave your perceived project
management whining out of it.
If you want to avoid these kind of issues, I encourage you to step up your
trunk
In our previous episode, Ludo Brands said:
> > They mostly track 2.7.1 also, so then it should be just a
> > matter of enabling the right override for 2.6.x too (which is
> > what I had in mind)
>
> I understand. Just wanted to clarify that, to my knowledge, all 3rd party
> dataset descendants
On 25 April 2012 13:10, Jonas Maebe wrote:
>
> That's not entirely correct.
Ah yes, the core developers live by different rules to all of use.
> features or important bug fixes that may break backwards compatibility can
> also be merged under certain circumstances.
Strange then that in the las
Graeme Geldenhuys wrote on Wed, 25 Apr 2012:
On 25 April 2012 11:08, Ludo Brands wrote:
I understand. Just wanted to clarify that, to my knowledge, all 3rd party
dataset descendants and some other programs using bookmarks are affected by
a change that wanted to minimize compatibility problem
On 25 April 2012 11:08, Ludo Brands wrote:
>
> I understand. Just wanted to clarify that, to my knowledge, all 3rd party
> dataset descendants and some other programs using bookmarks are affected by
> a change that wanted to minimize compatibility problems.
Indeed, and it now has the total oppos
> > It broke also lazarus, MDO, rxmemds.
>
> They mostly track 2.7.1 also, so then it should be just a
> matter of enabling the right override for 2.6.x too (which is
> what I had in mind)
>
I understand. Just wanted to clarify that, to my knowledge, all 3rd party
dataset descendants and some o
In our previous episode, Ludo Brands said:
> It broke also lazarus, MDO, rxmemds.
They mostly track 2.7.1 also, so then it should be just a matter of enabling
the right override for 2.6.x too (which is what I had in mind)
> > I first changed it to tbytes (as it is in D2009+), but got
> > some
> -Message d'origine-
> De : fpc-devel-boun...@lists.freepascal.org
> [mailto:fpc-devel-boun...@lists.freepascal.org] De la part de
> Marco van de Voort
> Envoyé : mardi 24 avril 2012 23:13
> À : FPC developers' list
> Objet : Re: [fpc-devel] Breaking cha
On Tuesday 24 April 2012 23:13:26 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6
> > breaks FPC 2.6.0 compatible code. Is this intended?
>
> Yes. It should not break proper code (since that would
On Tue, Apr 24, 2012 at 6:18 PM, Marco van de Voort wrote:
> In our previous episode, Marcos Douglas said:
>> > every assignment of TDataset.Bookmark to a variable.
>> > As intended too?
>>
>> This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7
>> in attachment for somebody want)
In our previous episode, Vincent Snijders said:
> >> FPC 2.6.0 compatible code. Is this intended?
> >> TBookmark is defined as "Pointer" which has no automatic memory management
> >> so
> >> probably TDataset.FreeBookmark() must be called in a try finally block for
> >> every assignment of TDatase
In our previous episode, Marcos Douglas said:
> > every assignment of TDataset.Bookmark to a variable.
> > As intended too?
>
> This broke the ZEOS 6.6.6-stable and 7.0.0-alpha too (patch to zeos 7
> in attachment for somebody want).
zeoslib_testing (7 trunk) has a "have_tbookmark" define to hand
In our previous episode, Martin Schreiber said:
> Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks
> FPC 2.6.0 compatible code. Is this intended?
Yes. It should not break proper code (since that would already treat it as
abstract type and call freebookmark).
> TBookm
Op 24 april 2012 21:16 heeft Marcos Douglas het
volgende geschreven:
> On Tue, Apr 24, 2012 at 3:56 PM, Martin Schreiber wrote:
>> Hi,
>> Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks
>> FPC 2.6.0 compatible code. Is this intended?
>> TBookmark is defined as "Point
On Tue, Apr 24, 2012 at 3:56 PM, Martin Schreiber wrote:
> Hi,
> Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks
> FPC 2.6.0 compatible code. Is this intended?
> TBookmark is defined as "Pointer" which has no automatic memory management so
> probably TDataset.FreeBook
Hi,
Changing TDataset.Bookmark from TBookmarkStr to TBookmark in fixes_2_6 breaks
FPC 2.6.0 compatible code. Is this intended?
TBookmark is defined as "Pointer" which has no automatic memory management so
probably TDataset.FreeBookmark() must be called in a try finally block for
every assignment
97 matches
Mail list logo
