If you have not seen it, users of Delphi XE2 may be interested to read
Delphi Product Manager JT's blog about what Embarcadero are working on
for native Android and iOS development (which won't be in the
forthcoming XE3 release - it's all further ahead than that), dropping
FPC in favour of anot
On Tue, Aug 21, 2012 at 1:01 PM, Howard Page-Clark wrote:
> dropping FPC in favour of
> another open source toolchain and their own new debugger, revamped
> FireMonkey etc.
Why do you say "another open source"? I haven't seen anything saying
that the new toolchain is open source. And I don't know
On 08/21/2012 01:01 PM, Howard Page-Clark wrote:
http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/
Besides, technically, I read that Objects will become reference counting
and thus ".Free" gets obsolete (like in Prism).
-Michael
--
___
Am 22.08.2012 11:18, schrieb Felipe Monteiro de Carvalho:
On Tue, Aug 21, 2012 at 1:01 PM, Howard Page-Clark wrote:
dropping FPC in favour of
another open source toolchain and their own new debugger, revamped
FireMonkey etc.
Why do you say "another open source"? I haven't seen anything saying
On 08/22/2012 11:44 AM, Sven Barth wrote:
They plan to use LLVM (though this is not mentioned in that roadmap
article).
Regarding the multiple request I read in the past in the FPC forums to
move FPC to use a "standard" backend (such as LLVM), this seems like a
rather logical move (also reg
On Wed, Aug 22, 2012 at 11:44 AM, Sven Barth
wrote:
> They plan to use LLVM (though this is not mentioned in that roadmap
> article).
I wonder if this means that the resulting compiler will be open
source. I don't know anything about the licensing of LLVM, but they
could require front-ends to be
Den 22-08-2012 12:32, Felipe Monteiro de Carvalho skrev:
On Wed, Aug 22, 2012 at 11:44 AM, Sven Barth
wrote:
They plan to use LLVM (though this is not mentioned in that roadmap
article).
I wonder if this means that the resulting compiler will be open
source. I don't know anything about the lic
Am 22.08.2012 12:32, schrieb Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 11:44 AM, Sven Barth
wrote:
They plan to use LLVM (though this is not mentioned in that roadmap
article).
I wonder if this means that the resulting compiler will be open
source. I don't know anything about the l
Am 22.08.2012 12:08, schrieb Michael Schnell:
On 08/22/2012 11:44 AM, Sven Barth wrote:
They plan to use LLVM (though this is not mentioned in that roadmap
article).
Regarding the multiple request I read in the past in the FPC forums to
move FPC to use a "standard" backend (such as LLVM), thi
On 08/22/2012 02:39 PM, Sven Barth wrote:
Free Pascal will never move solely to a backend like LLVM.
That is what I learned in the forum already long ago :). I did not
intend advocate LLVM over the current Pascal based backend, but I wanted
to state that it seems like a logical move for Emba
Sorry for a newbie question, but how is FPC connected to gcc anyways?
Doesn't it translate the (object) pascal code directly into the
various machine languages for the different platforms (Or into
assembler and then machine language)? Pascal, only needs a one-pass
compiler, making it by nature much
On Wed, Aug 22, 2012 at 3:41 PM, Chavoux Luyt wrote:
> Sorry for a newbie question, but how is FPC connected to gcc anyways?
It is not.
> Doesn't it translate the (object) pascal code directly into the
> various machine languages for the different platforms (Or into
> assembler and then machine
context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Delphi-post-XE3-roadmap-tp4025806p4025862.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.
On 21 August 2012 12:01, Howard Page-Clark wrote:
> If you have not seen it, users of Delphi XE2 may be interested to read
And the big news is that the soon to be launched XE3 will not ship
with FireMonkey or FPC or any iOS development tools for that matter.
Wow, I can see quite a few ISV's (eg T
Am 22.08.2012 19:09, schrieb Graeme Geldenhuys:
On 21 August 2012 12:01, Howard Page-Clark wrote:
If you have not seen it, users of Delphi XE2 may be interested to read
And the big news is that the soon to be launched XE3 will not ship
with FireMonkey or FPC or any iOS development tools for t
Den 22-08-2012 19:09, Graeme Geldenhuys skrev:
On 21 August 2012 12:01, Howard Page-Clark wrote:
If you have not seen it, users of Delphi XE2 may be interested to read
And the big news is that the soon to be launched XE3 will not ship
with FireMonkey or FPC or any iOS development tools for tha
Am 23.08.2012 09:50, schrieb Anders E. Andersen:
Den 22-08-2012 19:09, Graeme Geldenhuys skrev:
On 21 August 2012 12:01, Howard Page-Clark wrote:
If you have not seen it, users of Delphi XE2 may be interested to read
And the big news is that the soon to be launched XE3 will not ship
with Fire
Den 23-08-2012 10:37, Sven Barth skrev:
Where is your source for this? The blogs on the Embarcadero website puts
a lot of emphasis on the firemonkey components and as far as I have read
the framework will ship for both Windows and OSX from the get go. The
mobile platforms will be added at a later
Many big companies do things like that! E.g: Enter on Microsoft Website,
they will promote Windows 7 until Windows 8 be finally released...
2012/8/23 Anders E. Andersen
> Den 22-08-2012 19:09, Graeme Geldenhuys skrev:
>
> On 21 August 2012 12:01, Howard Page-Clark wrote:
>>
>>> If you have not
On Wed, Aug 22, 2012 at 11:44:14AM +0200, Michael Schnell wrote:
> On 08/21/2012 01:01 PM, Howard Page-Clark wrote:
> >
> > http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/
> >
> Besides, technically, I read that Objects will become reference counting
> and thus ".Free" gets o
On Wed, Aug 22, 2012 at 06:09:00PM +0100, Graeme Geldenhuys wrote:
> On 21 August 2012 12:01, Howard Page-Clark wrote:
> > If you have not seen it, users of Delphi XE2 may be interested to read
>
> And the big news is that the soon to be launched XE3 will not ship
> with FireMonkey or FPC or any
On Thu, Aug 23, 2012 at 11:50:08AM +0200, Anders E. Andersen wrote:
> >
> >
> > This "they will be added at a later date" is exactly the point. They
> > release a product as the successor to XE2 and leave those people in
> > the rain that already built upon the mobile components provided by XE2.
On 24/08/12 21:38, Marco van de Voort wrote:
And the TUFKAM(*) option is a skin, not native, and thus not marketstorable.
I don't think the skinning is a big deal at all. Especially if you
consider that Microsoft itself created a "metro skin" for their flagship
product - Microsoft Office. Yes
On Sat, Aug 25, 2012 at 02:38:23AM +0100, Graeme Geldenhuys wrote:
> On 24/08/12 21:38, Marco van de Voort wrote:
> > And the TUFKAM(*) option is a skin, not native, and thus not marketstorable.
>
> I don't think the skinning is a big deal at all. Especially if you
> consider that Microsoft itsel
On 26/08/12 20:23, Marco van de Voort wrote:
Then you will also see that your Office counterexample is irrelevant,
If skinning is good enough for Microsoft itself, then it must be good
enough for many other ISV's too. After all, they are just following
Microsoft's example. But to get back to
On Sun, Aug 26, 2012 at 9:23 PM, Marco van de Voort wrote:
> Then you will also see that your Office counterexample is irrelevant, since
> app store rules don't apply to Office. (but they do to nearly everybody
> else).
I am not aware of any app store rule that says that people need to use
native
On 08/24/2012 10:36 PM, Marco van de Voort wrote:
I read that as that there will be ref counted objects, not that all
objects will be ref counted per se. --
Ok, but if there are reef-counted objects what is the point in not using
them ?
-Michael
--
__
On Mon, 27 Aug 2012, Michael Schnell wrote:
On 08/24/2012 10:36 PM, Marco van de Voort wrote:
I read that as that there will be ref counted objects, not that all objects
will be ref counted per se. --
Ok, but if there are reef-counted objects what is the point in not using them
Because yo
On 08/27/2012 03:36 PM, michael.vancann...@wisa.be wrote:
So for all those people shouting for a new string type: be warned that
there
may be a lot of side effects...
This is very obvious. The problem is that as soon Unicode is introduced
there are side effects even if Unicode is implemented
Am 27.08.2012 15:15, schrieb Michael Schnell:
On 08/24/2012 10:36 PM, Marco van de Voort wrote:
I read that as that there will be ref counted objects, not that all
objects will be ref counted per se. --
Ok, but if there are reef-counted objects what is the point in not using
them ?
I would n
On Fri, Aug 24, 2012 at 10:36 PM, Marco van de Voort wrote:
>> Besides, technically, I read that Objects will become reference counting
>> and thus ".Free" gets obsolete (like in Prism).
>
> I read that as that there will be ref counted objects, not that all objects
> will be ref counted per se.
On 08/28/2012 11:59 AM, Michael Fuchs wrote:
Ok, but if there are reef-counted objects what is the point in not using
them ?
I would not use them, because of my experiences with the garbage
collector of .NET. After using it, I know that I should decide when a
object has to be destroyed.
2012/8/27 Michael Schnell :
> On 08/24/2012 10:36 PM, Marco van de Voort wrote:
>>
>> I read that as that there will be ref counted objects, not that all
>> objects will be ref counted per se. --
>
>
> Ok, but if there are reef-counted objects what is the point in not using
> them ?
consider for e
Am 28.08.2012 12:13, schrieb Michael Schnell:
>>> Ok, but if there are reef-counted objects what is the point in not
>>> using them ?
>>
>> I would not use them, because of my experiences with the garbage
>> collector of .NET. After using it, I know that I should decide when a
>> object has to b
On 08/28/2012 12:48 PM, Michael Fuchs wrote:
It is not a problem that is caused every time. But I prefer objects
which I destroy by myself, not by some magic.
I see.:-)
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
h
On 08/28/2012 12:47 PM, Bernd wrote:
If such behavior were suddenly the norm for *all* objects (and not
only for interfaces or otherwise explicitly and knowingly reference
counted objects) then I am sure most of currently existing code would
completely stop working from one day to the other and
On 28/08/12 11:48, Michael Fuchs wrote:
It is not a problem that is caused every time. But I prefer objects
which I destroy by myself, not by some magic.
Why not simply wait and see what Delphi does... FPC is bound to follow
that exactly (or damn close). So no point in guessing now, or thinkin
>From https://forums.embarcadero.com/thread.jspa?threadID=76082 (Thread: Bad
morning surprise)
"From XE3 onwards, your Delphi Professional EULA will prohibit you from
> using Delphi Professional for anything other than local data access."
> http://www.deltics.co.nz/blog/?p=1097
> http://bbs.2ccc.c
On 28/08/12 18:11, Alexsander Rosa wrote:
"From XE3 onwards, your Delphi Professional EULA will prohibit you from
using Delphi Professional for anything other than local data access."
R.I.P Delphi!
G.
--
___
Lazarus mailing list
Lazarus@lists.l
On Mon, Aug 27, 2012 at 03:15:43PM +0200, Michael Schnell wrote:
> On 08/24/2012 10:36 PM, Marco van de Voort wrote:
> > I read that as that there will be ref counted objects, not that all
> > objects will be ref counted per se. --
>
> Ok, but if there are reef-counted objects what is the point i
On Tue, Aug 28, 2012 at 12:08:05PM +0200, Felipe Monteiro de Carvalho wrote:
>
> Does anyone know if:
>
> 1> It will be possible to choose if a class or object is to be ref-counted?
> How?
>
> 2> If all existing objects will suddenly be ref-counted?
No. The above is all I have seen.
> I thin
On Sun, Aug 26, 2012 at 10:53:53PM +0200, Felipe Monteiro de Carvalho wrote:
> On Sun, Aug 26, 2012 at 9:23 PM, Marco van de Voort wrote:
> > Then you will also see that your Office counterexample is irrelevant, since
> > app store rules don't apply to Office. (but they do to nearly everybody
> >
On Tue, Aug 28, 2012 at 2:59 PM, Graeme Geldenhuys
wrote:
> On 28/08/12 18:11, Alexsander Rosa wrote:
>>
>>
>> "From XE3 onwards, your Delphi Professional EULA will prohibit you from
>>>
>>> using Delphi Professional for anything other than local data access."
>
>
>
> R.I.P Delphi!
=)
Marcos Dou
On 28.08.2012 19:59, Graeme Geldenhuys wrote:
On 28/08/12 18:11, Alexsander Rosa wrote:
"From XE3 onwards, your Delphi Professional EULA will prohibit you from
using Delphi Professional for anything other than local data access."
R.I.P Delphi!
The more I read about Delphi XE3 the more I h
On Tue, Aug 28, 2012 at 8:09 PM, Marco van de Voort wrote:
> I doubt that is possible. The non GCed classes would not have the events
> to handle the non ref counted classes. References from non ref counted
> classes to ref counted classes etc would not work.
>
> Something like that is only possib
On 8/28/2012 06:47, Bernd wrote:
The pragmatic fix to he above problem was:
procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
begin
Self._AddRef;
FDisconnectLock.Acquire;
[...]
FDisconnectLock.Release;
Self._Release; //<-- now we will be freed exactly her
On 29/08/2012 05:05, waldo kitty wrote:
> On 8/28/2012 06:47, Bernd wrote:
>> The pragmatic fix to he above problem was:
>>
>> procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
>> begin
>>Self._AddRef;
>>FDisconnectLock.Acquire;
>>
>>[...]
>>
>>FDisconnectLock
On 08/29/2012 06:05 AM, waldo kitty wrote:
i'm still learning all this new-fangled stuff... i'm a (very)
oldschool procedural coder and having things popping into and out of
existence whenever they want to is something i'm still trying to wrap
my head around :/ :(
You are using strings. He
On 08/28/2012 08:04 PM, Marco van de Voort wrote:
Because they might not only have advantages?
If this is that TObject.Free sometimes helps: Free supposedly still can
be used.
If this is that sometimes you don't want ref counting you might be able
to do TObject.RefCounting := False;
If t
On 08/29/2012 10:22 AM, Michael Schnell wrote:
If this is that it is error prone in certain situations:
TObject.RefCounting = False by default.
Nonetheless to me it seems like a nice idea to have String as a sibling
of TObjcet which in this case is somehow self-creating and freeing
(RefCo
On 08/28/2012 10:16 PM, Felipe Monteiro de Carvalho wrote:
This way no existing code is broken and only people that explicitly
want it for their framework will use it.
No existing code would be broken if TObject would get a property
RefCounting and by default TObject.RefCounting = False.
Bu
On 28/08/2012 18:59, Graeme Geldenhuys wrote:
On 28/08/12 18:11, Alexsander Rosa wrote:
"From XE3 onwards, your Delphi Professional EULA will prohibit you from
using Delphi Professional for anything other than local data access."
R.I.P Delphi!
I think that this has been the "intention" of
On 08/29/2012 11:07 AM, Leslie Kaye wrote:
I think that this has been the "intention" of the Professional Version
for many years else there would be no incentive to buy the Enterprise
and above versions would there??
Okay so you could access work group databases with the BDE but it was
always f
On 29/08/12 09:54, Michael Schnell wrote:
Nonetheless to me it seems like a nice idea to have String as a sibling
of TObjcet which in this case is somehow self-creating and freeing
(RefCounting = True) like an interfaced Object.
I'm working on exactly that (well, if I understood your message
On 08/29/2012 11:39 AM, Graeme Geldenhuys wrote:
Anyway, so far it is an interesting idea [for me], and maybe this
experiment will actually go somewhere. :)
Great !!!
If that library is working, to make it really usable, I suppose some
compiler magic is necessary to allow for using these l
On 29/08/12 10:07, Leslie Kaye wrote:
I think that this has been the "intention" of the Professional Version
for many years else there would be no incentive to buy the Enterprise
and above versions would there??
In the days of Borland, there was a clear separation between the
Personal, Profe
On 29/08/12 10:54, Michael Schnell wrote:
If that library is working, to make it really usable, I suppose some
compiler magic is necessary to allow for using these lStrings with the
syntax we know for String
In the end that would probably be the case... Just like Qt and Java
implemented some
2012/8/29 Lukasz Sokol :
> BTW, Frankly, would it not be easier/less error prone if the
> FDisconnectLock.[Acquire|Release]
> did that ? (i.e. increase/decrease the RefCount of Self as well as
> acquire/release the lock ?)
> It seems /logically/ correct : there is /one/ more activity associated
To me all this seems like a great idea and I am enlightened to see that
you already invested some work on that behalf.
Re-thinking the concept of (Unicode enabled) Strings in that light would
allow for another idea of mine, I expressed some months ago. I think the
different strings types shoul
Michael Schnell wrote:
In the Embarcadero forum someone suggested, that the intention is to
draw as much money as possible with a castrated XE3 (no IOS and Android
support), and then drop the Delphi Product line altogether.
Presumably with Embarcadero retaining it for internal development, wh
Michael Schnell wrote:
On 08/29/2012 11:39 AM, Graeme Geldenhuys wrote:
Anyway, so far it is an interesting idea [for me], and maybe this
experiment will actually go somewhere. :)
Great !!!
If that library is working, to make it really usable, I suppose some
compiler magic is necessary to
On 08/29/2012 12:33 PM, Mark Morgan Lloyd wrote:
Which was what I was assuming in my "What is a string" query in
fpc-devel
... where this discussion would be located more appropriately, of course.
-Michael
--
___
Lazarus mailing list
Lazarus@l
On 29/08/12 11:21, Michael Schnell wrote:
I think the different strings types should be a hierarchy of
increasingly specialized classes.
I think we only need one "unicode string" type and be done with it. That
"unicode string" type can support the official UTF-8, UTF-16 and UTF-32
encodings.
On 08/29/2012 12:51 PM, Graeme Geldenhuys wrote:
I think we only need one "unicode string" type and be done with it.
That "unicode string" type can support the official UTF-8, UTF-16 and
UTF-32 encodings. That's it! No more other string types should be
needed for modern applications.
I thin
2012/8/28 Sven Barth
> On 28.08.2012 19:59, Graeme Geldenhuys wrote:
>
>> On 28/08/12 18:11, Alexsander Rosa wrote:
>>
>>>
>>> "From XE3 onwards, your Delphi Professional EULA will prohibit you from
>>>
using Delphi Professional for anything other than local data access."
>>>
>>
>> R.I.
On 28/08/12 20:40, Sven Barth wrote:
The more I read about Delphi XE3 the more I have the feeling that FPC
and Lazarus should leave the route laid out by Delphi...
+1
I've been saying that for years.
Graeme.
--
___
Lazarus mailing list
Lazaru
I was thinking: I hope that Delphi will not make ref-counted objects
mandatory. If yes, then it will essentially bring all of the problems
from Java into Pascal, and loose our current memory optimization
parity with C++
--
Felipe Monteiro de Carvalho
--
__
On 29/08/12 13:41, Felipe Monteiro de Carvalho wrote:
I hope that Delphi will not make ref-counted objects
mandatory. If yes, then it will essentially bring all of the problems
from Java into Pascal,
The solution is simple. stop following Delphi!
G.
--
__
On 29/08/2012 11:11, Bernd wrote:
> 2012/8/29 Lukasz Sokol :
>
>> BTW, Frankly, would it not be easier/less error prone if the
>> FDisconnectLock.[Acquire|Release] did that ? (i.e.
>> increase/decrease the RefCount of Self as well as acquire/release
>> the lock ?) It seems /logically/ correct : th
Graeme Geldenhuys schrieb:
On 29/08/12 09:54, Michael Schnell wrote:
Nonetheless to me it seems like a nice idea to have String as a sibling
of TObjcet which in this case is somehow self-creating and freeing
(RefCounting = True) like an interfaced Object.
I'm working on exactly that (well, if
On 08/29/2012 06:24 PM, Hans-Peter Diettrich wrote:
AFAIK string concatenation "+" in .NET (and others?) is slow, instead
it's suggested to use concatenation methods directly. The intermediate
results in string expressions can cause much overhead.
IMHO this can only just be a test in orde
s-Delphi-post-XE3-roadmap-tp4025806p4026088.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Embrace yourself, people. We might get a lot of "attack" from
to-be-previous-Delphi-users (assuming they finally look at Lazarus/FPC
instead of moving to other dev platforms).
--
View this message in context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Delphi-post-X
I appreciate your... umm... "warm" welcome.
-Original Message-
From: leledumbo [mailto:leledumbo_c...@yahoo.co.id]
Sent: 29 August 2012 17:03
To: lazarus@lists.lazarus.freepascal.org
Subject: Re: [Lazarus] Delphi post-XE3 roadmap
Embrace yourself, people. We might get a lot
, and some people's email clients
aren't very good at keeping things properly threaded.
-Original Message-
From: leledumbo [mailto:leledumbo_c...@yahoo.co.id]
Sent: 29 August 2012 17:03
To: lazarus@lists.lazarus.freepascal.org
Subject: Re: [Lazarus] Delphi post-XE3 roadmap
Embra
On 29/08/12 17:24, Hans-Peter Diettrich wrote:
How do you intend to implement string operators?
I haven't thought or got to that part yet. I'll start with .Append(),
.Equals(), .Replace(), .SubString(), .Split() etc to cover all bases.
I'm still deciding if the TString class must be immutab
On 29/08/12 17:01, leledumbo wrote:
Standard problems in languages whose strings are immutable. Simply avoid
it... don't even try to implement it... please...
:-)
See my response to Hans-Peter.
Graeme.
--
___
Lazarus mailing list
Lazarus@l
On 8/29/2012 03:59, Lukasz Sokol wrote:
On 29/08/2012 05:05, waldo kitty wrote:
On 8/28/2012 06:47, Bernd wrote:
The pragmatic fix to he above problem was:
procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String);
begin
Self._AddRef;
FDisconnectLock.Acquire;
[...]
Graeme Geldenhuys schrieb:
On 29/08/12 17:24, Hans-Peter Diettrich wrote:
How do you intend to implement string operators?
I haven't thought or got to that part yet. I'll start with .Append(),
.Equals(), .Replace(), .SubString(), .Split() etc to cover all bases.
I'm still deciding if the T
create new instance, however .Concat, .SubString and .Split should.
--
View this message in context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Delphi-post-XE3-roadmap-tp4025806p4026143.html
Sent from the Free Pascal - Lazarus maili
On 30/08/12 13:49, leledumbo wrote:
straight, easy to write code to load a file contents into a string
variable easily. complicated techniques required)
What's so difficult about:
var
sl: TMyNewStringList;
fn: IString;
begin
fn := s('c:\myfile.txt');
sl := TMyNewStringList.Create;
sl
Seems like those bankers finally realized their mistake:
https://forums.embarcadero.com/thread.jspa?threadID=76285&tstart=0
The restriction now applies only to dbExpress.
--
View this message in context:
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Delphi-post-XE3-roa
82 matches
Mail list logo
