Delphi Project X Cross GUI

What will be the Delphi Project X Cross GUI ?

- Qt4
- wxWindows
- VCL 2.0
- ???

What is your estimation?
0
Ralf
1/3/2010 8:47:50 PM
embarcadero.delphi.non-tech 5933 articles. 1 followers. Follow

378 Replies
2474 Views

Similar Articles

[PageSpeed] 4

Ralf Stocker a écrit :

> What will be the Delphi Project X Cross GUI ?
> 
> - Qt4
> - wxWindows
> - VCL 2.0
> - ???
> 
> What is your estimation?

My estimation is that you just want to start yet another speculative 
thread because you are bored.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/3/2010 8:56:23 PM
Ralf Stocker wrote:

> What will be the Delphi Project X Cross GUI ?

Only Embt can answer this. I would prefer a VCL 2.0 but I doubt that
will happen. And I hope it won't be a CLX 2.0.


-- 
Andreas Hausladen
0
Andreas
1/3/2010 9:01:25 PM
Just a short lock at the numbers...

Qt4.6            1.45 GB (~31.000 files)
wxWindows 2.9    0.20 GB (~24.000 files)
VCL D2009        0.05 GB (~ 1.200 files)
0
Ralf
1/3/2010 9:15:22 PM
On 03.01.2010 22:01, Andreas Hausladen wrote:
> Ralf Stocker wrote:
>
>> What will be the Delphi Project X Cross GUI ?
>
> Only Embt can answer this. I would prefer a VCL 2.0 but I doubt that
> will happen. And I hope it won't be a CLX 2.0.
>
>

According to history (CLX 1.0), CLX 2.0 means Qt4 plus Delphi wrappers. 
What is bad about that?
0
Ralf
1/3/2010 9:18:29 PM
Joanna Carter wrote:

>> What is your estimation?
>
>My estimation is that you just want to start yet another speculative 
>thread because you are bored.

Sure sure, and mayby he is just really interested in what direction
they *could* go or if there are more posibilities next to the 3 items
he mentioned.

Its a big step for codegear and for us so why not speculate?
0
Marius
1/3/2010 9:35:03 PM
Joanna Carter wrote:

> Ralf Stocker a écrit :
> 
> > What will be the Delphi Project X Cross GUI ?
> > 
> > - Qt4
> > - wxWindows
> > - VCL 2.0
> > - ???
> > 
> > What is your estimation?
> 
> My estimation is that you just want to start yet another speculative 
> thread because you are bored.
> 
> Joanna


With no firm information available people, if interested in something,
often try to speculate. It is I guess part of human nature.

To avoid that, the good solution would be to provide more information
if possible.


Regards,
Zenon

Edited by: Zenon Jordan on Jan 3, 2010 1:45 PM
0
Zenon
1/3/2010 9:46:12 PM
Ralf Stocker wrote:

> What is bad about that?

Qt4 isn't the problem. The problem is that I remember what I did in
2002-2005 for the Kylix "Community".


-- 
Andreas Hausladen
0
Andreas
1/3/2010 9:47:34 PM
> {quote:title=Ralf Stocker wrote:}{quote}
> What will be the Delphi Project X Cross GUI ?
> 
> - Qt4
> - wxWindows
> - VCL 2.0
> - ???
> 
> What is your estimation?

Unless they're writing a VCL 2.0 as Andreas said, I think reviving CLX remains the only acceptable solution timewise.

Does anyone know if they started a private beta program or not?

Utku.
0
utku
1/3/2010 10:05:56 PM
On 03.01.2010 22:47, Andreas Hausladen wrote:
> Ralf Stocker wrote:
>
>> What is bad about that?
>
> Qt4 isn't the problem. The problem is that I remember what I did in
> 2002-2005 for the Kylix "Community".
>
>

Maybe we could recycle some things... ;-)
0
Ralf
1/3/2010 10:49:40 PM
Zenon Jordan a écrit :
y
> To avoid that, the good solution would be to provide more information
> if possible.

In that case, you really need to ask EMBT directly; they really are the 
only people who know anything more.

Then you can tell all of us what they tell you :-)

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/3/2010 11:24:40 PM
> Just a short lock at the numbers...
> 
> Qt4.6            1.45 GB (~31.000 files)
> wxWindows 2.9    0.20 GB (~24.000 files)
> VCL D2009        0.05 GB (~ 1.200 files)

.... and your point is? The VCL (especially the 'visual' part) just
wraps a more fundamental API, so of course it's going to be much
smaller than the other two. As for QT vs wxWindows, well doesn't the
former provide a rather more high level interface for its consumers? If
so, then again, one would expect it to be bigger.
0
Chris
1/3/2010 11:38:30 PM
Joanna Carter wrote:

> My estimation is that you just want to start yet another speculative 
> thread because you are bored.

And the problem with that is......?

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/4/2010 1:39:03 AM
> - VCL 2.0

Woot? After only 16 years on VCL 1.0?
0
Martin
1/4/2010 3:18:20 AM
Joanna Carter wrote:

> Zenon Jordan a écrit :
> y
> > To avoid that, the good solution would be to provide more
> > information if possible.
> 
> In that case, you really need to ask EMBT directly; they really are
> the only people who know anything more.
> 
> Then you can tell all of us what they tell you :-)
> 
> Joanna



Good idea!
Do you know any talkative people there? <g>
0
Zenon
1/4/2010 4:06:03 AM
On 3-1-2010 22:46, Zenon Jordan wrote:

> With no firm information available people, if interested in something,
> often try to speculate. It is I guess part of human nature.
>
> To avoid that, the good solution would be to provide more information
> if possible.

Apart from the GUI stuff, I'd be really interested if "X-Platform"
means that each platform can also target databases that reside
on a different platform.
I would have been happy to use Kylix if it had had MSSQL
connectivity. Lacking that, Kylix was useless to me.
And I don't care who was to "blame".




-- 
Arthur Hoornweg

(In order to reply per e-mail, please just remove the ".net"
  from my e-mail address. Leave the rest of the address intact
  including the "antispam" part. I had to take this measure to
  counteract unsollicited mail.)
0
Arthur
1/4/2010 7:41:31 AM
> Does anyone know if they started a private beta program or not?

It wouldn't be private if that was known to us would it? ;)
0
Hannes
1/4/2010 9:15:24 AM
utku karatas wrote:

>Unless they're writing a VCL 2.0 as Andreas said, I think reviving
>CLX remains the only acceptable solution timewise.

For the record, i'm not much into cross platform (except some
windows-mobile using lazarus/fpc), but out of interest, what would have
to be changed in a vcl-2 to be cross platform (in a crude approach)?
Why would only CLX be the only option (i never really liked the
q-approach)

Sofar i have only heard rumors about windows/linux/mac, but does the
new x-platform include windows-mobile, most linux variants or even
other OS'es?
0
Marius
1/4/2010 10:01:37 AM
Zenon Jordan wrote:

> > In that case, you really need to ask EMBT directly; they really are
> > the only people who know anything more.
> > 
> > Then you can tell all of us what they tell you :-)
> 
> Good idea!
> Do you know any talkative people there? <g>

They all love to talk, but I'm not sure if they are allowed to. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"You can't step twice into the same river."
 -- Heraclitus
0
Rudy
1/4/2010 11:55:52 AM
On 1/3/2010 2:56 PM, Joanna Carter wrote:

>
> My estimation is that you just want to start yet another speculative
> thread because you are bored.
>
> Joanna
>

How is it that certain posters who never use Delphi, are exclusive 
Macophiles and routinely insult the rest of us are still allowed to be 
TeamB members?
0
Mark
1/4/2010 3:12:26 PM
> What is bad about that?

That you get a wrapper over a wrapper. And a over a wrapper the design of is beyond Embarcadero control. IMHO it means slower performance and lots of compromises to accomodate different designs and aims. Especially if compatibility among the native API VCL and a VCL wrapped over another wrapper has to be mantained. And the last thing I wish to see is a Windows Qt-VCL or the like.
0
Luigi
1/4/2010 3:22:11 PM
> {quote:title=Hannes Danzl wrote:}{quote}
> > Does anyone know if they started a private beta program or not?
> 
> It wouldn't be private if that was known to us would it? ;)

The first rule of beta program is you don't talk about beta program? That must be a hardcore beta process Embt. runs :)
0
utku
1/4/2010 3:44:22 PM
"utku karatas" wrote on Sun, 3 Jan 2010 14:05:56 -0800:

> Does anyone know if they started a private beta program or not?

If someone tells you they have, they'd be breaking their NDA.

-- 
Better Web Sites Sell More Software: http://www.vexelfire.com

Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
0
Brandon
1/4/2010 3:46:12 PM
On 04.01.2010 16:22, Luigi Sandon wrote:
>> What is bad about that?
>
> That you get a wrapper over a wrapper. And a over a wrapper the design of is beyond Embarcadero control. IMHO it means slower performance and lots of compromises to accomodate different designs and aims. Especially if compatibility among the native API VCL and a VCL wrapped over another wrapper has to be mantained. And the last thing I wish to see is a Windows Qt-VCL or the like.

+1

But I doubt that the VCL can talk to Linux and Mac API within 1 
year...Emba hasn't that manpower. And Qt exists for 19 years.
0
Ralf
1/4/2010 3:47:12 PM
On 04.01.2010 16:44, utku karatas wrote:
>> {quote:title=Hannes Danzl wrote:}{quote}
>>> Does anyone know if they started a private beta program or not?
>>
>> It wouldn't be private if that was known to us would it? ;)
>
> The first rule of beta program is you don't talk about beta program? That must be a hardcore beta process Embt. runs :)

....with hardcore bugs in the RTM iso ;-)
0
Ralf
1/4/2010 3:56:16 PM
> {quote:title=Marius . wrote:}{quote}
> For the record, i'm not much into cross platform (except some
> windows-mobile using lazarus/fpc), but out of interest, what would have
> to be changed in a vcl-2 to be cross platform (in a crude approach)?
> Why would only CLX be the only option (i never really liked the
> q-approach)

I'm not experienced either but I think coming up with a whole new framework is a lot harder than just wrapping your already existing solution. Look at QT, yeah it sure looks good now but how many years and how many versions did it take to get there? (So is Rails, Django, etc.. These might sound newish to you but even they are at least 5 year old frameworks. Any reputable framework earned that reputation by not losing in the time test. How would Embt. compete in such a short time frame if they come up with
 a new GUI framework? Would they even risk it I am doubtful.) 

Utku.
0
utku
1/4/2010 3:59:18 PM
Mark Andrews a écrit :

> How is it that certain posters who never use Delphi, are exclusive 
> Macophiles and routinely insult the rest of us are still allowed to be 
> TeamB members?

Because not all members of TeamB are here purely for Delphi and, with 
the proposed Project X targetting Mac, don't you think it would be 
useful to have someone on TeamB to help all those Mac newbies with any 
problems?

Don't forget, I was recruited to support C#Builder and the OO Design 
forums, not primarily Delphi; even though I used it for many years and 
contributed extensively to the Delphi forums.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/4/2010 4:08:24 PM
Brandon Staggs a écrit :

> If someone tells you they have, they'd be breaking their NDA.

But, if someone tells you they are not on the beta, they are either 
lying or they are not on the beta.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/4/2010 4:09:36 PM
> How would Embt. compete in such a short time frame

By basing their framework on Qt, they wouldn't be competing, they would 
be repeating one of the mistake of D.Net, by essentially saying that 
"hey, we're not good enough to do it ourselves, so we're using XXX which 
is better than what we could have come up with"

The answer in that case would be the same as with .Net: if there exists 
another framework that is better, why use Embarcadero's wrapper and not 
the real thing? The wrapper will have compromises, limitations, issues 
and add layer of potentially soon obsolete proprietary stuff (a very 
real issue given Kylix, CXXBuilder, D.Net, DWin32-only etc.), while the 
real deal would be moving forward, be well supported, etc.

Just like D.Net turned out as little more than a C#/.Net advertisement 
in favour of MS's dev tools, an Embarcadero relying on QT would be an 
advertisement for using Qt directly.

It's not like .Net or QT are not usable on their own merits, that you 
need a wrapper to take advantage of them...

Eric
0
Eric
1/4/2010 4:26:55 PM
Joanna,

> Don't forget, I was recruited to support C#Builder and the OO Design
> forums, not primarily Delphi; even though I used it for many years and
> contributed extensively to the Delphi forums.

Does recruited mean that you are paid for it?
I thought that you are posting here in your spare time.

-- 
Roman
0
Roman
1/4/2010 4:49:51 PM
> What will be the Delphi Project X Cross GUI ?
>
> - Qt4
> - wxWindows
> - VCL 2.0
> - ???
>
> What is your estimation?

May be Lazarus/FPC interfaces?
0
Gilbert
1/4/2010 4:52:25 PM
utku karatas wrote:

> > {quote:title=Hannes Danzl wrote:}{quote}
> > > Does anyone know if they started a private beta program or not?
> > 
> > It wouldn't be private if that was known to us would it? ;)
> 
> The first rule of beta program is you don't talk about beta program?

NDAs usually prohibit this, yes.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Science is what people understand well enough to explain to a 
 computer. All else is art." -- Donald Knuth
0
Rudy
1/4/2010 5:42:36 PM
Hello,

if you ask the right persons they might not give you a definite answer
but maybe some hints about other ways to find out or so.

In every case persons worh asking would be Nick and Mike for instance.
David I might also be a good idea.

Greetings

Markus
0
Markus
1/4/2010 6:42:44 PM
Am 04.01.2010 16:44, schrieb utku karatas:
>> {quote:title=Hannes Danzl wrote:}{quote}
>>> Does anyone know if they started a private beta program or not?
>>
>> It wouldn't be private if that was known to us would it? ;)
> 
> The first rule of beta program is you don't talk about beta program? That must be a hardcore beta process Embt. runs :)

About EMBT's rules for betas you'd better ask EMBT directly.

Greetings

Markus
0
Markus
1/4/2010 6:45:23 PM
Roman Kassebaum a écrit :

> Does recruited mean that you are paid for it?

You must be joking. The most we get is free product; which isn't worth 
much if you don't have clients who use those products and require your 
services with those products.

> I thought that you are posting here in your spare time.

Believe it or not, TeamB do what they do out of loyalty to the people 
who put in the real effort to bring you the best products their managers 
will allow. Developers helping other developers to earn a crust.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/4/2010 6:53:25 PM
Roman Kassebaum wrote:

> Joanna,
> 
> > Don't forget, I was recruited to support C#Builder and the OO Design
> > forums, not primarily Delphi; even though I used it for many years
> > and contributed extensively to the Delphi forums.
> 
> Does recruited mean that you are paid for it?

It means you can't apply for a position in TeamB, you are chosen. <g>

> I thought that you are posting here in your spare time.

Don't know about Joanna, but I surely am and I guess she is too. I
doubt her clients want her to spend their time helping others. <g>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Bo Diddeley's Observation On The Law: Always take a lawyer with 
you, and bring another lawyer to watch him.
0
Rudy
1/4/2010 7:07:26 PM
extjs or jquery
0
James
1/4/2010 7:19:15 PM
Markus Humm wrote:

> Am 04.01.2010 16:44, schrieb utku karatas:
> >> {quote:title=Hannes Danzl wrote:}{quote}
> >>> Does anyone know if they started a private beta program or not?
> > > 
> >> It wouldn't be private if that was known to us would it? ;)
> > 
> > The first rule of beta program is you don't talk about beta
> > program? That must be a hardcore beta process Embt. runs :)
> 
> About EMBT's rules for betas you'd better ask EMBT directly.

Isn't this enough?

"What We Expect From Our Field Testers"
http://dn.embarcadero.com/article/40234
-- 
Uwe
0
Uwe
1/4/2010 7:36:23 PM
> And the problem with that is......?

.... that Embarcadero will leave its customers in the total dark until it will roll out a lame solution.
0
Luigi
1/4/2010 7:41:28 PM
In article <199479@forums.codegear.com>, Eric Grange wrote:
> By basing their framework on Qt, they wouldn't be competing, they
> would be repeating one of the mistake of D.Net, by essentially
> saying that "hey, we're not good enough to do it ourselves, so
> we're using XXX which is better than what we could have come up with"

No, there's a big difference between "we're not good enough" and "if we 
were going to do this we should have started five years ago".

> The answer in that case would be the same as with .Net: if there
> exists another framework that is better, why use Embarcadero's
> wrapper and not the real thing?

That depends on what "the real thing" is ... one answer that will apply 
in most cases is because "the real thing" probably has a C/C++ interface 
that will not be intuitive to call from Pascal.

A C++ Builder release could probably be built around Qt or wx or GTK+ or 
some other toolkit without too much effort and without placing too much 
burden on programmers, but Delphi is a different animal.

Cheers,
 Daniel.
0
Daniel
1/4/2010 7:46:49 PM
> But I doubt that the VCL can talk to Linux and Mac API within 1 
> year...Emba hasn't that manpower. And Qt exists for 19 years.

That was what "shocked" me when the news that xplat has precedence over 64 bit came out. Going 64 would have required some adjustements, but not a whole new VCL (although after so many years the Windows VCL itself needs a redesing), while targeting Linux and Mac *properly* needs two whole new frameworks - and even if they their Linux/BSD kernels may share something, the layers above the kernel may be pretty different, especially the GUIs. A "lame" solution on both platforms IMHO won't be appealing at all 
to "foreign" developers - beside fulfilling Embarcadero own xplat needs (and maybe some customers'). And while under Linux many could accept a subpar GUI in exchange of being able to deliver server applications on that platform, the Mac is all about the GUI - and if you target the Mac you don't target the average data-entry guy, nobody buys him a Mac.

I always thought xplat as a multi-year incremental effort - I know that using Qt as they did with CLX is the faster and requiring less resources approach, but the one that will cause many issues too in the long run.
0
Luigi
1/4/2010 7:53:25 PM
utku karatas wrote:

> > {quote:title=Hannes Danzl wrote:}{quote}
> > > Does anyone know if they started a private beta program or not?
> > 
> > It wouldn't be private if that was known to us would it? ;)
> 
> The first rule of beta program is you don't talk about beta program? That
> must be a hardcore beta process Embt. runs :)

I wasn't commenting on beta or program, but on your oxymoron (or close to
anyways) of asking about a private thing in public ;)
0
Hannes
1/4/2010 10:08:12 PM
> {quote:title=Joanna Carter wrote:}{quote}
> My estimation is that you just want to start yet another speculative 
> thread because you are bored.
> 
> Joanna

I've been wondering... can't you just stay quiet if you have nothing interesting and valuable to say? 

No answer preferred.
0
Pietia
1/5/2010 2:42:22 AM
Joanna,

> Believe it or not, TeamB do what they do out of loyalty to the people
> who put in the real effort to bring you the best products their managers
> will allow. Developers helping other developers to earn a crust.

I do believe you. I only misunderstood the term "to recruit".

-- 
Roman
0
Roman
1/5/2010 9:18:50 AM
Luigi Sandon wrote:

> > And the problem with that is......?
> 
> ... that Embarcadero will leave its customers in the total dark until
> it will roll out a lame solution.

Wow, what faith. I'm touched.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/5/2010 5:27:01 PM
"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:199847@forums.codegear.com...
> Luigi Sandon wrote:
>
>> > And the problem with that is......?
>>
>> ... that Embarcadero will leave its customers in the total dark until
>> it will roll out a lame solution.
>
> Wow, what faith. I'm touched.

Maybe CLX has something to do with it? :) This aside, it would certainly be 
nice to know what you guys have in mind...

Alan
0
Alan
1/5/2010 6:21:29 PM
Captain Mockba wrote:

> > {quote:title=Joanna Carter wrote:}{quote}
> > My estimation is that you just want to start yet another
> > speculative thread because you are bored.
> > 
> > Joanna
> 
> I've been wondering... can't you just stay quiet if you have nothing
> interesting and valuable to say?

I found it spot on, and therefore very valuable. <g>


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"People demand freedom of speech to make up for the freedom of 
 thought which they avoid."
 -- Soren Aabye Kierkegaard (1813-1855)
0
Rudy
1/5/2010 7:05:40 PM
In article <199573@forums.codegear.com>, Luigi Sandon wrote:
> That was what "shocked" me when the news that xplat has precedence
> over 64 bit came out. Going 64 would have required some adjustements,
> but not a whole new VCL ...

It seems to me that (unless I've missed something) you probably haven't 
understood what's actually been said.

As I understand it the thing that is going to be done before producing 
64-bit Delphi is the work on the new compiler architecture -- so that 
the D64 compiler can be built with the new architecture, which should 
(we all hope) make it quicker to develop and more reliable to maintain.

The new compiler design will of course support X-platform work -- or 
any work targeting a platform other than Win32 (and that would include 
Win64) -- but that doesn't mean that the technology won't be first used 
for D64 and CB64. I haven't seen any statement to lead me to believe 
that those products won't be the first to use it.

There will eventually have to be a replacement for VCL -- or at least a 
massive upgrade to it -- if a Delphi-like product is to be released on 
non-Windows platforms, but that doesn't have to be done before the 
first release of Delphi for Win64.

> ... targeting Linux and Mac *properly* needs two whole new
> frameworks ...

I disagree. The value of cross-platform tools is that the SAME codebase 
targets all platforms. The idea is that it should be possible to write 
application code that can be built -- without change -- for any 
(supported) platform. The framework itself will contain code specific 
to the particular platform being targeted, but it hides that from the 
client app.

I develop mostly for Windows and linux. If I can build my applications 
for Mac just by throwing a switch I may be moved to do so, but if I 
have to learn a new framework to target the Mac I'm not going to bother 
-- it's not that I don't like the Mac, just that I don't have time to 
support three different targets unless the app code is very similar for 
them all.

> ... the Mac is all about the GUI - and if you target the Mac you
> don't target the average data-entry guy, nobody buys him a Mac.

That's true ... but a good cross-platform framework can support the Mac 
well enough -- and "well enough" is certainly better than "not at all", 
if the application itself has any value. I don't target "the average 
data entry guy" whatever platform I'm writing for.

Cheers,
 Daniel.
0
Daniel
1/5/2010 11:58:11 PM
"Alan Garny" wrote on Tue, 5 Jan 2010 10:21:29 -0800:

> Maybe CLX has something to do with it? :) This aside, it would certainly be 
> nice to know what you guys have in mind...

Obviously if they give us an outline of what they are currently doing,
the newsgroups will explode with complaints (no matter what they are
doing), so I can understand why they wouldn't want to bother.

Still, it would be nice to have some idea of the immediate future of
Delphi, especially since some of us renew SA every year.

-- 
Better Web Sites Sell More Software: http://www.vexelfire.com

Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
0
Brandon
1/6/2010 12:04:36 AM
Daniel James wrote:
> I disagree. The value of cross-platform tools is that the SAME codebase 
> targets all platforms. The idea is that it should be possible to write 
> application code that can be built -- without change -- for any 
> (supported) platform.

That may be nice for new projects -- but how am I going to take any of 
my large applications, which rely heavily on various DevEx components, 
such as the Quantum Grid, the Scheduler, and a host of others -- and 
recompile them for the Mac?

The answer, of course, is that I won't be able to. It took DevEx many 
months to fully adapt to Unicode! It would take them 3 centuries to 
adapt all that code that is ultimately based on the WinAPI, and make 
that library work the same on Windows, Linux and Mac.

I think that many developers have projects that could never be 
recompiled for another platform. We have taken advantage of the great 
specialization and benefits that a come from focusing on a single platform.

The most that I could hope for in the short-term, is to be able to 
provide separate projects that provide some of the functionality of the 
products. That kind of flies in the face of the same code base.

Loren sZendre
0
Loren
1/6/2010 12:09:40 AM
> Wow, what faith. I'm touched.

Well between CLX and the amount of UI glitches that can be found in the 
Delphi IDE (flickering, misalignments, etc.) or the UI behaviors 
tolerated from the new help (laggyness, flickerings, impractical 
layouts...), there is certainly a lot of trust you have to rebuild as 
far as GUIs are concerned, at every level of it.

Eric
0
Eric
1/6/2010 7:50:09 AM
"Brandon Staggs" <nospam@a.b.c> wrote in message 
news:200013@forums.codegear.com...
> "Alan Garny" wrote on Tue, 5 Jan 2010 10:21:29 -0800:
>
>> Maybe CLX has something to do with it? :) This aside, it would certainly 
>> be
>> nice to know what you guys have in mind...
>
> Obviously if they give us an outline of what they are currently doing,
> the newsgroups will explode with complaints (no matter what they are
> doing), so I can understand why they wouldn't want to bother.

What difference would that make? People would just complain a few months 
earlier, that's all. :)

> Still, it would be nice to have some idea of the immediate future of
> Delphi, especially since some of us renew SA every year.

That's one reason indeed.

Alan
0
Alan
1/6/2010 9:33:12 AM
"Joanna Carter" <joanna@no.spam.for.me> wrote in message 
news:199474@forums.codegear.com...
> Mark Andrews a écrit :
>
>> How is it that certain posters who never use Delphi, are exclusive
>> Macophiles and routinely insult the rest of us are still allowed to be
>> TeamB members?
>
> Because not all members of TeamB are here purely for Delphi and, with
> the proposed Project X targetting Mac, don't you think it would be
> useful to have someone on TeamB to help all those Mac newbies with any
> problems?
>
> Don't forget, I was recruited to support C#Builder and the OO Design
> forums, not primarily Delphi; even though I used it for many years and
> contributed extensively to the Delphi forums.

Unfortunately most of your posts here over the past year exhibit nothing 
more than you would expect from a Mac fanboy(/girl).

CB
0
Charles
1/6/2010 2:19:33 PM
Charles B a écrit :

> Unfortunately most of your posts here over the past year exhibit nothing 
> more than you would expect from a Mac fanboy(/girl).

Maybe because, for the first time in around 20 years of using computers 
I am actually enjoying the experience, not fighting with an unreliable 
operating system.

Even when I do use Windows in a VM, it's so much more reassuring that I 
can revert the VM to a clean installation in less time than it takes to 
have lunch.

As for Mac development in Xcode, most Windows development environments 
really could learn a thing or two :-)

Don't forget that programming X-platform means you really should know 
what users on other platforms expect from a product. Mac users are 
notoriously fastidious and an in depth knowledge of how to design an 
acceptable Mac UI may well involve a bit more knowledge than simply 
hoping that a Windows designed UI will be acceptable.

How would anyone ever get to know about the underlying ObjectiveC and 
Cocoa libraries that Delphi X will need to access when third party 
components are not yet available without spending a lot of time learning?

How else would third party components get written if vendors don't 
understand the OS they are targetting if they don't get "down and dirty" 
with the target OSs and their APIs?

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/6/2010 5:57:39 PM
> {quote:title=Arthur Hoornweg wrote:}{quote}
> On 3-1-2010 22:46, Zenon Jordan wrote:
> 
> > With no firm information available people, if interested in something,
> > often try to speculate. It is I guess part of human nature.
> >
> > To avoid that, the good solution would be to provide more information
> > if possible.
> 
> Apart from the GUI stuff, I'd be really interested if "X-Platform"
> means that each platform can also target databases that reside
> on a different platform.
> I would have been happy to use Kylix if it had had MSSQL
> connectivity. Lacking that, Kylix was useless to me.
> And I don't care who was to "blame".
> 
> 
> 
> 
> -- 
> Arthur Hoornweg
Kylix worked just fine accessing MSSQL, by installing UnixODBC and FreeTDS, and using cross platform ODBC components. I used it, worked well. Sorry you didn't research this thoroughly enough at the time that you were interested. Then you could have invested significant resources & time in +upgrading+ your server side systems like myself and many others did, only to have your tools vendor pull the rug out from under you with extreme +silence+. <g>

David Keith
0
David
1/6/2010 6:45:19 PM
Hello,

Joanna Carter wrote:

> As for Mac development in Xcode, most Windows development
> environments really could learn a thing or two :-)

FWIW, I'd really appreciate some kind of document that points out the
advantages XCode has over other environments. Such advantages clearly
seem to exist since many Mac programmers praise XCode, but I never
found more precise explanations. I don't have Mac experience, but I've
developed with VS, Delphi/C++Builder, Eclipse and other common tools,
and I think many people around here have similar presets, so if you
know an article that somehow covers XCode's assets for Mac newbies I'd
be happy to read it.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/6/2010 6:53:25 PM
Moritz Beutel <Moritz Beutel a écrit :

> FWIW, I'd really appreciate some kind of document that points out the
> advantages XCode has over other environments. Such advantages clearly
> seem to exist since many Mac programmers praise XCode, but I never
> found more precise explanations. I don't have Mac experience, but I've
> developed with VS, Delphi/C++Builder, Eclipse and other common tools,
> and I think many people around here have similar presets, so if you
> know an article that somehow covers XCode's assets for Mac newbies I'd
> be happy to read it.

I don't know, off hand, of any such document.

My experience has been that, as a Mac newbie, I really didn't know what 
I was doing with Xcode and ended up just getting frustrated and hoping 
it wouldn't be long before somebody brought out a VS or Delphi for Mac.

However, as I used to do when I first got to know about Delphi, I have 
set myself the challenge of doing presentations, on Mac development, for 
the UK Developers Group (used to be the Borland Users Group). I did one 
a few months ago; I had copied a lot of the code from other articles and 
wasn't really sure what a lot of it did and ended up giving a very good 
impression of someone who really didn't know what she was talking about ;-)

I am presently preparing for another presentation for February. This 
time, I am writing an article (more like a small book!) with a detailed 
account of how to create a simple application, to accompany the 
presentation.

The object model consists of a Word class with one string and one 
Language properties, and a Language class that just has one string property.

The application has a main form that browses a list of Word objects, has 
a second form for browsing and editing a list of Language objects and 
dialogs for creating and editing Word objects.

In the process of writing the article I have found out all sorts of 
interesting and useful things about using Xcode, Interface Builder, 
ObjectiveC and the Cocoa libraries.

You may remember that I wrote a MVP (Model View Presenter) framework, 
starting in Delphi and then ported to C#. Apple's development 
environment and the Cocoa libraries have strong connections with the 
same Taligent MVP frameworks that I based my frameworks on so, now I 
have started to get to know how to use the IDE, everything has started 
to fall into place and, instead of having to work very hard to get 
Delphi or Visual Studio to accomodate the MVP patterns, I am finding it 
a lot easier to use Xcode.

But, as for being easy for an experienced Windows programmer but a Mac 
newbie...

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/6/2010 7:19:55 PM
In article <200015@forums.codegear.com>, Loren Szendre wrote:
> I think that many developers have projects that could never be 
> recompiled for another platform. 

I'm sure that's true, yes. You have to build for cross-platform from the 
start.

> We have taken advantage of the great specialization and benefits
> that a come from focusing on a single platform.

I don't know your products so I can't say how well that has worked for 
you, but I have seen very few applications in which the 'specialization' 
that came from focusing on a single platform brought anything I would 
describe as a 'benefit'. In most cases the result is just a non-standard 
GUI that -- because it is non-standard -- is harder for end users to 
learn.

I consider it a benefit of cross-platform development that the 
programmer is encouraged to concentrate on the business logic rather 
than being distracted by obscure GUI 'tricks'. Good cross-platform 
frameworks use native widgets on every platform and have the platform-
specific code necessary to make correct use of those widgets built in. 
There is rarely much need for further customization.

That's not to say that platform-specific customization of cross-platform 
frameworks isn't possible, just that it isn't necessary and that 
developers using such tools generally don't customize further without 
good reason.

Cheers,
 Daniel.
0
Daniel
1/6/2010 7:35:15 PM
Daniel James wrote:
> In article <200015@forums.codegear.com>, Loren Szendre wrote:
>> I think that many developers have projects that could never be 
>> recompiled for another platform. 
> 
> I'm sure that's true, yes. You have to build for cross-platform from the 
> start.

Exactly. When you start using a new architecture on any level, it takes 
significant time for it to infiltrate into all stages of planning, 
designing, development and testing. For example, we started using 
RemObjects Data Abstract years ago -- and yet we're still finding ways 
to re-architect our framework, based on it's capability.

>> We have taken advantage of the great specialization and benefits
>> that a come from focusing on a single platform.

> describe as a 'benefit'. In most cases the result is just a non-standard 
> GUI that -- because it is non-standard -- is harder for end users to 
> learn.

The deviations we have made were specifically to make the application 
far easier to learn, and we are well known in our industry for only 
requiring 10-15 minutes for new employees to learn 75% of what they need 
to use our apps. But, having said that, those innovations could be 
implemented on any platform.

> I consider it a benefit of cross-platform development that the 
> programmer is encouraged to concentrate on the business logic rather 
> than being distracted by obscure GUI 'tricks'.

Yes, that is a huge benefit. But when over 99% of your potential 
customers use Windows, and you use an amazingly productive development 
tool for that platform, you tend to focus your efforts on things that 
bring in additional revenue.

> That's not to say that platform-specific customization of cross-platform 
> frameworks isn't possible, just that it isn't necessary.

One thing I had in mind specifically was simply using the Quantum Grid 
from DevEx. Such an amazingly complex component would obviously not be 
included in any cross-dev toolkit, because one vendor would have to 
provide 3 separate components (for Win, Linux & Mac) -- that were 
radically different under the hood, but still had the same public 
interfaces for programmers, including the skinning.

But yet, our users love that component, and would skin us alive, were we 
to take it out, after exposing them to it. There are other examples, but 
that should suffice.

Loren sZendre
0
Loren
1/6/2010 8:08:23 PM
> {quote:title=Loren Szendre wrote:}{quote}
> The answer, of course, is that I won't be able to. It took DevEx many 
> months to fully adapt to Unicode! It would take them 3 centuries to 
> adapt all that code that is ultimately based on the WinAPI, and make 
> that library work the same on Windows, Linux and Mac.

100% agreed.
3rd party tooling will lag (if ever coming) and without it, there's not that much advantage Delphi can offer. Richness of 3rd party offerings (be it free or commercial) was always the strong reason for choosing Delphi (as it was for Turbo Pascal (my first one was on CP/M)). I'm afraid that that market is diminishing and remaining (although vocal) users are begining to sound like retired Cobol programmers(*).

LP,
Dejan
0
Dejan
1/6/2010 11:47:16 PM
> {quote:title=Joanna Carter wrote:}{quote}
> Maybe because, for the first time in around 20 years of using computers 
> I am actually enjoying the experience, not fighting with an unreliable 
> operating system.

For me: enjoying means nice cigar, excellent cognac and great sex - not fiddling with a OS: that's work. Work I do for a living. Being 2 man shop that means market niches. And chasing percents of promilles of 3% market shares (see: http://www.systemshootouts.org/mac_sales.html) doesn't seem very sound plan.

To each his own, I guess.
Dejan
0
Dejan
1/6/2010 11:53:02 PM
Dejan Stanic wrote:
>> {quote:title=Loren Szendre wrote:}{quote}
>> The answer, of course, is that I won't be able to. It took DevEx many 
>> months to fully adapt to Unicode! It would take them 3 centuries to 
>> adapt all that code that is ultimately based on the WinAPI, and make 
>> that library work the same on Windows, Linux and Mac.
> 
> Richness of 3rd party offerings (be it free or commercial) was always the strong reason for choosing Delphi (as it was for Turbo Pascal (my first one was on CP/M)). I'm afraid that that market is diminishing...

Yeah, I hear a lot about the 3rd party market diminishing. But that's 
not a bad thing, necessarily. 8-10 years ago, if you searched the 
Internet for a something like Com Port components, you would find many 
(perhaps dozens) available, some free, some shareware and some fully 
commercial. You don't know right away which are buggy, which are about 
to be dropped from active development (or are already dropped, but you 
just don't know it), or which are built by developers that really 
understand the topic, or which had the love and attention to make a 
truly useful and robust component.

With all those issues, at this point in Delphi's maturity, many of the 
poorly designed or buggy components have dropped from view. What usually 
remains is 1-3 really good choices.

And there are many major vendors who are very actively maintaining and 
adding new offerings and features to their Delphi component libraries. I 
still hear of many developers that avoid 3rd party components like the 
plague. If that works for them, fine. But for my company, the benefit 
our apps receive, and the cost-benefit ratio of these components 
(spending thousands of hours in-house to create them, versus licensing 
them) -- make it a no-brainer for us. And we don't license components 
without source.

I believe the 3rd party market is more than sufficient for Delphi. Take, 
for instance, DevEx and TMS. We use significant numbers of components 
from both companies, and find that between the two, there are ample 
options. Would I really be benefited by having 30 products to sort 
through? I doubt it.

And for the really off-beat stuff, there is still plenty out there that 
can be adapted to the latest Delphi, without too much work.

Loren sZendre
0
Loren
1/7/2010 12:15:15 AM
On 07.01.2010 00:53, Dejan Stanic wrote:
>> {quote:title=Joanna Carter wrote:}{quote}
>> Maybe because, for the first time in around 20 years of using computers
>> I am actually enjoying the experience, not fighting with an unreliable
>> operating system.
>
> For me: enjoying means nice cigar, excellent cognac and great sex - not fiddling with a OS: that's work. Work I do for a living. Being 2 man shop that means market niches. And chasing percents of promilles of 3% market shares (see: http://www.systemshootouts.org/mac_sales.html) doesn't seem very sound plan.
>
> To each his own, I guess.
> Dejan

Wow! 2.5%
0
Ralf
1/7/2010 12:53:56 AM
> {quote:title=Rudy Velthuis (TeamB) wrote:}{quote}
> Captain Mockba wrote:
> 
> > > {quote:title=Joanna Carter wrote:}{quote}
> > > My estimation is that you just want to start yet another
> > > speculative thread because you are bored.
> > > 
> > > Joanna
> > 
> > I've been wondering... can't you just stay quiet if you have nothing
> > interesting and valuable to say?
> 
> I found it spot on, and therefore very valuable. <g>
> 
> 
> -- 
> Rudy Velthuis (TeamB)        http://www.teamb.com
> 

Birds of a feather flock together :P

I expect TeamB'ers respond technical questions instead of flamewars and such.
0
Gokhan
1/7/2010 1:08:50 AM
G?khan Ers#mer wrote:

> > > > My estimation is that you just want to start yet another
> > > > speculative thread because you are bored.
> > > 
> > > I've been wondering... can't you just stay quiet if you have
> > > nothing interesting and valuable to say?
> > 
> > I found it spot on, and therefore very valuable. <g>
> 
> Birds of a feather flock together :P
> 
> I expect TeamB'ers respond technical questions instead of flamewars
> and such.

I respond to what I think I should respond. This is a non-technical
group, after all.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If it were all so simple! If only there were evil people
 somewhere insidiously committing evil deeds, and it were
 necessary only to separate them from the rest of us and destroy
 them; but the line dividing good and evil cuts through the
 heart of every human being. And who is willing to destroy a
 piece of his own heart?"
 -- Aleksandr Solzhenitsyn
0
Rudy
1/7/2010 1:21:57 AM
Dejan Stanic wrote:

> > {quote:title=Joanna Carter wrote:}{quote}
> > Maybe because, for the first time in around 20 years of using
> > computers I am actually enjoying the experience, not fighting with
> > an unreliable operating system.
> 
> For me: enjoying means nice cigar, excellent cognac and great sex -
> not fiddling with a OS: that's work. 

Hmmm... I very much enjoy writing a good piece of code. And I'm not
very fond of cigars. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"His mother should have thrown him away and kept the stork." 
 -- Mae West
0
Rudy
1/7/2010 1:44:49 AM
> {quote:title=Ralf Stocker wrote:}{quote}
> On 07.01.2010 00:53, Dejan Stanic wrote:
> >> {quote:title=Joanna Carter wrote:}{quote}
> >> Maybe because, for the first time in around 20 years of using computers
> >> I am actually enjoying the experience, not fighting with an unreliable
> >> operating system.
> >
> > For me: enjoying means nice cigar, excellent cognac and great sex - not fiddling with a OS: that's work. Work I do for a living. Being 2 man shop that means market niches. And chasing percents of promilles of 3% market shares (see: http://www.systemshootouts.org/mac_sales.html) doesn't seem very sound plan.
> >
> > To each his own, I guess.
> > Dejan
> 
> Wow! 2.5%

And how much is Delphi's market share?  I'm just saying............
0
Phillip
1/7/2010 3:51:01 AM
"Dejan Stanic" wrote:
>
> For me: enjoying means nice cigar, excellent cognac and great sex - not 
> fiddling with a OS: that's work.

I can well relate to your concept of enjoyment!!!

Work I do for a living. Being 2 man shop that means market niches. And 
chasing percents of promilles of 3% market shares (see: 
http://www.systemshootouts.org/mac_sales.html) doesn't seem very sound plan.

Thanks for the excellent reference about Mac sales, I've already bookmarked 
it in my browser for future reference.

Lastly you taught me the name for a technical term (%%) I hadn't known 
before reading your message. ;-)
0
John
1/7/2010 5:08:00 AM
Phillip Woon wrote:

> > {quote:title=Ralf Stocker wrote:}{quote}
> > On 07.01.2010 00:53, Dejan Stanic wrote:
> > >> {quote:title=Joanna Carter wrote:}{quote}
> > >> Maybe because, for the first time in around 20 years of using
> > computers >> I am actually enjoying the experience, not fighting
> > with an unreliable >> operating system.
> > > 
> > > For me: enjoying means nice cigar, excellent cognac and great sex
> > > - not fiddling with a OS: that's work. Work I do for a living.
> > > Being 2 man shop that means market niches. And chasing percents
> > > of promilles of 3% market shares (see:
> > > http://www.systemshootouts.org/mac_sales.html) doesn't seem very
> > > sound plan.
> > > 
> > > To each his own, I guess.
> > > Dejan
> > 
> > Wow! 2.5%
> 
> And how much is Delphi's market share?  I'm just saying............



You mean out of that 2.5% ?
If yes, then I think the answer is nore or less 0%, or rather to be more precise it is 0% +/-0% .

Regards,
Zenon

Edited by: Zenon Jordan on Jan 6, 2010 10:18 PM
0
Zenon
1/7/2010 6:19:58 AM
I've made my hobby my work. And yes that means i'm sometimes writing code in 
my own time and having a good time doing so. (see www.pictoselector.eu as a 
result).

The benefit of spare time programming is the luxery of being user / chief / 
customer etc at the same time. In my work i have to meet goals of others. 
And work on projects i sometimes dislike.

And no, i don't like sigars/sigarettes :-)

Greetings, Martijn
0
Martijn
1/7/2010 9:06:16 AM
Ralf Stocker wrote:
> What will be the Delphi Project X Cross GUI ?
> 
> - Qt4
> - wxWindows
> - VCL 2.0
> - ???
> 
> What is your estimation?

I would say they are working on a Delphi MVC/MVP type framework.
Custom GUI wrappers for QT, Cocoa, Win32, etc would somehow be installed 
into the Delphi IDE to be used in the GUI designer. IOW you could have 
multiple dfm files to target your different platforms with native View 
controls. The Delphi IDE will manage the controller links to the GUI 
controls.

Anyways something along those lines..

Siegfried
0
Siegfried
1/7/2010 12:36:13 PM
Allen Bauer wrote:

> Luigi Sandon wrote:
> 
> > ... that Embarcadero will leave its customers in the total dark
> > until it will roll out a lame solution.
> 
> Wow, what faith. I'm touched.

All things considered, this is pretty mild for non-tech.  You could
deliver cross platform, native 64 bit and cold fusion (not CFM) in the
next release, and somebody will still complain.

Still, I wouldn't mind seeing some more blogging about what's going on.
A little peak behind the curtain here and there.

-- 
Regards,
Bruce McGee
Glooscap Software
0
Bruce
1/7/2010 1:59:04 PM
> Wow, what faith. I'm touched.

You're right. Till now we had "faith". And in exchange we often had pretty hard times. Many half-baked or broken solutions (localization, midas, the many internet framework attempts, dbExpress before 4, WS support, Indy, CLX, Eco, etc. etc.). You released a whole new remoting framework without ever thinking about *security* and how to plug it into a real enterprise network. 

Sorry if we lost "faith", and like St. Thomas, we would like to *see* before *believing*.

BorCodeDero reminds me how Western countries assessed USSR arsenal, looking at what was displayed on Red Square parades and trying to infer which weapons were ready and which were not, which technologies were known and which not, and trying to guess what was cooking under the cover.

Telling your customer now how you are going to implement xplat GUI will allow the to decide if Delphi will be *their* way to go xplat, or if their requirements need a different tool. For you nothing changes - those who won't find your xplat approach appealing will use other tools anyway - you avoid to turn hopeful customers into disgrunted ones later, you'll just allow them to plan their xplat future earlier and with the right knowledge - as it is expected by a technology partner. Instead you often work a
gainst your own customers, once it was SOX, not it is whatever else, and we don't understand why. We're just left unable to plan for our product future, that in turn it's often yours too.
0
Luigi
1/7/2010 4:39:33 PM
Am 07.01.2010 14:59, schrieb Bruce McGee:
> Allen Bauer wrote:
> 
>> Luigi Sandon wrote:
>>
>>> ... that Embarcadero will leave its customers in the total dark
>>> until it will roll out a lame solution.
>>
>> Wow, what faith. I'm touched.
> 
> All things considered, this is pretty mild for non-tech.  You could
> deliver cross platform, native 64 bit and cold fusion (not CFM) in the
> next release, and somebody will still complain.
> 
> Still, I wouldn't mind seeing some more blogging about what's going on.
> A little peak behind the curtain here and there.
> 

I suspect that as for previous versions they start blogging at a late
stage of the development process, otherwise it's simply too vague in
many cases. And they already blogged as much that clever readers would
get that they must be working on something for the Mac currently.

Greetings

Markus
0
Markus
1/7/2010 6:57:42 PM
Hello,

where did you get that knowledge from?

Greetings

Markus
0
Markus
1/7/2010 7:07:57 PM
Luigi Sandon wrote:

> > Wow, what faith. I'm touched.

> Telling your customer now how you are going to implement xplat GUI
> will allow the to decide if Delphi will be their way to go xplat, or
> if their requirements need a different tool. For you nothing changes
> - those who won't find your xplat approach appealing will use other
> tools anyway - you avoid to turn hopeful customers into disgrunted
> ones later, you'll just allow them to plan their xplat future earlier
> and with the right knowledge - as it is expected by a technology
> partner. Instead you often work a gainst your own customers, once it
> was SOX, not it is whatever else, and we don't understand why. We're
> just left unable to plan for our product future, that in turn it's
> often yours too.

I hate the lack of information too. I wish I could say more. But the
cold hard reality is that if we divulge too much too soon, sales of the
current product tank, layoffs happen, pay is cut and we are left with
less people, less time, and more work. I've seen it happen many times.
It sucks for us, it sucks for you.

As for the xplat plans, we're working hard to get something very usable
before we begin to divulge the details. Many of us were around for the
Kylix days and are fully aware of some of the problems with the
frameworks.

FWIW, Kylix was *very* successful... The problem was that it took way
too many resources from our core product, so it suffered. Also the
upper management forced us to price it a little too high for the market
at large. If Kylix were the only thing we did, it would be considered a
resounding success and it would probably stil be around.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/7/2010 7:08:07 PM
> cold hard reality is that if we divulge too much too soon, sales of the
> current product tank, layoffs happen, pay is cut and we are left with

That depends only on what each release delivers. If a release is just useful to fix the bugs of the previous two, and delivers very little more, yes, people will wait. I would have upgraded instantly if D2010 had a DCOM-free *real* remoting framework. Unluckily I need AD authentication/authorization and communication protection - which DCOM has. My company is still on D2007 and it's up to me to decide when to upgrade - or to switch to something else.

Because I can't see what direction Delphi is taking *really*, I have issue to decide what to do. Is upgrading to D2010 worth it? Should we go full Unicode with Delphi or wait, because if the direction it takes diverges from ours we could be forced switch to something else, and the expense of upgrading - including all third party tools used -, and updating code doesn't pay off? I don't know, and I am forced to plan defensively, because the risk is getting too high for us.

Maybe if you divulge too little too late, sales tank too, because you really ask for a "faith" that wasn't supported by "miracles" in the recent years.

> The problem was that it took way too many resources from our core product,

And you repeated this problem with Delphi.NET. Now Delphi developers need sound solutions and some real hints about the future of the tool, because it is becoming very difficult to "sell" it to upper management.
0
Luigi
1/7/2010 8:06:03 PM
"Luigi Sandon" wrote in message news:200738@forums.codegear.com...
> Because I can't see what direction Delphi is taking *really*, I have issue 
> to decide what to do.
....
> I don't know, and I am forced to plan defensively, because the risk is 
> getting too high for us.
>
> Maybe if you divulge too little too late, sales tank too, because you 
> really ask for a "faith" that
> wasn't supported by "miracles" in the recent years.

I agree.  If they dont give out an appropriate level of information about 
where the product is going, they face a more real risk of people having no 
choice but look elsewhere.  If someone wanted to start a project that they'd 
like to eventually make available for the mac or linux... do they use 
delphi, and wager their business on whether or not Embarc can deliver a mac 
version... or do they use C++, which they know would work today?  Without 
any real time frames or implementation info, they arent *helping* their 
customers to stay with them.
0
Joe
1/7/2010 8:45:13 PM
Luigi Sandon wrote:

> > cold hard reality is that if we divulge too much too soon, sales of
> > the current product tank, layoffs happen, pay is cut and we are
> > left with
> 
> That depends only on what each release delivers. If a release is just
> useful to fix the bugs of the previous two, and delivers very little
> more, yes, people will wait. I would have upgraded instantly if D2010
> had a DCOM-free real remoting framework. Unluckily I need AD
> authentication/authorization and communication protection - which
> DCOM has. My company is still on D2007 and it's up to me to decide
> when to upgrade - or to switch to something else.

Fair enough. We always know that only a certain percentage of the
customer base upgrades each cycle. If it's not a compelling upgrade for
you, I can respect that.
 
> Because I can't see what direction Delphi is taking really, I have
> issue to decide what to do. Is upgrading to D2010 worth it? Should we
> go full Unicode with Delphi or wait, because if the direction it
> takes diverges from ours we could be forced switch to something else,
> and the expense of upgrading - including all third party tools used
> -, and updating code doesn't pay off? I don't know, and I am forced
> to plan defensively, because the risk is getting too high for us.
> 
> Maybe if you divulge too little too late, sales tank too, because you
> really ask for a "faith" that wasn't supported by "miracles" in the
> recent years.

The opposite has been proven time and time again. I've not seen the
reverse be the case. We try and balance the level of detail we give
about future plans with our need to keep current sales as strong as
possible. In many ways, we try and only divulge enough information to
make sure we can *support* the sales of the curent release and not have
the opposite effect.

> > The problem was that it took way too many resources from our core
> > product,
> 
> And you repeated this problem with Delphi.NET. Now Delphi developers
> need sound solutions and some real hints about the future of the
> tool, because it is becoming very difficult to "sell" it to upper
> management.

If we were perfect, we wouldn't be having this conversation, no? :-). I
doubt anyone here can claim perfection either. I also don't think that
anyone elses' crystal ball is any more clear. Only time will tell
whether or not doing xplat proves to be wrong. Not that we're
"guessing" or "speculating" at all, but the ultimate test will be when
we look back at the decision.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/7/2010 8:59:59 PM
"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:200756@forums.codegear.com...
> reverse be the case. We try and balance the level of detail we give
> about future plans with our need to keep current sales as strong as
> possible. In many ways, we try and only divulge enough information to
> make sure we can *support* the sales of the curent release and not have
> the opposite effect.

Allen, your other post is exactly the kind of info I think helps the most. 
It shows a) there's active development and  b) the rationale about why 
you're doing what we already know you're doing.  You dont have to 
necessarily spill the beans about secrets... just provide insight so that 
people get a feeling for whats going on with the development tool their 
business depends on.

It might be somewhat different when targeting developers... but our company 
has always given a good deal of info about the releases in development.  If 
its far enough off, it doesnt affect sales, and if its close enough to 
release, we give a free upgrade to the new version when its released. 
Thats always worked for us, and truth be told, 90% of our customers arent 
paying attention and wont notice a new release until they get the email 
notice.  Honestly, preventing people from buying previous releases, not 
knowing there's a newer one, has traditionally been a bigger problem.
0
Joe
1/7/2010 9:32:36 PM
Allen,

Kudos for your posts today!

-- 

   Q

01/07/2010 14:08:02

XanaNews Version 1.19.1.236  [Not all my Mods]
0
Quentin
1/7/2010 10:10:16 PM
"Allen Bauer" wrote on Thu, 7 Jan 2010 11:08:07 -0800:

> I hate the lack of information too. I wish I could say more. But the
> cold hard reality is that if we divulge too much too soon, sales of the
> current product tank, layoffs happen, pay is cut and we are left with
> less people, less time, and more work. I've seen it happen many times.
> It sucks for us, it sucks for you.

That is a reasonable explanation, and anyone who markets products to 
end-users should be able to relate.

-- 
Better Web Sites Sell More Software: http://www.vexelfire.com

Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
0
Brandon
1/7/2010 10:22:22 PM
Hello,

Joe Demartino wrote:

> Allen, your other post is exactly the kind of info I think helps the
> most.  It shows a) there's active development and  b) the rationale
> about why you're doing what we already know you're doing.  You dont
> have to necessarily spill the beans about secrets... just provide
> insight so that people get a feeling for whats going on with the
> development tool their business depends on.

+1.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/7/2010 11:41:38 PM
Brandon Staggs wrote:

> "Allen Bauer" wrote on Thu, 7 Jan 2010 11:08:07 -0800:
> 
> > I hate the lack of information too. I wish I could say more. But the
> > cold hard reality is that if we divulge too much too soon, sales of
> > the current product tank, layoffs happen, pay is cut and we are
> > left with less people, less time, and more work. I've seen it
> > happen many times.  It sucks for us, it sucks for you.
> 
> That is a reasonable explanation, and anyone who markets products to 
> end-users should be able to relate.

If we had an annuity, like an OS or mainstream productivity
applications, that would consistently support our dev-tool efforts we
would not have to be as nearly "self-supporting."

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/7/2010 11:43:12 PM
Markus Humm wrote:

> where did you get that knowledge from?

Markus, To me "I would say they are..." implies an opinion, not
knowledge.
0
Doug
1/8/2010 12:38:09 AM
> If its far enough off, it doesnt affect sales, and if its close 
enough to
> release, we give a free upgrade to the new version when its released. 

+1

Eric
0
Eric
1/8/2010 7:33:42 AM
> If we had an annuity, like an OS or mainstream productivity
> applications, that would consistently support our dev-tool efforts we
> would not have to be as nearly "self-supporting."

If SA turned into a *real* maintenace program and support cycles get longer than six months, backporting important fixes to older releases that often need to be still in use, we would be happy to buy it and give you an "annuity". For example we pay for the Oracle OPN, but at least for all its duration we see real advantages that we didn't see when we bough SA. They don't support actively the latest release only.

Today SA is just a bet, and can hurt "early upgraders" because in the end all you get is the newer release, and if you get SA too early the next release can be rolled out when SA is expired and needs renewing - and at that point "cherry-picking" upgrades may become more economical.

Also promoting other Embarcadero applications like Interbase would be smart - right now not allowing the Pro sku to connect to remote IB servers just help cutting IB sales telling developers that is better to go to SQL Server and ADO, or use alternative libraries and use MySQL or Postgres.
0
Luigi
1/8/2010 8:41:16 AM
Am 07.01.2010 23:10, Quentin Correll wrote:
> Allen,
>
> Kudos for your posts today!
>

+1

-- 
Regards
Jens
0
Utf
1/8/2010 8:47:38 AM
Markus Humm wrote:
> Hello,
> 
> where did you get that knowledge from?
> 

 From my brain <g>

Siegfried
0
Siegfried
1/8/2010 9:39:30 AM
"James Smith"
> extjs or jquery

extjs rocks! delphi rules!

happy fishes!
http://prime.fmsoft.net/out/dbdemo.dll
0
Farshad
1/8/2010 12:31:36 PM
Luigi Sandon wrote:

> > If we had an annuity, like an OS or mainstream productivity
> > applications, that would consistently support our dev-tool efforts
> > we would not have to be as nearly "self-supporting."
> 
> If SA turned into a real maintenace program and support cycles get
> longer than six months, backporting important fixes to older releases
> that often need to be still in use, we would be happy to buy it and
> give you an "annuity". For example we pay for the Oracle OPN, but at
> least for all its duration we see real advantages that we didn't see
> when we bough SA. They don't support actively the latest release only.
> 
> Today SA is just a bet, and can hurt "early upgraders" because in the
> end all you get is the newer release, and if you get SA too early the
> next release can be rolled out when SA is expired and needs renewing
> - and at that point "cherry-picking" upgrades may become more
> economical.
> 
> Also promoting other Embarcadero applications like Interbase would be
> smart - right now not allowing the Pro sku to connect to remote IB
> servers just help cutting IB sales telling developers that is better
> to go to SQL Server and ADO, or use alternative libraries and use
> MySQL or Postgres.

Those are all excellent suggestions. I would recommend you contact
Michael Rozlog, the RAD Studio Product Manager, and voice your
suggestions. He needs to hear from as many of you as possible. If he
can come up with a plan and a business case that can clearly show a NET
positive gain, his life is much easier.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/8/2010 5:37:29 PM
Am 08.01.2010 01:38, schrieb Doug Chamberlin:
> Markus Humm wrote:
> 
>> where did you get that knowledge from?
> 
> Markus, To me "I would say they are..." implies an opinion, not
> knowledge.

Yes you are right. I just wanted to sort of force him to express this
more clearly. Nearly everybody here has opinions about nearly
everything, but they're mostly mood. Reality matters and in this case
you just can't know what they're up to until they tell you.

Greetings

Markus
0
Markus
1/8/2010 7:25:27 PM
Am 08.01.2010 10:39, schrieb Siegfried Niedinger:
> Markus Humm wrote:
>> Hello,
>>
>> where did you get that knowledge from?
>>
> 
>  From my brain <g>
> 
> Siegfried

So you've made it up. Ok.

Greetings and a nice snowy weekend

Markus
0
Markus
1/8/2010 7:25:52 PM
> 64-bit Delphi is the work on the new compiler architecture -- so that 

That's a separate issue. The compiler is just the first step. Anyway I would have preferred the actual compiler tweaked to support 64 bit with a 64 bit VCL - and later a redesigned compiler - than waiting a long time for a new compiler and a new VCL.

> I disagree. The value of cross-platform tools is that the SAME codebase 
> targets all platforms. The idea is that it should be possible to write 

That's the Holy Grail noone ever found - and noone will. Every attempt ended up in GUIs that look so-so or bad on every supported platform, or look alien on every platfom. There are still too many differences in widgets, underlying APIs and standards to use the same code, the amount of compromises needed is large enough to undermine the same meaning of "native" applications. And given the resources available at Embarcadero, I really wonder if they can even get close to the Grail.

> have to learn a new framework to target the Mac I'm not going to bother 

I think the opposite. Each platform I target needs its own native application. Sharing some code is good, but I do not care if I need to develop different interfaces to target the native GUI needed. If my application looks ugly on each supported platform, I have no advantage over true native applications.

> That's true ... but a good cross-platform framework can support the Mac 
> well enough -- and "well enough" is certainly better than "not at all", 

"Well enough" is in the eye of the beholder. What is will enough for you may not be for me, and I prefer not at all and have a state-of-the-art Windows tool that have a tool that is somewhat "well-enough" on several platforms but "very well" on none.
0
Luigi
1/8/2010 10:01:42 PM
> GUI that -- because it is non-standard -- is harder for end users to 
> learn.

What is standard on one platform may not be on others. Office features like ribbons and outlook grids and bars are pretty standard on Windows, but not on Linux. MacOS has its own standard. Each user expext his own standard.

> programmer is encouraged to concentrate on the business logic rather 
> than being distracted by obscure GUI 'tricks'. Good cross-platform 

The best business logic is almost useless if the user can't interact with it in the way he expects on his platform.

> developers using such tools generally don't customize further without 
> good reason.

The problem is what tools Delphi aims to be. Actually it is a tool capable of delivering failry complex native GUIs on Windows. Would turning it into a xplat Jack-of-all-trades-and-master-of.none be a smart move? Is it what Delphi developers needs? Delphi developers today are not xplat developers - if they don't use Java or C++/Qt there is a reason.
0
Luigi
1/8/2010 10:21:36 PM
Luigi Sandon wrote:
>> I disagree. The value of cross-platform tools is that the SAME codebase 
>> targets all platforms. The idea is that it should be possible to write 
> 
> That's the Holy Grail noone ever found - and noone will. Every attempt ended up in GUIs that look so-so or bad on every supported platform, or look alien on every platfom. There are still too many differences in widgets, underlying APIs and standards to use the same code, the amount of compromises needed is large enough to undermine the same meaning of "native" applications. And given the resources available at Embarcadero, I really wonder if they can even get close to the Grail.

I've been thinking about that issue a lot lately. For instance, I have 
been trying to standardize on Open Office for the past several years. 
There are lots of quirks that make me wonder if it was simply a bad 
design, or if the code was written to be x-plat. One example is that 
when I click on the shortcut (on Vista 64-bit Ultimate) for Writer, it 
opens hidden. I have to go hunt for it on my task bar, to make sure it 
opened, and bring it to the front. All other word processors/text 
editors open ready to use when I start the program.

That is only one example (there are others), and as stated, I'm not sure 
I can blame x-plat, I only suspect it.

Most x-plat programs I have used make me run screaming to pay money for 
something that feels more natural to use. The usability issue comes 
quickly to the fore. What's $100-200 for something that will save you 
5-10 minutes per day, plus reduce your anxiety/extend your life span?

I very much doubt that I will ever have ANY code that will cross compile 
on Windows and Mac (not ruling it entirely, however). The jury is still 
out whether I will actually create lite versions for the Mac. To me, 
that is much more intriguing than creating Linux versions. AFAIK, there 
is no product out there that allows me to use Pascal on Windows to 
create an application that runs on the Mac.

Loren sZendre
0
Loren
1/8/2010 10:27:21 PM
"Luigi Sandon" wrote in message news:201134@forums.codegear.com...
>> I disagree. The value of cross-platform tools is that the SAME codebase
>> targets all platforms. The idea is that it should be possible to write
>
> That's the Holy Grail noone ever found - and noone will.

I dont know why people keep on saying that.  QT is cross platform and *very* 
thorough.  wxWidgets is cross platform w/ native widgets.  Real Basic is 
cross platform (even if the IDE itself is limited).  FPC/Laz is cross 
platform... with interchangable gui toolkits to boot.  Heck, I maintain a 
WinCE/ARM app that I design and compile under windows using Lazarus.  About 
the only IDE that *cant* make cross platform (native) apps is Delphi.  And 
of course, all that completely ignores the countless C based, non-GUI 
libraries that can compile on virtually any platform with a c compiler.

This notion that an IDE cant be used to create apps that look good on each 
platform while using the same code base is simply nonsense.  Will there be 
tweaks to the code based on the platform?  Yes.  We do that now even for 
different versions of windows.  I dont think anyone is expecting 100%, line 
per line compatibiity.  But if it can get me 90-95% there... I certainly 
wouldnt mind tweaking the rest, as thats a world better than a complete 
re-write.
0
Joe
1/8/2010 10:41:36 PM
Loren Szendre wrote:

>  AFAIK, there 
> is no product out there that allows me to use Pascal on Windows to 
> create an application that runs on the Mac.

this is the point I have been thinking for while. 
People complaing about the Mac version, 
maybe where they see a problem actually exist an opportunity.


Cesar
0
Cesar
1/8/2010 10:43:48 PM
Joe Demartino wrote:
> I dont know why people keep on saying that.
> This notion that an IDE cant be used to create apps that look good on each 
> platform while using the same code base is simply nonsense.  Will there be 
> tweaks to the code based on the platform?  Yes.  We do that now even for 
> different versions of windows.  I dont think anyone is expecting 100%, line 
> per line compatibiity.  But if it can get me 90-95% there...

Sure, there are toolkits. But can any of them come even close to 
providing me what I can do with a combination of DevEx, TMS, RemObjects 
and TurboPower (my core component libraries)?

I'm not disagreeing with your point -- it's just that you have to look 
at the position of developers who have been using Delphi for years, and 
have availed themselves of its benefits. There's no way I'm going to be 
able to cross-compile any of my major apps. I cannot rip these amazing 
components out, and replace them with some x-plat widget set (as 
complete as it may seem) -- and end up at the same place.

Loren sZendre
0
Loren
1/8/2010 10:55:37 PM
"Loren Szendre" <zorenlendry@yahoo.com> wrote in message 
news:201156@forums.codegear.com...
> Sure, there are toolkits. But can any of them come even close to
> providing me what I can do with a combination of DevEx, TMS, RemObjects
> and TurboPower (my core component libraries)?
>
> I'm not disagreeing with your point -- it's just that you have to look
> at the position of developers who have been using Delphi for years, and
> have availed themselves of its benefits. There's no way I'm going to be
> able to cross-compile any of my major apps. I cannot rip these amazing
> components out, and replace them with some x-plat widget set (as
> complete as it may seem) -- and end up at the same place.

I concede that if the components arent available, you wont be able to port 
your app using those components.  But whats the alternative if you want a 
mac version?  The only alternative is a complete re-write in another 
language.  And you'd still not have those same components.  I'm under zero 
impression that I'll be able to take any of my apps and 'simply' re-compile 
them for macs.  Thats not going to happen.  But, if Delphi can get me 90% of 
the way there.... I'll only have 10% to do, as opposed to a 100% re-write in 
a language I'm less familiar with.  And if you dont want a mac version... 
just keep on using Windows specific code.

Plus, if a Delphi compiler for macs/linux/whatever is available, what makes 
you think DevEx, TMS, etc wouldnt port their components?  Esp when we're 
talking non visual components.  Unless their components are specifically 
designed for integrating into windows (something like D2D or shell 
integration), it should certainly be possible for most of them.  A grid is a 
grid... why wouldnt it be possible to port it?   Heck, there may even be 
opportunities for them to create components to make it easier for people to 
port their apps - how about some libraries that encapsulate OS features in a 
cross platform way?
0
Joe
1/8/2010 11:22:36 PM
In article <201134@forums.codegear.com>, Luigi Sandon wrote:
> > I disagree. The value of cross-platform tools is that the SAME
> > codebase targets all platforms. The idea is that it should be
> > possible to write 
> 
> That's the Holy Grail noone ever found - and noone will.

It's like those heavier-than-air flying machines -- nobody can make one, 
and noone ever will. <smile>

It may be that you don't happen to like the results that can be achieved 
with the current crop of cross-platform tools, but that doesn't mean 
that there aren't many people happily using applications that have been 
developed with those tools, or that it isn't possible to build better 
ones.

I think the likes of Qt and wx can produce very usable applications. 
They're not perfect in every respect, but I see that as an argument for 
improving the tools, not for decrying them as doomed to failure.

> > have to learn a new framework to target the Mac I'm not going to
> > bother 
> 
> I think the opposite. Each platform I target needs its own native
> application.

Does it? I don't know what sort of applications you write, but 90%+ of 
all applications I use have very basic GUIs that use only the common 
widgets that are available on every WIMP platform. Most of these are 
single-platform apps, but there's no reason to suppose that they 
couldn't have been written with a cross-platform toolkit. There's really 
no need to rewrite an application GUI for every one of those.

Cheers,
 Daniel.
0
Daniel
1/8/2010 11:23:40 PM
Joe Demartino wrote:
> I concede that if the components arent available, you wont be able to port 
> your app using those components.  But whats the alternative if you want a 
> mac version?  The only alternative is a complete re-write in another 
> language.  And you'd still not have those same components.  I'm under zero 
> impression that I'll be able to take any of my apps and 'simply' re-compile 
> them for macs.  Thats not going to happen.  But, if Delphi can get me 90% of 
> the way there....

Yeah, that's what I'm thinking. I may have to "dumb-down" some of the 
screens, but that won't keep me from re-using A LOT of code, when 
releasing a lite-version of Product X for the Mac.
> 
> Plus, if a Delphi compiler for macs/linux/whatever is available, what makes 
> you think DevEx, TMS, etc wouldnt port their components?

Believe me, I'm counting on it. I already have declarations from Marc 
Hoffman that I'll have TDAMemDataTable's equivalent on the Mac.

> Esp when we're 
> talking non visual components.  Unless their components are specifically 
> designed for integrating into windows (something like D2D or shell 
> integration), it should certainly be possible for most of them.  A grid is a 
> grid... why wouldnt it be possible to port it?

Well, a grid is a grid, until you start using DevEx's QuantumGrid. 
That's when you realize there are 2 classes of citizens in that world. 
Of course I would want them to port it. I'm sure it COULD be ported. The 
question is how much work would it take DevEx, and what is the ROI?

And by extension, what is my ROI for extending my apps to the Mac space? 
In the past 12 years, our company has had only 1 demo where having a Mac 
version was stated to be part of the decision making process. That fact 
doesn't negate that we could start actively pursuing that market, however.

Loren sZendre
0
Loren
1/8/2010 11:34:58 PM
Loren,

> Sure, there are toolkits. But can any of them come even close to
> providing me what I can do with a combination of DevEx, TMS, RemObjects
> and TurboPower (my core component libraries)?

I don't know which Turbo Power components you are using, but I'm trying 
to support all upcoming Delphi versions with Abbrevia, LockBox, OnGuard 
and Orpheus.

-- 
Roman
0
Roman
1/9/2010 8:35:33 AM
In article <201146@forums.codegear.com>, Luigi Sandon wrote:
> > GUI that -- because it is non-standard -- is harder for end users to 
> > learn.
> 
> What is standard on one platform may not be on others.

That's true ... and that's why a cross-platform framework should not try 
to produce applications that look the same on all platforms.

Java made that mistake in ... was it Swing? ... every app looks just 
like a crappy Swing app on every platform. That's no way to design for 
cross-platform.

Abstraction of GUI detail makes it possible to target multiple disparate 
platforms from a single codebase. You can write apps that are MDI in 
Windows but present multiple top-level Windows on linux (whose window 
managers typically don't support MDI idioms like child widows with top-
level style frames). You can write menu handling code that puts the menu 
of the application's window on Windows or linux, but uses the system 
menu at the top of the screen on a Mac. These are obvious large-scale 
examples, but you get the idea. A sufficiently well-designed cross-
platform framework can provide the native platform look and feel for 
basic applications on multiple platforms without the programmer having 
to customize the app for each one.

A small proportion of applications need to go beyond the basic UI 
manipulation that can easily be abstracted, and these applications will 
have to provide platform-specific code -- but even these can use the 
generic abstraction provided by a framework to do most of the leg-work.

> Office features like ribbons and outlook grids and bars are pretty
> standard on Windows, but not on Linux.

Office 2007 lookalike wannabees may use ribbons. They're hardly standard 
(they're not provided by the native Windows API widget set). The point 
about cross-platform frameworks is that they provide a platform-agnostic 
API for accessing the native widget set of each platform.

If you want to write an app with a ribbon you can do so ... but the 
ribbon will be part of your app's GUI -- which you can write using 
cross-platform tools if you want -- not something that a framework can 
abstract away.

> The problem is what tools Delphi aims to be. Actually it is a tool
> capable of delivering failry complex native GUIs on Windows. Would
> turning it into a xplat Jack-of-all-trades-and-master-of.none be a
> smart move?

I don't think that's the option that's on offer. cross-platform tools 
may not offer absolute mastery of all trades (to follow your analogy) 
but they (the good ones, at least) do most of the legwork without 
preventing you from refining the result if you want to. VCL doesn't 
offer mastery either.

> Is it what Delphi developers needs? Delphi developers
> today are not xplat developers - if they don't use Java or C++/Qt
> there is a reason.

Most Delphi developers are Delphi developers because the Delphi IDE is 
very good at making the process of designing and coding a GUI painless 
-- even pleasant -- and doesn't cost the earth. They don't care HOW 
Delphi does it, they care that it works.

Until recently Qt has been quite an expensive toolkit to use for 
anything but Free OS software so it's unreasonable to suggest that 
Delphi's relative popularity in commercial Windows software is due to 
any technical shortcoming of Qt's. 

Cheers,
 Daniel.
0
Daniel
1/9/2010 3:00:55 PM
Hello,

did you see/use Windows 7 yet?
Look at its paint application. it uses the ribbon now, even after I told
them in the beta cycle I don't like this idea! ;-)

Greetings

Markus
0
Markus
1/9/2010 5:19:54 PM
On 09.01.2010 18:19, Markus Humm wrote:
> Hello,
>
> did you see/use Windows 7 yet?
> Look at its paint application. it uses the ribbon now, even after I told
> them in the beta cycle I don't like this idea! ;-)
>
> Greetings
>
> Markus

Who needs Ribbon?
0
Ralf
1/9/2010 7:38:15 PM
Roman Kassebaum wrote:
> Loren,
> 
>> Sure, there are toolkits. But can any of them come even close to
>> providing me what I can do with a combination of DevEx, TMS, RemObjects
>> and TurboPower (my core component libraries)?
> 
> I don't know which Turbo Power components you are using, but I'm trying 
> to support all upcoming Delphi versions with Abbrevia, LockBox, OnGuard 
> and Orpheus.

I'm glad to hear that. LockBox is the most important for us, followed by 
SysTools, AsyncPro and OnGuard, in that order.

Loren sZendre
0
Loren
1/9/2010 7:41:02 PM
Loren,

> I'm glad to hear that. LockBox is the most important for us, followed by
> SysTools, AsyncPro and OnGuard, in that order.

LockBox is without GUI. It shouldn't be an issue to port it to other 
platforms.
Have you tried the OnGuard version from sourceforge? I only compiled it. 
I never worked with it.

-- 
Roman
0
Roman
1/9/2010 7:53:04 PM
Roman Kassebaum wrote:
>> I'm glad to hear that. LockBox is the most important for us, followed by
>> SysTools, AsyncPro and OnGuard, in that order.
> 
> LockBox is without GUI. It shouldn't be an issue to port it to other 
> platforms.
> Have you tried the OnGuard version from sourceforge? I only compiled it. 
> I never worked with it.

Haven't tried OnGuard in D2009+ yet. LockBox works fine in Unicodeville 
(and as you say, should smoothly port to other platforms). I've already 
ported (to D2009+) the barcode components that I need from SysTools -- 
and those components should go x-plat very easily, as I simply call the 
method that generates an image, and paint it onto a canvas for display 
or printing.

So, I look forward to seeing TCanvas on the Mac -- if the public end of 
TCanvas is identical to the version we all know and love, the it opens 
up a huge section of my code to be used on all platforms.

Loren sZendre
0
Loren
1/9/2010 9:28:19 PM
Loren,

> I've already
> ported (to D2009+) the barcode components that I need from SysTools --
> and those components should go x-plat very easily, as I simply call the
> method that generates an image, and paint it onto a canvas for display
> or printing.

I just looked at the sourceforge project. The zip-Archive is from 2005. 
Does it work with Unicode?

BTW, do you write you name Szendre or sZendre?

-- 
Roman
0
Roman
1/9/2010 10:55:06 PM
Roman Kassebaum wrote:
> Loren,
> 
>> I've already
>> ported (to D2009+) the barcode components that I need from SysTools --
>> and those components should go x-plat very easily, as I simply call the
>> method that generates an image, and paint it onto a canvas for display
>> or printing.
> 
> I just looked at the sourceforge project. The zip-Archive is from 2005. 
> Does it work with Unicode?

I'll check it out. It hasn't been a priority to get the entire SysTools 
library working in D2009+, since my early port works fine for us (for 
the apps that we have ported to D2009+, we only need a handful of the 
barcode components therefrom). But! I would love to have the entire 
library at my disposal, in D2009+ and for x-plat.

> BTW, do you write you name Szendre or sZendre?

Officially it's written Szendre. My Hungarian ancestors pronounced it 
"sen-dre" (Hungarian can only have an "s" sound using the "sz" 
diagraph). But since my more recent ancestors, in their journey to 
America, changed the pronunciation to "zen-dri" ("i" pronounced as in 
Latin), we sometimes try to help people know the "s" is silent (in our 
corrupted pronunciation :) ).

My brother took a recent trip to Hawaii, and met some Hungarians, who 
told him how to say it correctly. Now he's going around pronouncing it 
"correctly". So who knows...

loren szendre
0
Loren
1/9/2010 11:03:01 PM
> It's like those heavier-than-air flying machines -- nobody can make one, 

Or like faster-than-light machines? Standards across platforms can be so different framework can start to hit a barrier not easy to overcome - and the more the framework attempts to be fully xplat the more massive it becomes...

> that there aren't many people happily using applications that have been 
> developed with those tools, or that it isn't possible to build better 

I use Wireshark, but hate its GTK interface. I use Oracle SQL Developer where I can't have Quest SQL Navigator, but I hate its Java interface. At least they are free tools aimed at IT professionals. When average users are in play, delivering the proper interface may be what can make them buy.

> improving the tools, not for decrying them as doomed to failure.

They are just one approach to xplat. If you're a C developer without high GUI requirements they're ok. How much they can improve I do not know - it's not just a matter of widgets, is a matter of overall GUI design and workflow.
 
> Does it? I don't know what sort of applications you write, but 90%+ of 
> all applications I use have very basic GUIs that use only the common 

Most of the application I buy have failry complex GUIs with their own custom controls.
0
Luigi
1/9/2010 11:25:39 PM
> Abstraction of GUI detail makes it possible to target multiple disparate 
> platforms from a single codebase. You can write apps that are MDI in 

Let's see... there are so many subtle and not-so-subtle differences to take care.

> Office 2007 lookalike wannabees may use ribbons. They're hardly standard 
> (they're not provided by the native Windows API widget set). The point 

No. In Windows 7 ribbons are a standard API - and you may like it or not, but Office always set Windows interface standards well before Windows itself.

> about cross-platform frameworks is that they provide a platform-agnostic 
> API for accessing the native widget set of each platform.

There's something contradictory in what you wrote - who cares of an *agnostic* access to the *native set of each platform*? <G> There is the problem that the intersection of those sets is different from its union, and GUIs are much more than a set of widgets.

> ribbon will be part of your app's GUI -- which you can write using 
> cross-platform tools if you want -- not something that a framework can 
> abstract away.

So what shoud a framework abstract?
 
> preventing you from refining the result if you want to. VCL doesn't 
> offer mastery either.

Well, compare a VCL GUI and a Qt one... 
 
> -- even pleasant -- and doesn't cost the earth. They don't care HOW 
> Delphi does it, they care that it works.

Well, now I am very worried... I believed most developers where far better than VB coders, and cared about how Delphi works. Maybe I am wrong.
0
Luigi
1/9/2010 11:44:51 PM
I hope readers appreciate what a champion for TurboPower tools they have in Roman. These tools were once maintained by a team of developers who were paid to create them over a period of years, with technical support from Borland and with the advantage of a big group of active beta testers and users. Now consider that Roman is attempting to keep these valuable products viable pretty much by himself as a volunteer.

That's a grand goal of making these venerable tools work with all future versions of Delphi, although we don't have any idea really what that means. I suspect that it may be a pretty big challenge to many of the existing third party toolkits. I've ported a number of Delphi packages to Free Pascal and Lazarus and this was quite a challenge, not helped by my own deficiencies as a tool developer (I had never even created a custom component before) and the work-in-progress nature of the Lazarus LCL.

What works for Windows may not make sense on other platforms. Furthermore, it's possible that we're not the audience for Delphi X. As the inexorable shift to mobile computing continues, this will attract lots of new developers of all sorts to the various mobile platforms that emerge. That may be the real audience for Delphi X, not current Delphi users who are comfortable with VCL. Currently with mobile computing that starts with iPhone OS and to get there you have to go through OS X. The iPhone UI classes
 (UIWIndow, UIButton, etc.) are pretty close to the traditional OS X Cocoa NS classes (NSWindow, NSButton, etc.), but slimmed down and cleaned up, making them easier to use and understand. If you've worked with the NS classes, you're ready to work with the UI classes for iPhone OS. In fact, it wouldn't surprise me if Apple introduced the UI classes for OS X too at some point as a way to consolidate everything in one set of classes.

Part of me hopes that we don't get what we're wishing for, meaning a cross-platform VCL. The new group of mobile developers won't care about VCL and might even reject a tool that makes them use VCL. They want to use the UIAccelerometer class, not some wrapper surrogate.

Thanks.

-Phil


> {quote:title=Loren Szendre wrote:}{quote}
> Roman Kassebaum wrote:
> > Loren,
> > 
> >> Sure, there are toolkits. But can any of them come even close to
> >> providing me what I can do with a combination of DevEx, TMS, RemObjects
> >> and TurboPower (my core component libraries)?
> > 
> > I don't know which Turbo Power components you are using, but I'm trying 
> > to support all upcoming Delphi versions with Abbrevia, LockBox, OnGuard 
> > and Orpheus.
> 
> I'm glad to hear that. LockBox is the most important for us, followed by 
> SysTools, AsyncPro and OnGuard, in that order.
> 
> Loren sZendre
0
Phil
1/10/2010 1:08:44 AM
Farshad,

Most impressive!

For readers who are not quite sure what they're looking at here, what Farshad has done is create a Web app that is running compiled Delphi code (using ExtPascal classes) on the server. This Delphi app serves up the Ext JS JavaScript controls and additional JS code that's delivered as needed using Ajax techniques.

The only thing odd that jumps out at me from this app (and it's not Farshad's fault) is the excessive number of decimal digits for the fish length in inches that Borland stores in the biolife database. Either that's supposed to be a bit of a joke or somebody didn't understand significant digits. Anytime you see original data like this that's rounded to the nearest 10 (as in 50 cm, 150 cm, etc.) that means these are just rough estimates of the lengths (if not just wild-ass guesses). Accordingly, the values
 in inches should also be just rough estimates, with at most perhaps one decimal digit. 13 decimal digits is just so weird. What was Borland thinking? Can anyone offer a sane explanation?

Thanks.

-Phil


> {quote:title=Farshad Mohajeri wrote:}{quote}
> "James Smith"
> > extjs or jquery
> 
> extjs rocks! delphi rules!
> 
> happy fishes!
> http://prime.fmsoft.net/out/dbdemo.dll
0
Phil
1/10/2010 2:10:05 AM
> I use Wireshark, but hate its GTK interface. I use Oracle SQL
> Developer where I can't have Quest SQL Navigator, but I hate its Java
> interface.
SWT (widget-toolkit for Java, from Eclipse developers) is pretty good, 
since it uses native controls, not perfect but close, especially on Windows.
0
Utf
1/10/2010 2:39:24 AM
Hello,

Farshad Mohajeri wrote:

> extjs rocks! delphi rules!
> 
> happy fishes!
> http://prime.fmsoft.net/out/dbdemo.dll

how cool is that?

Now do I go to sleep, or do I check out ExtPascal? :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/10/2010 2:59:59 AM
For best results, I would suggest starting with the SVN files for ExtPascal since SVN now includes the wrappers for Ext JS already generated so you don't have to do that. Even though that step was documented and easy to do, it eluded some users, so Wanderlan is now just including the wrapper classes in ExtPascal. All you need really then is the latest 3.1.0 Ext JS (www.extjs.com) and a Web server.

There's also an optional toolkit for ExtPascal included in SVN that includes a fmtoextp converter that you can use to convert existing Delphi .dfm files to ExtPascal code. As a proof of concept you might use this on an existing VCL app.  If you're using VCL controls that are supported by ExtPascal, you'll likely have very quickly a working Web app, albeit without any actual server code yet, mostly just the basic UI, which will resemble your desktop app in look. That might be one way of easing into ExtPasc
al. 

svn checkout http://extpascal.googlecode.com/svn/trunk/ [your_folder]

Thanks.

-Phil


> {quote:title=Moritz Beutel wrote:}{quote}
> Hello,
> 
> Farshad Mohajeri wrote:
> 
> > extjs rocks! delphi rules!
> > 
> > happy fishes!
> > http://prime.fmsoft.net/out/dbdemo.dll
> 
> how cool is that?
> 
> Now do I go to sleep, or do I check out ExtPascal? :)
> 
> -- 
> Moritz
> 
> "Hey, it compiles! Ship it!"
0
Phil
1/10/2010 3:19:05 AM
"Phil Hess" wrote in message news:201455@forums.codegear.com...
> For best results, I would suggest starting with the SVN files for 
> ExtPascal since SVN now includes the wrappers for Ext JS already generated 
> so you don't have to do that. Even though that step was documented and 
> easy to do, it eluded some users, so Wanderlan is now just including the 
> wrapper classes in ExtPascal. All you need really then is the latest 3.1.0 
> Ext JS (www.extjs.com) and a Web server.

Looks really interesting!

Thanks.

-d
0
Dennis
1/10/2010 3:41:30 AM
Here's Wanderlan's on-line ExtPascal demo:

http://extpascal.call.inf.br/cgi-bin/extpascalsamples.cgi

With each example, you can click the Show Source Code button to see that Pascal code behind it. He's using a CodePress widget that supports syntax highlighting to show the source. Normally you wouldn't post the Pascal source on your server but he's doing it here to show that there's nothing too complicated about it all.

This demo is actually a bit out of date. The current SVN version now has file upload and download examples too.

Thanks.

-Phil


> {quote:title=Dennis Landi wrote:}{quote}
> "Phil Hess" wrote in message news:201455@forums.codegear.com...
> > For best results, I would suggest starting with the SVN files for 
> > ExtPascal since SVN now includes the wrappers for Ext JS already generated 
> > so you don't have to do that. Even though that step was documented and 
> > easy to do, it eluded some users, so Wanderlan is now just including the 
> > wrapper classes in ExtPascal. All you need really then is the latest 3.1.0 
> > Ext JS (www.extjs.com) and a Web server.
> 
> Looks really interesting!
> 
> Thanks.
> 
> -d
0
Phil
1/10/2010 4:02:37 AM
Phil Hess wrote:

> I hope readers appreciate what a champion for TurboPower tools they
> have in Roman. These tools were once maintained by a team of
> developers who were paid to create them over a period of years, with
> technical support from Borland and with the advantage of a big group
> of active beta testers and users. Now consider that Roman is
> attempting to keep these valuable products viable pretty much by
> himself as a volunteer.

I couldn't agree more.  Roman has been simply amazing and has made an
incalcuable contribution to the Delphi community.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/10/2010 4:24:01 AM
Nick Hodges wrote:
> I couldn't agree more.  Roman has been simply amazing and has made an
> incalcuable contribution to the Delphi community.

May he live a thousand years!

Loren sZendre
0
Loren
1/10/2010 4:54:50 AM
Phil Hess a écrit :

> Part of me hopes that we don't get what we're wishing for, meaning a
> cross-platform VCL. The new group of mobile developers won't care
> about VCL and might even reject a tool that makes them use VCL. They
> want to use the UIAccelerometer class, not some wrapper surrogate.

FMPOV, even if X-VCL gives us UI wrappers for controls, what would 
happen to the concept of Cocoa bindings? Using Interface Builder to 
specify bindings is really simple and so powerful, compared with having 
to write code to connect up ontrols to properties of objects manually.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/10/2010 7:58:48 AM
Loren,

> I'll check it out. It hasn't been a priority to get the entire SysTools
> library working in D2009+, since my early port works fine for us (for
> the apps that we have ported to D2009+, we only need a handful of the
> barcode components therefrom). But! I would love to have the entire
> library at my disposal, in D2009+ and for x-plat.

The version from Sebastian, you can find it under 
http://www.songbeamer.com/delphi/ seems to work with D2009+.
Maybe, you can compare the barcode component with yours and if necessary 
merge them.
Then someone can update the "official" version on sourceforge.
I think the whole community and Nick will be very happy about this.


> Officially it's written Szendre. My Hungarian ancestors pronounced it
> "sen-dre" (Hungarian can only have an "s" sound using the "sz"
> diagraph). But since my more recent ancestors, in their journey to
> America, changed the pronunciation to "zen-dri" ("i" pronounced as in
> Latin), we sometimes try to help people know the "s" is silent (in our
> corrupted pronunciation :) ).
>
> My brother took a recent trip to Hawaii, and met some Hungarians, who
> told him how to say it correctly. Now he's going around pronouncing it
> "correctly". So who knows...

Thank you very much for the explanation. I was confused cause the forum 
user was "Szendre" but you signed with "sZendre".

On my passport my name is written "Kaßebaum" with small letters and 
"KASSEBAUM" with big letters. The reason is that a German "ß" doesn't 
exist as a capital letter.

> loren szendre

LOL.

-- 
Roman
0
Roman
1/10/2010 8:41:23 AM
Phil,

> I hope readers appreciate what a champion for TurboPower tools they have in Roman. These tools were once maintained by a team of developers who were paid to create them over a period of years, with technical support from Borland and with the advantage of a big group of active beta testers and users. Now consider that Roman is attempting to keep these valuable products viable pretty much by himself as a volunteer.

these a very friendly words. Thank you very much.
But please don't forget that I'm not doing the work alone. I have a lot 
of help from Sebastian, Craig, Quentin, Nick, yourself and maybe in the 
future from Loren.

-- 
Roman
0
Roman
1/10/2010 8:45:55 AM
Am 09.01.2010 20:38, schrieb Ralf Stocker:
> On 09.01.2010 18:19, Markus Humm wrote:
>> Hello,
>>
>> did you see/use Windows 7 yet?
>> Look at its paint application. it uses the ribbon now, even after I told
>> them in the beta cycle I don't like this idea! ;-)
>>
>> Greetings
>>
>> Markus
> 
> Who needs Ribbon?

I didn't say one needs it, but it's implemented by MS now!
So it seems to be included in the standard API somehow now or at least
MS compiler's solution has been used which would be even worse: sort of
declaring ribbons a new standard but not providing a API in the OS itsself.

Greetings

Markus
0
Markus
1/10/2010 9:34:38 AM
Markus Humm a écrit :

> did you see/use Windows 7 yet?
> Look at its paint application. it uses the ribbon now, even after I told
> them in the beta cycle I don't like this idea! ;-)

I would question how you can have a cross-platform UI library that 
allows a developer to design a Windos app with a ribbon and "simply 
recompile" it to work on OS X?

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/10/2010 10:12:44 AM
Hello,

thank you for elaborating on this!

As you see, I decided for sleeping yesterday :) I'll look at ExtPascal
later this day.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/10/2010 12:19:11 PM
Am 10.01.2010 11:12, schrieb Joanna Carter:
> Markus Humm a écrit :
> 
>> did you see/use Windows 7 yet?
>> Look at its paint application. it uses the ribbon now, even after I told
>> them in the beta cycle I don't like this idea! ;-)
> 
> I would question how you can have a cross-platform UI library that 
> allows a developer to design a Windos app with a ribbon and "simply 
> recompile" it to work on OS X?
> 
> Joanna
> 

Why? If that framework implements the whole ribbon stuf on Mac OS X on
its own this would work. And don't tell me this couldn't be done if
enough effort is invested!
(I'm not saying I'd need that!)

Greetings

Markus
0
Markus
1/10/2010 12:42:25 PM
Markus Humm a écrit :

> Why? If that framework implements the whole ribbon stuf on Mac OS X on
> its own this would work. And don't tell me this couldn't be done if
> enough effort is invested!
> (I'm not saying I'd need that!)

I suppose that's, sort of, my point. Unless someone is prepared to 
"emulate" what are presently single-platform compoents, it's never going 
to be a "simple recompile".

So, for most apps, that is going to mean devolving down to the lowest 
common denominator of UI controls.

Joanna

-- 
Joanna Carter [TeamB|http://www.teamb.com]
Consultant Software Engineer
0
Joanna
1/10/2010 1:06:10 PM
> {quote:title=Joanna Carter wrote:}{quote}
> Phil Hess a écrit :
> 
> > Part of me hopes that we don't get what we're wishing for, meaning a
> > cross-platform VCL. The new group of mobile developers won't care
> > about VCL and might even reject a tool that makes them use VCL. They
> > want to use the UIAccelerometer class, not some wrapper surrogate.
> 
> FMPOV, even if X-VCL gives us UI wrappers for controls, what would 
> happen to the concept of Cocoa bindings? Using Interface Builder to 
> specify bindings is really simple and so powerful, compared with having 
> to write code to connect up ontrols to properties of objects manually.
> 
> Joanna
> 

Right, Cocoa rules. But with Delphi X we don't even know yet what kind of interface to Cocoa it will have. Will it be via some third party product like Qt? Or a bridge? Or extensions to the language itself (like what they did years ago to fit better with Windows)?

The Free Pascal boys have taken the radical step of creating a new Objective Pascal dialect to support ObjC (and thus Cocoa classes).

http://wiki.freepascal.org/FPC_PasCocoa

This is going all the way, with few compromises. And it allows a parser to generate the ObjP classes from the ObjC header files all in one swoop. The result is a single unit, CocoaAll, that has all the Cocoa classes. A similar parser does the same thing for the iPhone UI classes, producing the iPhoneAll unit.

Look at the NoNib .zip file here for a simple app that uses the CocoaAll unit. As a proof of concept it does not use any .nib files, but of course they can also be used:

http://web.fastermac.net/~MacPgmr/Lazarus/

A little readme.txt file is included if you're interested in compiling this yourself.

Note that this app uses only two units: CocoaAll and SysUtils. Yet it's a full-fledged Cocoa app.

The question is how radical a step Codegear is going to take with Delphi X.

Thanks.

-Phil
0
Phil
1/10/2010 3:38:25 PM
In article <201516@forums.codegear.com>, Joanna Carter wrote:
> I suppose that's, sort of, my point. Unless someone is prepared to 
> "emulate" what are presently single-platform compoents, it's never
> going to be a "simple recompile".

That's true, of course: Unless the framework provides its own platform
-specific implementation of widgets that are not available on a given 
platform it can only provide a complete abstraction of the widgets that 
are available on all the platforms it covers.

Going back to the ribbon: The ribbon may be a standard widget in Win7 
but certainly isn't in Vista and earlier versions of Windows -- so an 
application that wished to use a ribbon would have to provide the 
implementation unless it limited itself to Win7. That implementation 
could be provided (on, say, XP as well as linux/Mac/whatever) using the 
primitives found in a cross-platform toolkit, which would make it 
cross-platform too.

I'm not sure that I'd want to do that, though. Nobody really expects to 
see a ribbon on a non-Windows platform. Better to use the cross-
platform toolkit to built a non-ribbon GUI that works everywhere, and 
build a specialization that provides a ribbon Windows (only) if you 
feel it's needed.

> So, for most apps, that is going to mean devolving down to the lowest 
> common denominator of UI controls.

That would be the case with the most basic of frameworks, yes, but it 
ain't necessarily so.

No, the cross-platform toolkit should provide a basic framework for 
each platform it supports and that framework should provide an API that 
enables client apps to access the GUI functionality without having to 
know or care quite how that GUI is presented. That doesn't mean that 
all platforms get only the lowest common denominator, but may mean that 
some features are not available on some platforms if those platforms 
don't support all the GUI mechanisms abstracted by the framework.

So, going back to the ribbon again, a (hypothetical) framework might 
provide a means to describe a ribbon as well as means to describe menus 
and toolbars. On Windows the default might be to produce an application 
that displayed a ribbon, while on another system the default might give 
a menu and a toolbar, and on a third system there might be no way to 
display a toolbar so the default would give a menu only. What's more, 
the programmer might be able to specify that the user should be able to 
configure the application on Windows to use a menu and a toolbar 
instead of (or as well as) a ribbon. After all, it's usual in pre-
ribbon applications to be able to turn toolbars on/off, why not the 
ribbon as well? If other GUIs later provided their own native 
implementations of the ribbon, then it would be trivially easy to add 
ribbon support to the applications on those platforms as soon as the 
framework provided ribbon support on those platforms.

What certainly *is* true is that a cross-platform toolkit can only 
provide abstractions of the widgets that it knows about, but it can 
know about -- and abstract -- widgets that are not supported on all the 
platforms it supports.

Cheers,
 Daniel.
0
Daniel
1/10/2010 4:08:55 PM
In article <201420@forums.codegear.com>, Luigi Sandon wrote:
> > about cross-platform frameworks is that they provide a platform-
> > agnostic API for accessing the native widget set of each platform.
> 
> There's something contradictory in what you wrote - who cares of an
> *agnostic* access to the *native set of each platform*? <G>

I don't see any contradiction there. The framework provides an API that 
the application uses to control the GUI, but the actual actions of the 
API calls vary appropriately from platform to platform. The framework 
presents the same API to the application on all platforms, but the 
actual implementation of that API is platform specific, and behaves 
appropriately for the target system.

So, the API is platform-agnostic (the application doesn't have to know 
or care what the target system is) but the implementation behind that 
API uses the platform's native widget set in the conventional way for 
the platform.

> ... GUIs are much more than a set of widgets.

Indeed they are, which is why cross-platform toolkits are complex 
frameworks ... if it were just a matter of switching widgets you'd only 
need a bunch of macros.

> > They don't care HOW Delphi does it, they care that it works.
> 
> Well, now I am very worried... I believed most developers where far
> better than VB coders, and cared about how Delphi works. Maybe I am
> wrong.

You're missing the point. I didn't mean that developers don't care how 
Delphi works during the process of coding with Delphi, I meant that they 
didn't choose Delphi over other tools because of the way that it works; 
they chose it because it *does* work, and then learnt about how.

Cheers,
 Daniel.
0
Daniel
1/10/2010 4:08:56 PM
Luigi Sandon wrote:

> I use Wireshark, but hate its GTK interface. I use Oracle SQL Developer where I can't have Quest SQL Navigator, but I hate its Java interface. At least they are free tools aimed at IT professionals. When average users are in play, delivering the proper interface may be what can make them buy.
I would say don't use these tools!

Have you looked at RealBASIC. It is monolithic but still very usable and 
truly xplat in all manner. It supports Win/Mac/Linux. It is better than 
Delphi in all way for anyone who is looking for a way to build multiple 
platform apps sitting/woring in Windows.

Of course for Delphi die hards like you there is FPC with MSDE to 
develop xplat apps.
0
Yogi
1/11/2010 4:56:56 AM
Phil Hess wrote:
> 
> For readers who are not quite sure what they're looking at here, what Farshad has done is create a Web app that is running compiled Delphi code (using ExtPascal classes) on the server. This Delphi app serves up the Ext JS JavaScript controls and additional JS code that's delivered as needed using Ajax techniques.
> 
> The only thing odd that jumps out at me from this app (and it's not Farshad's fault) is the excessive number of decimal digits for the fish length in inches that Borland stores in the biolife database. Either that's supposed to be a bit of a joke or somebody didn't understand significant digits. Anytime you see original data like this that's rounded to the nearest 10 (as in 50 cm, 150 cm, etc.) that means these are just rough estimates of the lengths (if not just wild-ass guesses). Accordingly, the valu
es
>  in inches should also be just rough estimates, with at most perhaps one decimal digit. 13 decimal digits is just so weird. What was Borland thinking? Can anyone offer a sane explanation?

Thanks for this detailed explanation.

I think everyone interested in xplat should link with Mark Wood on 
LinkedIn. I am just astonished to see as to how his company has 
exploited various open source tools like FPC, XUL, etc. and close source 
tools like Delphi to build solutions that work xplat quietly.

Check out their web site. http://www.timeandmotion.com.au/. This site 
requires QuickTime.

LinnkedIn url: http://au.linkedin.com/in/woodmark

Here are a few discussion to follow for those you are interested:

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1290947&discussionID=9790599&goback=.anh_1290947

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=2065753&discussionID=8375042&goback=.anb_2065753_*2.anh_2065753

HTH
0
Yogi
1/11/2010 6:29:45 AM
Am 10.01.2010 09:41, Roman Kassebaum wrote:
> On my passport my name is written "Kaßebaum" with small letters and
> "KASSEBAUM" with big letters. The reason is that a German "ß" doesn't
> exist as a capital letter.

You mean "didn't" ;).

http://en.wikipedia.org/wiki/Capital_%C3%9F

-- 
Regards
Jens
0
Utf
1/11/2010 11:45:34 AM
Jens,

>> On my passport my name is written "Kaßebaum" with small letters and
>> "KASSEBAUM" with big letters. The reason is that a German "ß" doesn't
>> exist as a capital letter.
> 
> You mean "didn't" ;).
> 
> http://en.wikipedia.org/wiki/Capital_%C3%9F

if I may quote the German version 
(http://de.wikipedia.org/wiki/Gro%C3%9Fes_%C3%9F):

"Sie ist nicht Bestandteil der offiziellen deutschen Rechtschreibung."

-- 
Roman
0
Roman
1/11/2010 11:54:39 AM
Am 11.01.2010 12:54, Roman Kassebaum wrote:
>
> "Sie ist nicht Bestandteil der offiziellen deutschen Rechtschreibung."
>

Ok, I overlooked that. Maybe with the next "Rechtschreibreform".

-- 
Regards
Jens
0
Utf
1/11/2010 12:06:24 PM
Am 11.01.2010 13:06, schrieb Jens Mühlenhoff:
> Am 11.01.2010 12:54, Roman Kassebaum wrote:
>>
>> "Sie ist nicht Bestandteil der offiziellen deutschen Rechtschreibung."
>>
> 
> Ok, I overlooked that. Maybe with the next "Rechtschreibreform".
> 

Hopefully not. No big use in even extending this!
And I also hope the french circumflex dies. The only meaning I knot it
has is, that there was a letter s some day at this place. But historic
letters s which aren't used any more and aren't pronunced are simply one
thing: historic and thus shouldn't burden present people learning french
(and not even french residents! ;-) )

Greetings

Markus
0
Markus
1/11/2010 6:31:36 PM
"Yogi Yang" <yogiyang007@gmail.com> wrote in message 
news:201698@forums.codegear.com...
> Have you looked at RealBASIC. It is monolithic but still very usable and

I tried realbasic.  I really tried.  The problem is, while the language 
itself is fine and pretty complete and cross platform, its IDE is painfully 
limiting.  You can only see one function at a time, for example.  And since 
its code isnt kept in plain text files, you cant even edit it with an 
outside editor.
0
Joe
1/11/2010 7:45:37 PM
Markus,

> Hopefully not. No big use in even extending this!

I try to avoid the "ß" in my name. IMO it is simply wrong.

-- 
Roman Kassebaum
0
Roman
1/11/2010 8:10:26 PM
Jens,

> Ok, I overlooked that. Maybe with the next "Rechtschreibreform".

I really hope that there will be no next "Rechtschreibreform". :-)

-- 
Roman
0
Roman
1/11/2010 8:12:20 PM
Roman Kassebaum wrote:

> Markus,
> 
> > Hopefully not. No big use in even extending this!
> 
> I try to avoid the "ß" in my name. IMO it is simply wrong.

How is it pronounced? Does the first part rhyme on Maße or on Masse?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Shaw's Principle: Build a system that even a fool can use, and 
only a fool will want to use it.
0
Rudy
1/11/2010 8:22:14 PM
Roman Kassebaum wrote:
> On my passport my name is written "Kaßebaum" with small letters and 
> "KASSEBAUM" with big letters. The reason is that a German "ß" doesn't 
> exist as a capital letter.

I thought that s-set was neither capital nor lower case, as it exists as 
a single code-point. It's certainly tall enough to not look out of place 
when a word is all-caps.

Loren sZendre
0
Loren
1/11/2010 8:34:40 PM
Rudy,

> How is it pronounced? Does the first part rhyme on Maße or on Masse?

Masse.
My name is a simple concatenation of "Kasse" and "Baum".

-- 
Roman
0
Roman
1/11/2010 8:35:15 PM
Loren,

> I thought that s-set was neither capital nor lower case, as it exists as
> a single code-point. It's certainly tall enough to not look out of place
> when a word is all-caps.

In German orthography the "ß" is lower case.

-- 
Roman
0
Roman
1/11/2010 8:38:38 PM
Roman Kassebaum wrote:

> Rudy,
> 
> > How is it pronounced? Does the first part rhyme on Maße or on Masse?
> 
> Masse.
> My name is a simple concatenation of "Kasse" and "Baum".

Then an ß would indeed give people the wrong pronunciation.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There are very few monsters who warrant the fear we have of
 them."
 -- Andre Gide
0
Rudy
1/11/2010 10:13:06 PM
Loren Szendre wrote:

> Roman Kassebaum wrote:
> > On my passport my name is written "Kaßebaum" with small letters and 
> > "KASSEBAUM" with big letters. The reason is that a German "ß"
> > doesn't exist as a capital letter.
> 
> I thought that s-set was neither capital nor lower case, as it exists
> as a single code-point. 

It is lower case. 
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"How wrong it is for a woman to expect the man to build the world 
 she wants, rather than to create it herself."
 -- Anais Nin (1903-1977)
0
Rudy
1/11/2010 10:14:39 PM
Rudy Velthuis (TeamB) wrote:
>>> How is it pronounced? Does the first part rhyme on Maße or on Masse?
>> Masse.
>> My name is a simple concatenation of "Kasse" and "Baum".
> 
> Then an ß would indeed give people the wrong pronunciation.

Why? Es-set is a simple orthographic replacement, and never modifies the 
word phonologically or morphologically (I believe it can never cross 
morpheme boundaries).

Loren sZendre
0
Loren
1/11/2010 10:24:46 PM
Loren Szendre wrote:

> Rudy Velthuis (TeamB) wrote:
> >>> How is it pronounced? Does the first part rhyme on Maße or on
> Masse?  >> Masse.
> >> My name is a simple concatenation of "Kasse" and "Baum".
> > 
> > Then an ß would indeed give people the wrong pronunciation.
> 
> Why? Es-set is a simple orthographic replacement

No, it isn't. An ß in words like Maße, Straße, Fuß, etc. means the
preceding vowel must be pronounced long. If the ß is replaced by double
s, it is pronounced short (e.g. Masse [*]). The same for Kaßebaum and
Kassebaum. They are pronounced differently. But some older spellings
use ß where it should be ss, and this can cause mispronunciations (e.g.
there is a street here called Roßheidestraße, although the o in Roß -
horse - is pronounced short. In the new orthography, it ought to be
Rossheidestraße, but the new orthography does not apply to names).

----- 
[*] Maße = measures, measurements; Masse = mass. They are pronounced
differently and they have different meanings.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Democracy is where you can say what you think even if you don't 
 think."
0
Rudy
1/11/2010 10:51:05 PM
Rudy Velthuis (TeamB) wrote:
> Loren Szendre wrote:
> 
>> Rudy Velthuis (TeamB) wrote:
>>>>> How is it pronounced? Does the first part rhyme on Maße or on
>> Masse?  >> Masse.
>>>> My name is a simple concatenation of "Kasse" and "Baum".
>>> Then an ß would indeed give people the wrong pronunciation.
>> Why? Es-set is a simple orthographic replacement
> 
> No, it isn't. An ß in words like Maße, Straße, Fuß, etc. means the
> preceding vowel must be pronounced long. If the ß is replaced by double
> s, it is pronounced short (e.g. Masse [*]).

Thanks for the explanation. I'll have to get out my Duden. I took German 
long before I learned the principles of linguistics, so I'll have to 
rethink some of my long-held assumptions.

One last question: if you are using, say an old American typewriter, and 
you have to represent "Straße", you couldn't type "Strase", because that 
would be pronounced "shtraza" -- so are you saying there is no way to 
represent the word in Americangelese without the s-set? For instance, we 
can replace "ä" with "ae" (even in German, I believe).

Loren sZendre
0
Loren
1/11/2010 11:12:44 PM
Hello,

Loren Szendre wrote:

> One last question: if you are using, say an old American typewriter,
> and you have to represent "Straße", you couldn't type "Strase",
> because that would be pronounced "shtraza" -- so are you saying there
> is no way to represent the word in Americangelese without the s-set?
> For instance, we can replace "ä" with "ae" (even in German, I
> believe).

you can substitute 'ß' with 'ss' in such cases.

FWIW, the Swiss always do that:
http://en.wikipedia.org/wiki/%C3%9F#Switzerland_and_Liechtenstein

-- 
Moritz

"I don't go off-topic. Others do." -- Rudy Velthuis
0
Moritz
1/11/2010 11:19:07 PM
Loren Szendre wrote:

> Rudy Velthuis (TeamB) wrote:
> > Loren Szendre wrote:
> > 
> >> Rudy Velthuis (TeamB) wrote:
> >>>>> How is it pronounced? Does the first part rhyme on Maße or on
> >> Masse?  >> Masse.
> >>>> My name is a simple concatenation of "Kasse" and "Baum".
> >>> Then an ß would indeed give people the wrong pronunciation.
> >> Why? Es-set is a simple orthographic replacement
> > 
> > No, it isn't. An ß in words like Maße, Straße, Fuß, etc. means the
> > preceding vowel must be pronounced long. If the ß is replaced by
> > double s, it is pronounced short (e.g. Masse [*]).
> 
> Thanks for the explanation. I'll have to get out my Duden. I took
> German long before I learned the principles of linguistics, so I'll
> have to rethink some of my long-held assumptions.
> 
> One last question: if you are using, say an old American typewriter,
> and you have to represent "Straße", you couldn't type "Strase",
> because that would be pronounced "shtraza" -- so are you saying there
> is no way to represent the word in Americangelese without the s-set?

Once again, it is es-zet. And if you don't have an ß, like the Swiss,
you use ss, but it makes things a little harder to read. Words like
Strasse would not be a problem, but words like Masse would. You'd have
to get the meaning (and pronunciation) from the context.

FWIW, Straße is pronounced "shtra'suh", not "shtra'sa"

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Everything secret degenerates, even the administration of 
 justice." -- Lord Acton
0
Rudy
1/11/2010 11:30:15 PM
Joe Demartino wrote:
> "Yogi Yang" <yogiyang007@gmail.com> wrote in message 
> news:201698@forums.codegear.com...
>> Have you looked at RealBASIC. It is monolithic but still very usable and
> 
> I tried realbasic.  I really tried.  The problem is, while the language 
> itself is fine and pretty complete and cross platform, its IDE is painfully 
> limiting.  You can only see one function at a time, for example.  And since 
> its code isnt kept in plain text files, you cant even edit it with an 
> outside editor.
Which version of RealBasic did you try? I still use Version 5.5 Pro 
edition and it works just fine for me. I have never tried the latest 
versions. I think there should be some way to show code in all 
procedures & functions in newer versions.
0
Yogi
1/12/2010 4:53:22 AM
Markus Humm schrieb:

> And I also hope the french circumflex dies. The only meaning I knot it
> has is, that there was a letter s some day at this place.

And this knowledge IMO is very helpful when coming from other (Roman) 
languages (Latin, Italian...).

DoDi
0
Hans
1/12/2010 5:41:28 AM
Loren Szendre schrieb:

> One last question: if you are using, say an old American typewriter, and 
> you have to represent "Straße", you couldn't type "Strase", because that 
> would be pronounced "shtraza" -- so are you saying there is no way to 
> represent the word in Americangelese without the s-set? For instance, we 
> can replace "ä" with "ae" (even in German, I believe).

I've learned a couple of replacements for the "ß" in German writing, 
like "sz" and "hs". These replacements look somewhat similar in older 
fonts, and their ligatures may be the root of the "ß". The "sz" also may 
be a (wrong) decomposition of the old and phonetically closest "hs" 
ligature, resulting from an attempt to mimic its look in an different font.

DoDi
0
Hans
1/12/2010 5:41:31 AM
Rudy,

>> Masse.
>> My name is a simple concatenation of "Kasse" and "Baum".
>
> Then an ß would indeed give people the wrong pronunciation.

You are absolutely right. The "ß" is simply wrong (Have you ever seen 
the work "Kaße" in a supermarket?). I don't know the fool who began to 
write my name in this way. Unfortunately today it is official.

-- 
Roman
0
Roman
1/12/2010 6:03:00 AM
Am 11.01.2010 21:12, Roman Kassebaum wrote:
> Jens,
>
>> Ok, I overlooked that. Maybe with the next "Rechtschreibreform".
>
> I really hope that there will be no next "Rechtschreibreform". :-)
>

Me too, actually ;D.

-- 
Regards
Jens
0
Utf
1/12/2010 10:56:18 AM
Jens Mühlenhoff schrieb:

>>> Ok, I overlooked that. Maybe with the next "Rechtschreibreform".
>> I really hope that there will be no next "Rechtschreibreform". 
>>
> 
> Me too, actually ;D.

According to the latest argumentation (see "aufwändig"), it most 
probably will come as "Raechtschreibreform", because it derives from 
"Rache". The empire strikes back! ;-)

DoDi
0
Hans
1/12/2010 4:11:21 PM
"Yogi Yang" <yogiyang007@gmail.com> wrote in message 
news:202109@forums.codegear.com...
>> I tried realbasic.  I really tried.  The problem is, while the language
>> itself is fine and pretty complete and cross platform, its IDE is 
>> painfully
>> limiting.  You can only see one function at a time, for example.  And 
>> since
>
> Which version of RealBasic did you try? I still use Version 5.5 Pro

The current one.  I really like the concept, but limiting the editor to one 
function at a time is downright painful.  How do you build classes like 
that?  And no, there's practical way to edit entire code files.  There's an 
export, which really doesnt help.  That makes it very, very limiting to 
anything other than trivial apps.

And dont even get me started on the documentation.  F1 brings up a pdf, not 
a help file.  Though there is a help file for the language... its not very 
fleshed out.

If it had a command line compiler, or a better IDE, and some other tweaks to 
appeal to the more hardcore programmers, I'd say they would have a winner 
and Delphi would have a serious competitor.  But as is, not so much.
0
Joe
1/12/2010 10:43:56 PM
Allen,

On Thu, 07 Jan 2010 19:08:07 -0000, Allen Bauer  
<abauer@spicedham.codegear.com> wrote:

> I hate the lack of information too. I wish I could say more. But the
> cold hard reality is that if we divulge too much too soon, sales of the
> current product tank, layoffs happen, pay is cut and we are left with
> less people, less time, and more work.

ISTR a couple of years ago - when you were still Borland/DevCo/CodeGear -  
we were constantly told that everyone in the company wished they could say  
more (or even produce a roadmap) but we customers would just have to be  
patient.

Back then, of course, the sole impediment was that nasty SOX legislation.

   "Autres temps, Autres moeurs" ?   Or is it just  "Same old, Same old" ?


Turning your statement round, surely your management cannot think that  
giving /less/ information to your customers, will /increase/ the  
likelihood of them of them buying upgrades and /decrease/ the chances of  
them looking elsewhere for a longterm solution that they can rely on?

-- 
Paul Scott
Information Management Systems
Macclesfield, UK
0
Paul
1/17/2010 6:49:10 PM
Paul Scott wrote:

>surely your management cannot think that  
>giving less information to your customers, will increase the  
>likelihood of them of them buying upgrades and decrease the chances
>of them looking elsewhere for a longterm solution that they can rely
>on?

Indeed, for now the roadmap has lead us to buying the cheapest 2010
without SA. SA is a waste of money as we estimated there ain't going to
be a 64bit release before sept 2010.

Right now the only thing glueing us to delphi is our large delphi
codebase and the promise of a delphi 64 bit compiler..
0
Marius
1/17/2010 11:07:57 PM
> {quote:title=Eric Grange wrote:}{quote}
> > Wow, what faith. I'm touched.
> 
> Well between CLX and the amount of UI glitches that can be found in the 
> Delphi IDE (flickering, misalignments, etc.) or the UI behaviors 
> tolerated from the new help (laggyness, flickerings, impractical 
> layouts...), there is certainly a lot of trust you have to rebuild as 
> far as GUIs are concerned, at every level of it.

(gee, and I thought that previous experience with Kylix and Delphi.NET at least had corrected the unrealistic expectations that everything should run, always, with only a push on the button)
0
Marco
1/18/2010 2:29:36 PM
Paul Scott wrote:

> Allen,
> 
> On Thu, 07 Jan 2010 19:08:07 -0000, Allen Bauer  
> <abauer@spicedham.codegear.com> wrote:
> 
> > I hate the lack of information too. I wish I could say more. But the
> > cold hard reality is that if we divulge too much too soon, sales of
> > the current product tank, layoffs happen, pay is cut and we are
> > left with less people, less time, and more work.
> 
> ISTR a couple of years ago - when you were still
> Borland/DevCo/CodeGear - we were constantly told that everyone in the
> company wished they could say more (or even produce a roadmap) but we
> customers would just have to be patient.
> 
> Back then, of course, the sole impediment was that nasty SOX
> legislation.
> 
>    "Autres temps, Autres moeurs" ?   Or is it just  "Same old, Same
> old" ?
> 
> 
> Turning your statement round, surely your management cannot think
> that giving less information to your customers, will increase the  
> likelihood of them of them buying upgrades and decrease the chances
> of them looking elsewhere for a longterm solution that they can rely
> on?

My point is that there is a balance that has to be maintained.
Sometimes we get it right, but many times we err on the side of
caution. You cannot "unrelease" a roadmap that gives away information
that stalls current sales.

I do know that as the new owners and management get more and more
comfortable (remember, they're only 1.5 years into owning a product
line with >25 year history) with the customer base and the product,
things will change.

Because Delphi is such a key peice of the company's strategy over the
next few years, we have to be extremely diligent about when and what we
divulge. Not only are our customers listening for this information, so
too are the competitors.

Unlike Borland, Delphi is no longer an afterthought or footnote in the
company's strategic vision. We're no longer the whipping boy of
quarterly reports. Now it is, "How can we leverage and build on the
Delphi (RAD Studio) product, community, etc...?" There are many irons
in the fire with several key projects and teams spooled up throughout
the company. While not all of them are directly working *on* Delphi(RAD
Studio) the product, it is involved in some manner. Given that, we
*are* very careful to ensure we don't do *anything* that would hinder,
or even give the perception of hindering, current sales.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 7:18:27 PM
Allen Bauer wrote:
> Paul Scott wrote:
> 
>> Allen,
> Studio) the product, it is involved in some manner. Given that, we
> *are* very careful to ensure we don't do *anything* that would hinder,
> or even give the perception of hindering, current sales.
> 


All that you've said is well and good, and I'm happy to hear all of it 
(even those parts I may not agree with).  HOWEVER, there are times that 
you may want to consider 'hindering' current sales, if you can make the 
case that it will enhance future sales.  A blip of a couple of months on 
current sales in order to enhance a year or more of future sales would 
seem to be a valid trade-off.

David Erbas-White
0
David
1/18/2010 8:15:13 PM
Working for a recent startup company which created a product and then 6 
months
on told customers about it's big brother which hadn't quite been finished 
and
almost died when sales dried up due to people waiting for the big brother, I 
can
fully understand this.
Rgds Pete

"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:204108@forums.codegear.com...
> Paul Scott wrote:
>
>> Allen,
>>
>> On Thu, 07 Jan 2010 19:08:07 -0000, Allen Bauer
>> <abauer@spicedham.codegear.com> wrote:
>>
>> > I hate the lack of information too. I wish I could say more. But the
>> > cold hard reality is that if we divulge too much too soon, sales of
>> > the current product tank, layoffs happen, pay is cut and we are
>> > left with less people, less time, and more work.
>>
>> ISTR a couple of years ago - when you were still
>> Borland/DevCo/CodeGear - we were constantly told that everyone in the
>> company wished they could say more (or even produce a roadmap) but we
>> customers would just have to be patient.
>>
>> Back then, of course, the sole impediment was that nasty SOX
>> legislation.
>>
>>    "Autres temps, Autres moeurs" ?   Or is it just  "Same old, Same
>> old" ?
>>
>>
>> Turning your statement round, surely your management cannot think
>> that giving less information to your customers, will increase the
>> likelihood of them of them buying upgrades and decrease the chances
>> of them looking elsewhere for a longterm solution that they can rely
>> on?
>
> My point is that there is a balance that has to be maintained.
> Sometimes we get it right, but many times we err on the side of
> caution. You cannot "unrelease" a roadmap that gives away information
> that stalls current sales.
>
> I do know that as the new owners and management get more and more
> comfortable (remember, they're only 1.5 years into owning a product
> line with >25 year history) with the customer base and the product,
> things will change.
>
> Because Delphi is such a key peice of the company's strategy over the
> next few years, we have to be extremely diligent about when and what we
> divulge. Not only are our customers listening for this information, so
> too are the competitors.
>
> Unlike Borland, Delphi is no longer an afterthought or footnote in the
> company's strategic vision. We're no longer the whipping boy of
> quarterly reports. Now it is, "How can we leverage and build on the
> Delphi (RAD Studio) product, community, etc...?" There are many irons
> in the fire with several key projects and teams spooled up throughout
> the company. While not all of them are directly working *on* Delphi(RAD
> Studio) the product, it is involved in some manner. Given that, we
> *are* very careful to ensure we don't do *anything* that would hinder,
> or even give the perception of hindering, current sales.
>
> -- 
> Allen Bauer
> Embarcadero Chief Scientist
> http://blogs.embarcadero.com/abauer
0
Pete
1/18/2010 8:16:53 PM
David Erbas-White wrote:

> Allen Bauer wrote:
> > Paul Scott wrote:
> > 
> >> Allen,
> > Studio) the product, it is involved in some manner. Given that, we
> > are very careful to ensure we don't do anything that would hinder,
> > or even give the perception of hindering, current sales.
> > 
> 
> 
> All that you've said is well and good, and I'm happy to hear all of
> it (even those parts I may not agree with).  HOWEVER, there are times
> that you may want to consider 'hindering' current sales, if you can
> make the case that it will enhance future sales.  A blip of a couple
> of months on current sales in order to enhance a year or more of
> future sales would seem to be a valid trade-off.

Tell that to the investors who are expecting that we reach a certain
level of earnings. Or how about all the bank convenants that suddenly
become very onerous if we don't quite make the agreed upon earnings
level?

It's like telling your mortgage company, "Hey, I'm not going to be
making that mortgage payment for a few months while I 'invest' in that
new car, m-kay?"

I know it's not quite the same thing, but the analog is still there.
And, yeah, yeah, investors are "short-sighted buffoons..." But, guess
what? They're the investors. It was their money. They get to place
conditions on its use. They don't usually care what the company
strategy is, or whether or not some "long term bet" is going to pay
off. They don't want to be involved in the day-to-day operations. They
invested in the company believing that the leadership will protect
their investment. They've *already* taken their risk by investing. They
don't want to hear that there is suddenly more risk than what they
originally signed up for.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 8:35:58 PM
Allen Bauer wrote:
> 
> Tell that to the investors who are expecting that we reach a certain
> level of earnings. Or how about all the bank convenants that suddenly
> become very onerous if we don't quite make the agreed upon earnings
> level?
> 

That's a huge one, point taken...

> 
> I know it's not quite the same thing, but the analog is still there.
> And, yeah, yeah, investors are "short-sighted buffoons..." But, guess
> what? They're the investors. It was their money. They get to place
> conditions on its use. They don't usually care what the company
> strategy is, or whether or not some "long term bet" is going to pay
> off. They don't want to be involved in the day-to-day operations. They
> invested in the company believing that the leadership will protect
> their investment. They've *already* taken their risk by investing. They
> don't want to hear that there is suddenly more risk than what they
> originally signed up for.
> 


I'm more looking at the situation that missing a quarterly target to 
enhance an annual target may be the 'prudent' move.  I'm not suggesting 
making anything riskier, just to change the perspective slightly.

David Erbas-White
0
David
1/18/2010 8:50:42 PM
David Erbas-White wrote:

> Allen Bauer wrote:
> > Paul Scott wrote:
> > 
> >> Allen,
> > Studio) the product, it is involved in some manner. Given that, we
> > are very careful to ensure we don't do anything that would hinder,
> > or even give the perception of hindering, current sales.
> > 
> 
> 
> All that you've said is well and good, and I'm happy to hear all of
> it (even those parts I may not agree with).  HOWEVER, there are times
> that you may want to consider 'hindering' current sales, if you can
> make the case that it will enhance future sales.

A bird in the hand is worth two in the bush (in Dutch, we even say 10
in the bush).

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If Stupidity got us into this mess, then why can't it get us 
 out?" -- Will Rogers (1879-1935)
0
Rudy
1/18/2010 9:02:31 PM
David Erbas-White wrote:

> Allen Bauer wrote:
> > 
> 
> I'm more looking at the situation that missing a quarterly target to 
> enhance an annual target may be the 'prudent' move.  I'm not
> suggesting making anything riskier, just to change the perspective
> slightly.

*If*, and this is a *big if*, we felt it was a 'prudent' move *and*
could prove with reasonable certainty that the end result would be
better for all involved, we could present this case directly to the
investors and banks. The problem is reasonably assuring them of greater
returns, putting together a presentation and then negotiating what an
acceptible "missed target" would be. Knowing now how these things all
happen, given my involvment with all the negotiations surrounding the
sale of CodeGear, this could easily take the better part of a quarter
or more to even get buy-in from all the interested parties. At that
point, there is a chance that the immediate opportunity may have
already passed by :-(.

That is of course *if* they would even entertain the notion or engage
in the conversation. The *best* course of action would be to operate
within the framework given to the best of our ability. This may
sometimes mean that we have to make some unpopular short-term decisions.

All this doesn't mean we make all our decisions in a vacuum. Far from
it. There are a lot of customers that we seek direct feedback from on a
regular basis. Most of the time these are in the form of NDA breifings
and round-tables. Our CEO, Wayne Williams, is *rarely* in the office
because he's out visiting customers and talking about our long term
strategy and goals.

This can be a two-edged sword. It's *great* that our top guy is that
involved with making sure our customers are properly served and is
listening to their feedback. However, it can also cause a few hiccups
for the dev teams since there have been times where we've plotted
course in one direction and based on the feedback we're having to do
some mid-course corrections.

At least our sales and marketing organizations can actually *spell*
Delphi and RAD Studio! Contrast that with the last years at Borland
where a front-line sales guy would be reprimanded and *not* given
commission on a Delphi sale! No matter how large or even if it was
unsolicited! How f**** up was that!?

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 9:21:59 PM
"David Erbas-White" <derbas@arachneering.com> wrote in message
> I'm more looking at the situation that missing a quarterly target to
> enhance an annual target may be the 'prudent' move.  I'm not suggesting
> making anything riskier, just to change the perspective slightly.

Plus, that makes the assumption that giving info out harms sales in the 
first place.  They havent sold that to me yet.  One could equally speculate 
that by being overly secretive, they're driving sales away because 
developers will want a sense of security about the future of the dev tool 
they choose to invest in.  The thing to keep looking at is that Delphi went 
from a main stream development tool to a very niche product over about 5 
years - while taking the current 'secretive' approach.

Another thing to keep in mind... there's no mac or (active) linux delphi 
compiler.  So they wouldnt be harming sales of their mac and linux compiler 
if they released more info about them.  If anything, they'd be keeping 
people from jumping ship.

Also... Could it be that releases are just too frequent?  A yearly release 
is a pretty fast pace.  I can understand Embarc wanting to get a new release 
or two out the door to show they're on the ball with their new aquisition... 
but if upgrades are really hurt by announcements of the next version... 
maybe thats because new versions are so frequent that people can wait? 
Perhaps its time to slow things down, and have less frequent releases that 
have more pronounced changes, making the incentive to upgrade more evident? 
Its one thing to put off an upgrade for a few months, but another to put it 
off a few years.

One more commment - the concern seems to be for losing 'upgrades'.  All well 
and good, but if they are so reliant on upgrades (or what I like to call, 
milking their customers), perhaps its an indicator they arent forcusing 
enough on reaching new customers.
0
Joe
1/18/2010 9:39:29 PM
Joe Demartino wrote:

> "David Erbas-White" <derbas@arachneering.com> wrote in message
> > I'm more looking at the situation that missing a quarterly target to
> > enhance an annual target may be the 'prudent' move.  I'm not
> > suggesting making anything riskier, just to change the perspective
> > slightly.
> 
> Plus, that makes the assumption that giving info out harms sales in
> the first place.

Ever heard that car sales slow down a lot and people must be enticed to
buy a car by reducing prices when a new model is announced? This is a
similar situation.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If you pray for rain long enough, it eventually does fall. If
 you pray for floodwaters to abate, they eventually do. The same
 happens in the absence of prayers."
 -- Steve Allen
0
Rudy
1/18/2010 9:49:39 PM
Rudy Velthuis (TeamB) wrote:
> Joe Demartino wrote:
> 
>> "David Erbas-White" <derbas@arachneering.com> wrote in message
>>> I'm more looking at the situation that missing a quarterly target to
>>> enhance an annual target may be the 'prudent' move.  I'm not
>>> suggesting making anything riskier, just to change the perspective
>>> slightly.
>> Plus, that makes the assumption that giving info out harms sales in
>> the first place.
> 
> Ever heard that car sales slow down a lot and people must be enticed to
> buy a car by reducing prices when a new model is announced? This is a
> similar situation.


I've heard that the major cause of sales slowdowns for GM was that they 
decided not to produce a 64-bit automobile, thus forcing sales to Toyota...

David Erbas-White
0
David
1/18/2010 9:55:09 PM
Joe Demartino wrote:

> "David Erbas-White" <derbas@arachneering.com> wrote in message
> > I'm more looking at the situation that missing a quarterly target to
> > enhance an annual target may be the 'prudent' move.  I'm not
> > suggesting making anything riskier, just to change the perspective
> > slightly.
> 
> Plus, that makes the assumption that giving info out harms sales in
> the first place.  They havent sold that to me yet.  One could equally
> speculate that by being overly secretive, they're driving sales away
> because developers will want a sense of security about the future of
> the dev tool they choose to invest in.  The thing to keep looking at
> is that Delphi went from a main stream development tool to a very
> niche product over about 5 years - while taking the current
> 'secretive' approach.
> 
> Another thing to keep in mind... there's no mac or (active) linux
> delphi compiler.  So they wouldnt be harming sales of their mac and
> linux compiler if they released more info about them.  If anything,
> they'd be keeping people from jumping ship.

It's part of the overall product line, so it *does* affect it.
 
> Also... Could it be that releases are just too frequent?  A yearly
> release is a pretty fast pace.  I can understand Embarc wanting to
> get a new release or two out the door to show they're on the ball
> with their new aquisition...  but if upgrades are really hurt by
> announcements of the next version...  maybe thats because new
> versions are so frequent that people can wait?  Perhaps its time to
> slow things down, and have less frequent releases that have more
> pronounced changes, making the incentive to upgrade more evident?
> Its one thing to put off an upgrade for a few months, but another to
> put it off a few years.

Again, we have to balance out the needs of customers, the evoloving
marketplace, the shifting technologies, and our overriding need to keep
the lights on and continue producing product. We can only plan ahead by
looking at past data and performance. Of course, we all would *love* to
see that sudden unforseen "spike", but you have to make your plans and
budgets based on what you know about the past performance.
 
> One more commment - the concern seems to be for losing 'upgrades'.
> All well and good, but if they are so reliant on upgrades (or what I
> like to call, milking their customers), perhaps its an indicator they
> arent forcusing enough on reaching new customers.

You're free to believe this or not, however the perspective from *my*
side of the fence is markedly different. Too much information, too
early *does* hinder sales of the current release. As I've already
stated, I've literally seen this play out on several occasions, and it
ain't pretty...

I do take issue with the notion of "milking the customer." We provide a
new version, and you're free to buy the upgrade or not. You're under no
obligation to purchase. Our job is to make it *compelling* enough for
you to purchase. Sounds like a business to me. If you consider us
taking advantage of the fact that a portion of the customer base
*chooses* of their own volition to upgrade to every new release, then,
you got us... we're profiting from their choices. I would also assume
that they got something of value in return; a shiney new product
release.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 9:56:16 PM
Rudy Velthuis (TeamB) wrote:

> Joe Demartino wrote:
> 
> > "David Erbas-White" <derbas@arachneering.com> wrote in message
> > > I'm more looking at the situation that missing a quarterly target
> > > to enhance an annual target may be the 'prudent' move.  I'm not
> > > suggesting making anything riskier, just to change the perspective
> > > slightly.
> > 
> > Plus, that makes the assumption that giving info out harms sales in
> > the first place.
> 
> Ever heard that car sales slow down a lot and people must be enticed
> to buy a car by reducing prices when a new model is announced? This
> is a similar situation.

OMG!! It's the dreaded "software is the same as a car" analogy! Yep,
sometimes it works (but let's not tell Nick, ok? ;-).

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 9:57:29 PM
"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
news:204162@forums.codegear.com...
> Ever heard that car sales slow down a lot and people must be enticed to
> buy a car by reducing prices when a new model is announced? This is a
> similar situation.

Ever hear of Microsoft giving out its beta of Windows 7 to anyone who wanted 
it for a *year* prior to release, so that the positive buzz it generated 
would help sales?

Plus, note that car manufacturers DO announce and publicize their new models 
well before they come out, and display many proof-of-concept vehicles at 
trade shows and in the media (mosf of us have been hearing about the Chevy 
Volt now for 5 years...).  So they obviously think any decrease in sales are 
worth it.
0
Joe
1/18/2010 10:05:57 PM
"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
news:204167@forums.codegear.com...
> early *does* hinder sales of the current release. As I've already
> stated, I've literally seen this play out on several occasions, and it
> ain't pretty...

The trouble with that is I cant recall Borland/CodeGear/Embar ever taking 
the 'open' approach.  Someone already pointed out that before this line of 
thinking ('we cant tell you or it will risk sales'), we got the 'we cant 
tell you because of SOX' line for a number of years.  And over those years, 
Delphi went from mainstream to niche.

> I do take issue with the notion of "milking the customer." We provide a
> new version, and you're free to buy the upgrade or not. You're under no

I didnt mean it in a negative way - just that by relying on upgrades as 
opposed to new sales is a long term losing strategy as people eventually 
bail out for various reasons (retirement, changing requirements, etc).
0
Joe
1/18/2010 10:14:55 PM
David Erbas-White wrote:
> Rudy Velthuis (TeamB) wrote:
>> Ever heard that car sales slow down a lot and people must be enticed
>> to buy a car by reducing prices when a new model is announced? This
>> is a similar situation.
> 
> I've heard that the major cause of sales slowdowns for GM was that
> they decided not to produce a 64-bit automobile, thus forcing sales
> to Toyota... 

<ROTFLMAO> That's got to be 10 out of 10!

Mattias
0
Mattias
1/18/2010 10:37:10 PM
Joe Demartino wrote:

> "Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
> news:204167@forums.codegear.com...
> > early does hinder sales of the current release. As I've already
> > stated, I've literally seen this play out on several occasions, and
> > it ain't pretty...
> 
> The trouble with that is I cant recall Borland/CodeGear/Embar ever
> taking the 'open' approach.  Someone already pointed out that before
> this line of thinking ('we cant tell you or it will risk sales'), we
> got the 'we cant tell you because of SOX' line for a number of years.
> And over those years, Delphi went from mainstream to niche.

We've *never* played "fast and loose" with the whole kimono, however
I've seen plenty of times where a little more "peek" here and there did
have an effect.
 
> > I do take issue with the notion of "milking the customer." We
> > provide a new version, and you're free to buy the upgrade or not.
> > You're under no
> 
> I didnt mean it in a negative way - just that by relying on upgrades
> as opposed to new sales is a long term losing strategy as people
> eventually bail out for various reasons (retirement, changing
> requirements, etc).

I cannot disagree with you. That is why we're working on some
strategies company wide to target new customers.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 10:40:04 PM
Allen Bauer wrote:

> Yep,
> sometimes it works (but let's not tell Nick, ok? ;-).

It' /never/ works.  Hodges Law (much like Godwin's law) states that
anyone who invokes an analogy about cars relating to the software
business automatically loses the argument.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/18/2010 10:40:20 PM
Joe Demartino wrote:

> Ever hear of Microsoft giving out its beta of Windows 7 to anyone who
> wanted it for a year prior to release, so that the positive buzz it
> generated would help sales?

We are a completely, totally different business than Microsoft.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/18/2010 10:40:51 PM
Allen Bauer wrote:

>  Too much information, too
> early does hinder sales of the current release. As I've already
> stated, I've literally seen this play out on several occasions, and it
> ain't pretty...

This is utterly, definitely, completely true.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/18/2010 10:41:26 PM
"Nick Hodges" <nick.hodges@codegear.com> wrote in message 
news:204190@forums.codegear.com...
> Joe Demartino wrote:
>
>> Ever hear of Microsoft giving out its beta of Windows 7 to anyone who
>> wanted it for a year prior to release, so that the positive buzz it
>> generated would help sales?
>
> We are a completely, totally different business than Microsoft.

As are car manufacturers - I was just countering Rudy's point with a counter 
example.
0
Joe
1/18/2010 10:43:02 PM
David Erbas-White wrote:

> I've heard that the major cause of sales slowdowns for GM was that
> they decided not to produce a 64-bit automobile, thus forcing sales
> to Toyota...

Yeah, right.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"It is the job of thinking people not to be on the side of the
 executioners." -- Albert Camus
0
Rudy
1/18/2010 10:44:47 PM
Allen Bauer wrote:

> > > Plus, that makes the assumption that giving info out harms sales
> > > in the first place.
> > 
> > Ever heard that car sales slow down a lot and people must be enticed
> > to buy a car by reducing prices when a new model is announced? This
> > is a similar situation.
> 
> OMG!! It's the dreaded "software is the same as a car" analogy! 

I'm so terribly sorry. <g>

> Yep, sometimes it works (but let's not tell Nick, ok? ;-).

<making zipping gesture across mouth and turning gesture at corner of
mouth>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"In general the art of government consists in taking as much
 money as possible from one class of citizens to give to the
 other."
 -- Voltaire
0
Rudy
1/18/2010 10:44:48 PM
Joe Demartino wrote:

> "Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
> news:204162@forums.codegear.com...
> > Ever heard that car sales slow down a lot and people must be
> > enticed to buy a car by reducing prices when a new model is
> > announced? This is a similar situation.
> 
> Ever hear of Microsoft giving out its beta of Windows 7 to anyone who
> wanted it for a year prior to release, so that the positive buzz it
> generated would help sales?

Yes, because Vista sales were already on a low level, and they can
bundle their software with hardware, which is not something others can
do. <g>


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"University politics are vicious precisely because the stakes 
 are so small." -- Henry Kissinger (1923-)
0
Rudy
1/18/2010 10:44:52 PM
Joe Demartino wrote:

> "Allen Bauer" <abauer@spicedham.codegear.com> wrote in message 
> news:204167@forums.codegear.com...
> > early does hinder sales of the current release. As I've already
> > stated, I've literally seen this play out on several occasions, and
> > it ain't pretty...
> 
> The trouble with that is I cant recall Borland/CodeGear/Embar ever
> taking the 'open' approach.

I can. They have opened up considerably already. In the old days, you
did not see discussions like this one, with people from Borland
discussing their motives, at all.

That they opened up does not mean they should disclose everything YOU
would like to know. As Allen said, they have to consider more than just
your desire for information, things you apparently don't (have to)
consider.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If you put tomfoolery into a computer, nothing comes out of it 
 but tomfoolery. But this tomfoolery, having passed through a 
 very expensive machine, is somehow enobled and no-one dares 
 criticize it." -- Pierre Gallois.
0
Rudy
1/18/2010 10:45:29 PM
"Allen Bauer" <abauer@spicedham.codegear.com> wrote in message  
>> I didnt mean it in a negative way - just that by relying on upgrades
>> as opposed to new sales is a long term losing strategy as people
>> eventually bail out for various reasons (retirement, changing
>> requirements, etc).
> 
> I cannot disagree with you. That is why we're working on some
> strategies company wide to target new customers.

Good to hear!
0
Joe
1/18/2010 10:46:05 PM
In article <204170@forums.codegear.com>, Joe Demartino wrote:
> Ever hear of Microsoft giving out its beta of Windows 7 to anyone who 
> wanted it for a *year* prior to release, so that the positive buzz it 
> generated would help sales?

When it shipped. The sensible advice to anyone thinking of buying a 
computer through normal retail outlets during mid-2009 was to hold off 
for Windows 7 unless desperate.

-- 
Tony Bryer, Greentram Software Pty Ltd, Melbourne, Australia
'Software to build on'  http://www.greentram.com
0
Tony
1/18/2010 10:46:22 PM
Joe Demartino wrote:

> > We are a completely, totally different business than Microsoft.
> 
> As are car manufacturers - I was just countering Rudy's point with a
> counter example.

But the car sales example was an analogy that comes pretty close to
what Allen meant and what actually happens and has happened already,
while MS's bundling of Windows with computers doesn't come close to the
situation of Embarcadero at all.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"When a government lasts a long while, it deteriorates by
 insensible degrees. Republics end through luxury, monarchies
 through poverty." -- Montesquieu
0
Rudy
1/18/2010 10:49:14 PM
Tony Bryer wrote:

> In article <204170@forums.codegear.com>, Joe Demartino wrote:
> > Ever hear of Microsoft giving out its beta of Windows 7 to anyone
> > who wanted it for a year prior to release, so that the positive
> > buzz it generated would help sales?
> 
> When it shipped. The sensible advice to anyone thinking of buying a 
> computer through normal retail outlets during mid-2009 was to hold
> off for Windows 7 unless desperate.

Indeed.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"You exist only in what you do."
 -- Federico Fellini
0
Rudy
1/18/2010 10:50:54 PM
Nick Hodges wrote:

> This is utterly, definitely, completely true.

....and I should add that I was very skeptical of this before I joined
the company.  But reality is a tough thing to ignore.  ;-)

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/18/2010 11:00:10 PM
Allen Bauer wrote:
> 
> I cannot disagree with you. That is why we're working on some
> strategies company wide to target new customers.
> 

I think the cross-platform paradigm is one of them, and that's A Good
Thing (tm).  However, it would appear that it comes at the expense of
the needs of the existing customers, and that's A Bad Thing (trademark
available).

Believe me, I do understand the problem of existing resources, and
furthermore you folks are still having to pay the price of the ravages
of the 'Borland era'.

David Erbas-White
0
David
1/18/2010 11:04:14 PM
<Phil Hess> wrote in message news:201441@forums.codegear.com...
> Farshad,
>
> Most impressive!
>
> For readers who are not quite sure what they're looking at here, what 
> Farshad has done is create a Web app that is running compiled Delphi code 
> (using ExtPascal classes) on the server. This Delphi app serves up the Ext 
> JS JavaScript controls and additional JS code that's delivered as needed 
> using Ajax techniques.
>

Thanks,

I'm a bit late replying to this :)

Yes that is based on ExtJS and uses ExtPascal as gateway between Delphi and 
ExtJS.  ExtPascal performs great in this manner. Rest of it is my uniGUI 
framework adapted to ExtJS. It gives you full IDE design capability to 
create a WebApp based on ExtJS (ExtPascal). Indeed, the Fish Fact demo here 
is created by few mouse clicks plus a little code :)

Some features of uniGUI:
-Unified Visual Components for VCL and the Web. (The Fish Fact demo here has 
a VCL counterpart which can run on desktop)
-Complete session management.
-Web Forms are designed in Delphi IDE as if they're regular Delphi forms.
-Theme management for the web.
-Deployable as Standalone EXE, ISAPI Module or Windows Service (Service not 
implemented yet)
-Unified source/resource for both VCL and the Web. You create one Delphi app 
which can run on desktop and/or deployed to Web with no midification. 
(provided that all visual components used are uniXXX components).
-100% AJAX. All complex visual tasks can be done with no need for a browser 
refresh. (Thank to ExtJS and ExtPascal)

> The only thing odd that jumps out at me from this app (and it's not 
> Farshad's fault) is the excessive number of decimal digits for the fish 
> length in inches that Borland stores in the biolife database. Either 
> that's supposed to be a bit of a joke or somebody didn't understand 
> significant digits. Anytime you see original data like this that's rounded 
> to the nearest 10 (as in 50 cm, 150 cm, etc.) that means these are just 
> rough estimates of the lengths (if not just wild-ass guesses). 
> Accordingly, the values
> in inches should also be just rough estimates, with at most perhaps one 
> decimal digit. 13 decimal digits is just so weird. What was Borland 
> thinking? Can anyone offer a sane explanation?
>

Well, the framework itself is still alpha (maybe beta!) and there are still 
lots of tweaks to be done.
0
Farshad
1/18/2010 11:18:07 PM
Rudy Velthuis (TeamB) wrote:

> (in Dutch, we even say 10 in the bush).

<nitpick mode on>
  bush^H^H^H^H air
<nitpick mode off>

Carry on, nothing to see here ;-)

-- 
Pieter

"Asswhole = a complete ass" -- John McTaggart in bpot
0
Pieter
1/18/2010 11:19:56 PM
David Erbas-White wrote:

> Allen Bauer wrote:
> > 
> > I cannot disagree with you. That is why we're working on some
> > strategies company wide to target new customers.
> > 
> 
> I think the cross-platform paradigm is one of them, and that's A Good
> Thing (tm).  However, it would appear that it comes at the expense of
> the needs of the existing customers, and that's A Bad Thing (trademark
> available).

LOL! So *when* then should we embark on a "obtain new customers"
strategy? Only after we've "satified" the needs of all our existing
customers? Exactly *when* would that be? I hope you can see that not
matter which direction we go, we're going to be derided for "doing the
wrong thing" or "ignoring your existing customers."

We just have to make what we believe is the best decision for the
product, the company and our future. We all know that we're not going
to make everyone happy. So we just don the kevlar underwear, and charge
through the flames...

> Believe me, I do understand the problem of existing resources, and
> furthermore you folks are still having to pay the price of the ravages
> of the 'Borland era'.

When I say "company wide" that means more than RAD Studio.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/18/2010 11:22:48 PM
"Joe Demartino" <no@thanks.com> wrote in message 
news:204158@forums.codegear.com...
>
> Plus, that makes the assumption that giving info out harms sales in the
> first place.

Rather simple to demonstrate really. You're thinking of buying Widget v10 
right now. Unknown to you *yet* is that the next version will have feature-X 
which you are really going to want. So in 4 months Widget v11 is released 
and you immediately buy the upgrade.

Or... You're thinking of buying Widget v10 right now. But today you hear an 
announcement about feature-X in v11. While you'd really like to get v10 now, 
you decide you can carry on with v9 til v11 is released and only part with 
money then.

Happens *all the time*. This is one of the key reasons for creating the 
Software Assurance program - to get you to part with a little less money, 
but do so every year rather than only when a release comes out that has 
specific features you want. If enough people sign up for such subscription 
or similar programs, it would remove most if not all the need for secrecy 
from the customer standpoint (though there is still the issue of not giving 
your hand away to competitors).

> One could equally speculate
> that by being overly secretive, they're driving sales away because
> developers will want a sense of security about the future of the dev tool
> they choose to invest in.

Again comes the need for balance. They need to release enough to let people 
know development is active, agreed.

> The thing to keep looking at is that Delphi went
> from a main stream development tool to a very niche product over about 5
> years - while taking the current 'secretive' approach.

Nothing to do with that. First, compared to C/C++ and VB, Delphi has only 
ever just barely been considered a mainstream product, but has always had 
sufficient customers to be profitable and assure a next version (only thing 
that really matters). To the extent they lost any significant share is due 
to quality problems suffered under Borland mgmt, including a sales team that 
was actively told to *not* sell development tools and got no commission for 
doing so. Essentially Delphi continued making profits (and propping up 
Borland's ALM dreams) despite every attempt by them to marginalize and 
starve it! What's that say about whether developers were willing to shell 
out for it?

> Another thing to keep in mind... there's no mac or (active) linux delphi
> compiler.  So they wouldnt be harming sales of their mac and linux 
> compiler
> if they released more info about them.  If anything, they'd be keeping
> people from jumping ship.

As in the first case, they'd be harming sales of D2010 *now* if enough info 
is released to cause customers to hold off buying till next release. 
Cross-compiling is a feature many current customers (as well as hopefully 
many new ones) will want.

> Also... Could it be that releases are just too frequent?  A yearly release
> is a pretty fast pace.

For most software, the majority of sales happen in the months immediately 
following a release (mostly upgrade sales) and drop from that point on 
(leveling to mostly new sales). So yearly is probably an optimal target to 
develop and release a reasonable set of features and improvements. Under a 
subscription plan, releasing smaller more frequent upgrades might actually 
be more optimal.

> One more commment - the concern seems to be for losing 'upgrades'.  All 
> well
> and good, but if they are so reliant on upgrades (or what I like to call,
> milking their customers), perhaps its an indicator they arent forcusing
> enough on reaching new customers.

Most software, after the first few versions that establish a customer base, 
rely on upgrades. The goal of growing one's customer base *means growing and 
upgrade base* by definition - the more successful the product, the *more* it 
makes from upgrades over new customers!

-- 
Wayne Niddery (TeamB)
0
Wayne
1/19/2010 12:24:14 AM
"Joe Demartino" <no@thanks.com> wrote in message 
news:204173@forums.codegear.com...
>
> Someone already pointed out that before this line of
> thinking ('we cant tell you or it will risk sales'), we got the 'we cant
> tell you because of SOX' line for a number of years.

While that did concern publication of roadmaps, it was otherwise a totally 
different issue and, until it was figured out, stopped them from publishing 
a roadmap *period* since doing so, under SOX, could have required them to 
credit purchases only to the future, not-yet-released, version. That 
would've consequently caused them to go broke even while they were making 
sales.

I.e. that problem was *in addition* to the issue of harming current sales.

-- 
Wayne Niddery (TeamB)
0
Wayne
1/19/2010 12:31:10 AM
Wayne Niddery wrote:

> Happens *all the time*. This is one of the key reasons for creating
> the Software Assurance program - to get you to part with a little
> less money, but do so every year rather than only when a release
> comes out that has specific features you want. If enough people sign
> up for such subscription or similar programs, it would remove most if
> not all the need for secrecy from the customer standpoint (though
> there is still the issue of not giving your hand away to competitors).

This cannot be emphasised more. SA, was, IMO, marketed as more of a
"gimmick" rather than for its true intent. "Buy Delphi with SA, and you
get the next version for free!" The problem was that it was not (and is
not) really set up that way. The intent is that once you "jump on the
SA train" it is easier to remain on the train than to get off and then
jump back on. It isn't about "getting the next version for free," but
rather as long as you remain on the train, you benefit from any
release, regardless of when they happen.

If we could somehow transition to this model without tanking our
current revenue (The SA $$ has to be amortized over the SA period),
we'd do it in a heartbeat. The only way that can really happen is that
if sufficient customers signed up and remained on the program, year
after year. If that could ever happen (I'm not holding my breath), we
could begin to offer significantly more perks to the SA folks, like
early access to pre-releases, bug-fix updates are released to SA folks
a week or so before the non-SA folks. I'm just thinking on the fly
here. We could also do true "feature updates" since we're already
amortizing the revenue. If this could ever happen, then we'd be able to
easily quell the hue-and-cry from folks who paid for SA and then
complained that they "got nothing for that extra $$$" because we'd
always be delivering *something* to the large SA crowd through out the
year.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 12:45:38 AM
Wayne Niddery wrote:

> "Joe Demartino" <no@thanks.com> wrote in message 
> news:204173@forums.codegear.com...
> > 
> > Someone already pointed out that before this line of
> > thinking ('we cant tell you or it will risk sales'), we got the 'we
> > cant tell you because of SOX' line for a number of years.
> 
> While that did concern publication of roadmaps, it was otherwise a
> totally different issue and, until it was figured out, stopped them
> from publishing a roadmap period since doing so, under SOX, could
> have required them to credit purchases only to the future,
> not-yet-released, version. That would've consequently caused them to
> go broke even while they were making sales.

SOX has had a profound affect on all corporate accounting (public *and*
private). The primary one being that you cannot book revenue for a
product until it is delivered *in full* to the customer. As soon as you
release an update with a new "feature" then that triggers accounting
rules such that the "revenue" has to be recognized over the period of
time between the first sale and the update. It is *really* bad if
you've already booked the entire sale price as revenue. You now have to
go back and *restate* earnings if it crossed a quarterly boundary.

Even if you have the cash in the bank, you cannot count it as real
revenue! Under these rules, you could have $2B in cash from sales in
the bank, yet are only able to account for 1/4 of it on your balance
sheet. Also, you cannot spend or otherwise *use* that money because it
isn't *operating capital*. You can only take your expenses out of the
booked revenue. This is the true measure of the health of a company;
can they "operate" profitably? IOW, after you account for all your
expenses against the booked revenue, is there anything left over as
profit?

Yes, SOX SUX ;-) but it is a reality in which we live and we have to
make the best of it.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 12:56:49 AM
Allen Bauer wrote:

Sorry, I have to call BS on this one...

This 'problem' only existed for a year once the accounting method 
changed.  As a programmer, you should easily be able to figure out the 
paradigm.

At the beginning of the time, you folks went from 'booking all revenue' 
to only 'booking one-twelfth' of the revenue.  However, a year later you 
would be booking 1/12th of the new revenue from that month, 1/12th of 
the revenue from the month before, 1/12th of the revenue from 2 months 
before, etc., so that the total revenue booked one year after the 
accounting transition would 'show' as the full value of revenue that was 
being booked monthly a year previously.

The only result that SOX has at this point (more than one year after you 
changed accounting methods) is to SLOW the impact of revenue changes. 
If you have a stupendously large month, that change will be seen more 
gradually -- but the good news is that so is a dip.

So, you're not dealing with any differences in income, all of this 
nonsense about 'measuring the health of the company' doesn't relate to 
the 'real' measure of the company -- i.e., how likely is it that you 
will retain your paying customers?

I've been on SA for a while now, but I'm beginning to regret it.  I 
literally never even installed RAD Studio 2009, because there were so 
many issues to be worked out in it when it originally made the 
transition to Unicode.  RAD Studio 2011 (or whatever it will be called) 
will very likely be the same -- there is no way I'm going to trust a 
complete re-write of the compiler before I see others spend several 
months 'wringing the bugs' out of the product, and the likelihood is 
that (as with 2009) they won't be fixed until the NEXT iteration of the 
product.

So, at this point, being an SA customer brings me no real benefit -- I 
actually feel very much like I'm gambling.  And frankly, I am.  I'm 
gambling that a release will come out within the time frame of my SA 
period, and I'm gambling that the release will actually be usable/useful.

Embarcadero really needs to revamp what SA means if they want to retain 
folks longer term (retain as customers of SA, not overall customers). 
Blaming all of this on SOX doesn't go over well...

David Erbas-White


> Wayne Niddery wrote:
> 
> SOX has had a profound affect on all corporate accounting (public *and*
> private). The primary one being that you cannot book revenue for a
> product until it is delivered *in full* to the customer. As soon as you
> release an update with a new "feature" then that triggers accounting
> rules such that the "revenue" has to be recognized over the period of
> time between the first sale and the update. It is *really* bad if
> you've already booked the entire sale price as revenue. You now have to
> go back and *restate* earnings if it crossed a quarterly boundary.
> 
> Even if you have the cash in the bank, you cannot count it as real
> revenue! Under these rules, you could have $2B in cash from sales in
> the bank, yet are only able to account for 1/4 of it on your balance
> sheet. Also, you cannot spend or otherwise *use* that money because it
> isn't *operating capital*. You can only take your expenses out of the
> booked revenue. This is the true measure of the health of a company;
> can they "operate" profitably? IOW, after you account for all your
> expenses against the booked revenue, is there anything left over as
> profit?
>
0
David
1/19/2010 1:15:39 AM
David Erbas-White wrote:

> Allen Bauer wrote:
> 
> Sorry, I have to call BS on this one...
> 
> This 'problem' only existed for a year once the accounting method 
> changed.  As a programmer, you should easily be able to figure out
> the paradigm.

If, and only if you can survive that year with markedly lower revenue.
Also, it assumes that there are enough customers jump on that bandwagon.
 
> At the beginning of the time, you folks went from 'booking all
> revenue' to only 'booking one-twelfth' of the revenue.  However, a
> year later you would be booking 1/12th of the new revenue from that
> month, 1/12th of the revenue from the month before, 1/12th of the
> revenue from 2 months before, etc., so that the total revenue booked
> one year after the accounting transition would 'show' as the full
> value of revenue that was being booked monthly a year previously.
> 
> The only result that SOX has at this point (more than one year after
> you changed accounting methods) is to SLOW the impact of revenue
> changes.  If you have a stupendously large month, that change will be
> seen more gradually -- but the good news is that so is a dip.
> 
> So, you're not dealing with any differences in income, all of this 
> nonsense about 'measuring the health of the company' doesn't relate
> to the 'real' measure of the company -- i.e., how likely is it that
> you will retain your paying customers?

Correct. However it is the *transition* to that model that is what is
costly. As I stated in other posts, we cannot simply tell the creditors
and the investors, we're going to not be able have the same operating
profit for a while... We agree that the *outcome* is what is desired,
the problem is that the path from the current model to this new model
is no simple task. Our CFO would have a conniption.
 
> I've been on SA for a while now, but I'm beginning to regret it.  I 
> literally never even installed RAD Studio 2009, because there were so 
> many issues to be worked out in it when it originally made the 
> transition to Unicode.  RAD Studio 2011 (or whatever it will be
> called) will very likely be the same -- there is no way I'm going to
> trust a complete re-write of the compiler before I see others spend
> several months 'wringing the bugs' out of the product, and the
> likelihood is that (as with 2009) they won't be fixed until the NEXT
> iteration of the product.
> 
> So, at this point, being an SA customer brings me no real benefit --
> I actually feel very much like I'm gambling.  And frankly, I am.  I'm 
> gambling that a release will come out within the time frame of my SA 
> period, and I'm gambling that the release will actually be
> usable/useful.

That's the whole problem. Too many people think SA in its current form
is more like playing craps than being sound business strategy. How do
we fix that without giving our intestors, creditors, and CFO
indigestion?
 
> Embarcadero really needs to revamp what SA means if they want to
> retain folks longer term (retain as customers of SA, not overall
> customers).  Blaming all of this on SOX doesn't go over well...

On this we can agree. We need find some way to make SA more attractive,
since clearly the "you may get the next release for free" line isn't
sustainable long term. The SOX angle still plays a key role, whether or
not you believe it.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 1:28:55 AM
Allen Bauer wrote:
> David Erbas-White wrote:
> 
>> Allen Bauer wrote:
>>
>> Sorry, I have to call BS on this one...
>>
>> This 'problem' only existed for a year once the accounting method 
>> changed.  As a programmer, you should easily be able to figure out
>> the paradigm.
> 
> If, and only if you can survive that year with markedly lower revenue.
> Also, it assumes that there are enough customers jump on that bandwagon.
>  

That year interval has long since come and gone.  You folks are NOW (and 
obviously for quite some time previously) living off of 1/12th of new 
revenues, 1/12th of last month's revenue, etc., so you've obviously 
successfully made that transition.  There are no new transition costs.

David Erbas-White
0
David
1/19/2010 1:40:53 AM
David Erbas-White wrote:

> Allen Bauer wrote:
> > David Erbas-White wrote:
> > 
> >> Allen Bauer wrote:
> > > 
> >> Sorry, I have to call BS on this one...
> > > 
> >> This 'problem' only existed for a year once the accounting method 
> >> changed.  As a programmer, you should easily be able to figure out
> >> the paradigm.
> > 
> > If, and only if you can survive that year with markedly lower
> > revenue.  Also, it assumes that there are enough customers jump on
> > that bandwagon.   
> 
> That year interval has long since come and gone.  You folks are NOW
> (and obviously for quite some time previously) living off of 1/12th
> of new revenues, 1/12th of last month's revenue, etc., so you've
> obviously successfully made that transition.  There are no new
> transition costs.

I'm not sure where you got this information but that is not true at
all. We don't amortize license revenue. A license sale is booked at the
time of delivery. Only the SA portion of a sale (if it is so included)
is spread out over the next 12 months. I assure you that our SA to new
license revenue ratio is nowhere near where it would need to be to
transition to this new model.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 1:45:16 AM
"David Erbas-White" <derbas@arachneering.com> wrote in message 
news:204237@forums.codegear.com...
> Allen Bauer wrote:
>
> Sorry, I have to call BS on this one...
>
> This 'problem' only existed for a year once the accounting method
> changed.  As a programmer, you should easily be able to figure out the
> paradigm.


AFAIK what you state here is correct *as far as it goes*. But that is not 
the only disruption caused by SOX. The issue is, as I undertsand it, 
"forward-looking statements" - which is what a roadmap is. Under SOX it was 
possible that such a statement could be construed as a promise to deliver 
such features in return for a customer purchase *now*. That would mean, 
simply by stating that feature X is being planned or worked on for a future, 
from that moment, revenue for sales of the current version could only be 
booked once that feature was actually delivered.

At the moment SOX was passed, as with all such vague and hastily crafted 
regulation, there was much confusion as to what all the implications of it 
were; so much so that a whole industry of "compliance" consultants quickly 
appeared promising (for mega$dollars) to advise and guide companies through 
the new minefield.

In the end I still don't know if a roadmap could indeed cause that trouble 
under SOX, but reading what I could of the actual legislation and various 
"guidance" documents at the time, it certainly appeared to be the case. So 
at the time it was perfectly understandable for a company to put the kibosh 
on such statements *at least until they could figure it out*.

-- 
Wayne Niddery (TeamB)
0
Wayne
1/19/2010 3:13:45 AM
Allen,

I just want to say "thanks" for the non-trivial reply posts that you
have been making the past few days.  They do help for some of us to
understand where the "new" Embarcadero division is "coming from."

-- 

   Q

01/18/2010 19:09:28

XanaNews Version 1.19.1.269  [Q's Messing Around Mods]
0
Quentin
1/19/2010 3:13:47 AM
David Erbas-White wrote:

> That year interval has long since come and gone.  You folks are NOW
> (and obviously for quite some time previously) living off of 1/12th
> of new revenues, 1/12th of last month's revenue, etc., so you've
> obviously successfully made that transition.  There are no new
> transition costs.

David --

SOrry, but you are wrong.  License revenue, the large majority of
Delphi revenue, is not amortized.


-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/19/2010 4:02:04 AM
Nick,

> License revenue, the large majority of
> Delphi revenue, is not amortized.

Sorry for asking again. As a non-native speaker I do understand that you 
are not earning money with Delphi. Is this correct?

-- 
Roman
0
Roman
1/19/2010 7:00:44 AM
Roman Kassebaum wrote:
> Nick,
> 
>> License revenue, the large majority of
>> Delphi revenue, is not amortized.
> 
> Sorry for asking again. As a non-native speaker I do understand that you 
> are not earning money with Delphi. Is this correct?
> 


No, that is not correct.  Delphi IS making money.  What he stated was 
that when they are paid for a Delphi license, the take all of that money 
as 'income' at the time that the sale was made, they don't take (for 
example) a portion of it each month over a period of time (as an 
accounting action).

Further, it appears that I misunderstood/misinterpreted earlier 
statements about how things are handled.  My interpretation was that 
with the advent of 'SOX legislation' that they were 'forced' to amortize 
their income -- it now appears (if I'm reading correctly this time) that 
they are NOT doing so,  but would HAVE to do so if certain types of 
disclosures were made.

Going back to my original argument, IF this takes place, it should only 
offset earning over a period of a year, and after that, income/earnings 
would stabilize.  Given that (sooner or later) SOME action will PROBABLY 
occur that would trigger this requirement, it would seem prudent that 
they move to an amortized accounting method sooner or later.  Once that 
is done, there shouldn't be any further problems (as far as accounting 
rules are concerned) preventing them from discussions of roadmaps, etc.

David Erbas-White
0
David
1/19/2010 7:23:37 AM
In article <204275@forums.codegear.com>, Roman Kassebaum wrote:
> Sorry for asking again. As a non-native speaker I do understand
> that you are not earning money with Delphi. Is this correct?

What he means is that if today you spend $500 on a Delphi upgrade, 
$500 appears in the January profit & loss - it's a product sale. If 
you spend $600 on SA - it's a payment for a service so $50 appears 
this month, then $50 per month for the next 11 months. At the end 
of month one the other $550 appears on the balance sheet as a 
liability - which it is, to provide support over the contract 
period, or - in theory anyway - to return a pro-rata amount if you 
are no longer able to offer the contracted service.

If you're not already confused, assume that the current split is 
50% new sales, 50% upgrades (say $500). Then Nick waves a wand and 
next month all the upgrades turn into $600 SA. But in Feb only $50 
of this is taken + the same $500 for new sales, and the headline 
figure is a 45% collapse in sales! Of course the rest of the money 
will be drawn down but banks are vastly more impressed by sales 
revenue not expectations.

I switched to an SA type system in 1993 - on first time sales I 
take 80% now and 20% is treated as SA, then annual payments after 
year one are accounted for as 17.5% + 11 x 7.5%. In my case the 
effect in year one was to knock the sales figures down sharply, 
reducing my tax bill, but I didn't have a bank or investors to keep 
happy.

-- 
Tony Bryer, Greentram Software Pty Ltd, Melbourne, Australia
'Software to build on'  http://www.greentram.com
0
Tony
1/19/2010 7:31:55 AM
Tony,

> What he means is that if today you spend $500 on a Delphi upgrade,
> $500 appears in the January profit&  loss - it's a product sale. If
> you spend $600 on SA - it's a payment for a service so $50 appears
> this month, then $50 per month for the next 11 months. At the end
> of month one the other $550 appears on the balance sheet as a
> liability - which it is, to provide support over the contract
> period, or - in theory anyway - to return a pro-rata amount if you
> are no longer able to offer the contracted service.
>
> If you're not already confused, assume that the current split is
> 50% new sales, 50% upgrades (say $500). Then Nick waves a wand and
> next month all the upgrades turn into $600 SA. But in Feb only $50
> of this is taken + the same $500 for new sales, and the headline
> figure is a 45% collapse in sales! Of course the rest of the money
> will be drawn down but banks are vastly more impressed by sales
> revenue not expectations.

I'm already confused. That's why I have some questions:

1. Why is there a bank of investors? In the German news Embarcadero has 
been advertised as a normal software company. Is Embarcadero a bank of 
investors or is there someone else who invested a lot of money?

2. I do understand the issue with the SA. But normally after one year 
the effect is blown away, the SA repeats periodically. AFAIK they are 
offering SA for many years. Why is the splitting now a problem?

-- 
Roman
0
Roman
1/19/2010 8:51:58 AM
David,

> No, that is not correct.  Delphi IS making money.

These are very good news.


> What he stated was that when they are paid for a Delphi license, the take all of that money
> as 'income' at the time that the sale was made, they don't take (for
> example) a portion of it each month over a period of time (as an
> accounting action).

If I understood Tony correctly the opposite happens cause of SA.


> Further, it appears that I misunderstood/misinterpreted earlier
> statements about how things are handled.  My interpretation was that
> with the advent of 'SOX legislation' that they were 'forced' to amortize
> their income -- it now appears (if I'm reading correctly this time) that
> they are NOT doing so,  but would HAVE to do so if certain types of
> disclosures were made.

What is the "advent of 'SOX legislation'"?

> Going back to my original argument, IF this takes place, it should only
> offset earning over a period of a year, and after that, income/earnings
> would stabilize.  Given that (sooner or later) SOME action will PROBABLY
> occur that would trigger this requirement, it would seem prudent that
> they move to an amortized accounting method sooner or later.  Once that
> is done, there shouldn't be any further problems (as far as accounting
> rules are concerned) preventing them from discussions of roadmaps, etc.

What can a "an amortized accounting method" be?

-- 
Roman
0
Roman
1/19/2010 9:00:03 AM
Pieter Zijlstra wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > (in Dutch, we even say 10 in the bush).
> 
> <nitpick mode on>
>   bush^H^H^H^H air
> <nitpick mode off>
> 
> Carry on, nothing to see here ;-)

I know, but the English saying uses "in the bush", and I only wanted to
modify the number, not the rest. We actually say "in the air", yes.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"What difference does it make how much you have? What you do
 not have amounts to much more."
 -- Seneca
0
Rudy
1/19/2010 12:41:15 PM
Rudy Velthuis (TeamB) wrote:

> I know, but the English saying uses "in the bush", and I only wanted to
> modify the number, not the rest. We actually say "in the air", yes.

And in Sweden the 10 birds are "in the wood" (hard to find a place without
nearby woods in most of Sweden).

-- 
Anders Isaksson, Sweden
BlockCAD: http://www.blockcad.net  
Gallery: http://www.blockcad.net/gallery/index.htm
0
Anders
1/19/2010 12:57:17 PM
Anders Isaksson wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > I know, but the English saying uses "in the bush", and I only
> > wanted to modify the number, not the rest. We actually say "in the
> > air", yes.
> 
> And in Sweden the 10 birds are "in the wood" (hard to find a place
> without nearby woods in most of Sweden).

And in Germany, it is "better the sparrow in the hand than the pigeon
on the roof". At the same time, most Germans consider pigeons no better
than flying rats, these days. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The spirit of resistance to government is so valuable on
 certain occasions that I wish it to be always kept alive."
 -- Thomas Jefferson
0
Rudy
1/19/2010 1:06:49 PM
"Roman Kassebaum" <roman@nospamremoveitkassebaum.eu> wrote in message 
news:204286@forums.codegear.com...
> David,
>
> If I understood Tony correctly the opposite happens cause of SA.

Correct, because SA is similar to a subscription, revenue from it is 
recognized in equal anounts for the length of the subscription (1 year) 
instead of all at time of sale.

> What is the "advent of 'SOX legislation'"?

SOX = Sarbanes-Oxley, the two U.S. congress-critters that came up with this 
horrible legislation. It imposes all kinds of new rules on how a company 
must do its accounting and was a hasty "knee-jerk" reaction to the fraud and 
other criminal activity by Enron.

> What can a "an amortized accounting method" be?

As described, when you make a sale, instead of crediting (booking) the 
entire sale price at that time (in that fiscal month), a portion is credited 
to each month over the next 12 months. This also means those funds are not 
available to the company up front, only as each portion is booked each 
month.

-- 
Wayne Niddery (TeamB)
0
Wayne
1/19/2010 1:39:42 PM
Wayne,

> SOX = Sarbanes-Oxley, the two U.S. congress-critters that came up with this
> horrible legislation. It imposes all kinds of new rules on how a company
> must do its accounting and was a hasty "knee-jerk" reaction to the fraud and
> other criminal activity by Enron.

I see. Thank you very much for your explanation.
Now, I found a (German) wiki article about this legislation.

-- 
Roman
0
Roman
1/19/2010 1:49:25 PM
Allen Bauer wrote:

> At least our sales and marketing organizations can actually spell
> Delphi and RAD Studio! Contrast that with the last years at Borland
> where a front-line sales guy would be reprimanded and not given
> commission on a Delphi sale! No matter how large or even if it was
> unsolicited! How f**** up was that!?

Don't get me started...

-- 
Regards,
Bruce McGee
Glooscap Software
0
Bruce
1/19/2010 3:17:15 PM
Allen Bauer wrote:

> I cannot disagree with you. That is why we're working on some
> strategies company wide to target new customers.

I hope this includes a concerted (and consistent) effort to target
students.

-- 
Regards,
Bruce McGee
Glooscap Software
0
Bruce
1/19/2010 3:28:50 PM
David Erbas-White wrote:

> I think the cross-platform paradigm is one of them, and that's A Good
> Thing (tm).  

Yes, it is.


> However, it would appear that it comes at the expense of
> the needs of the existing customers, and that's A Bad Thing (trademark
> available).

Not this one.  I want cross platform.


> Believe me, I do understand the problem of existing resources, and
> furthermore you folks are still having to pay the price of the ravages
> of the 'Borland era'.

Yes, they have a lot to live down, but things have gotten much better
since CodeGear and then Embarcadero have been calling the shots.

-- 
Regards,
Bruce McGee
Glooscap Software
0
Bruce
1/19/2010 3:34:16 PM
Wayne Niddery wrote:

> > What is the "advent of 'SOX legislation'"?
> 
> SOX = Sarbanes-Oxley, the two U.S. congress-critters that came up
> with this horrible legislation. It imposes all kinds of new rules on
> how a company must do its accounting and was a hasty "knee-jerk"
> reaction to the fraud and other criminal activity by Enron.

To be clear, it is actually my understanding that the accounting
"rules" about requiring the amortization of "subscriptions" or
"incomplete product delivery" have been in place for many, many years
prior to the SOX legislation. What SOX did, among other things, was to
now hold certain company officers *personally* responsible for any
published financial results.  SOX also put into place much, much
stiffer penalties and fines if auditors ever found irregularities in
the books.

Previously, the "accounting rules" were largely left to some level of
interpretation, so some companies may have stretched and pulled them a
little more than others. Now with SOX, companies are now,
understandably, very skittish about "misinterpreting" the rules and
getting caught with their pants down. This bred a whole new industry of
independent corporate auditors that come in and ensure that a company
is meeting a now better standardized interpretation of the rules. Now
software is treated no different than a physical widget of some sort.
Until the accounting rules take into account the realities of software,
we're stuck with the way things are.

Remember when Apple was issuing an "update" to the iPhone and charged
$5 or some such to existing customers to get it? They publicly stated
that they could not "give it away" because that would have triggered a
nasty restatement of earnings event... While I have no evidence to the
fact, I suspect that they've switched to a fully amortized model just
to avoid such a situation in the future. However, they had enough
revenue from all their other products *and* it was early enough into
the iPhone lifecycle, whereby they could easily survive the blip in
revenue.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 5:29:38 PM
Roman Kassebaum wrote:

> Tony,
> 
> > What he means is that if today you spend $500 on a Delphi upgrade,
> > $500 appears in the January profit&  loss - it's a product sale. If
> > you spend $600 on SA - it's a payment for a service so $50 appears
> > this month, then $50 per month for the next 11 months. At the end
> > of month one the other $550 appears on the balance sheet as a
> > liability - which it is, to provide support over the contract
> > period, or - in theory anyway - to return a pro-rata amount if you
> > are no longer able to offer the contracted service.
> > 
> > If you're not already confused, assume that the current split is
> > 50% new sales, 50% upgrades (say $500). Then Nick waves a wand and
> > next month all the upgrades turn into $600 SA. But in Feb only $50
> > of this is taken + the same $500 for new sales, and the headline
> > figure is a 45% collapse in sales! Of course the rest of the money
> > will be drawn down but banks are vastly more impressed by sales
> > revenue not expectations.
> 
> I'm already confused. That's why I have some questions:
> 
> 1. Why is there a bank of investors? In the German news Embarcadero
> has been advertised as a normal software company. Is Embarcadero a
> bank of investors or is there someone else who invested a lot of
> money?

Thoma-Cressy-Bravo is a private equity firm that purchased Embarcadero,
which was a public company, several years ago and took it private. TCB
(http://www.tcb.com/) and Embarcadero then went looking for another
company to "blend" into the the portfolio with EMBT. That was about the
time that CodeGear was still being shopped around. They looked like a
good match with very little overlap in similar markets. So TCB ponied
up more $$ and purchased CodeGear from Borland and then "assigned" the
asset to Embarcadero.

When a PE firm does this kind of transaction, they represent a
consortium of many investors who give them $$ to invest. Generally,
they don't use all their $$ for one investment. They only put in what
they feel is an adequate amount of risk and will have the highest
return for their investors. The balance of the sale price is then taken
out in bank loans, with the company itself as collateral. These loans
are not put onto TCB's balance sheet, but are Embarcadero's to bear.
So, not only does the company have to pay back the investors, it also
on the hook to the banks that have also fronted a huge load of $$. Part
of the "terms" of the bank note is that the company must provide a
certain EBITDA (http://www.investopedia.com/terms/e/ebitda.asp) in
order for the bank to continue to provide "favorable" terms. This is
"normal" for many software firms in the industry. For instance,
AutomatedQA was purchased by another PE firm a couple years ago.

Do not confuse this with venture capital, which has a whole different
set of common scenarios. PE investments are usually only done with
existing, stable, sometimes profitable, businesses or product lines.
VC, by contrast is way more gamble, gut feel, and like playing a game
of craps. VC can also pay off way more because the risk is way higher
too.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/19/2010 6:18:36 PM
Am 18.01.2010 23:40, schrieb Nick Hodges:
> Allen Bauer wrote:
> 
>> Yep,
>> sometimes it works (but let's not tell Nick, ok? ;-).
> 
> It' /never/ works.  Hodges Law (much like Godwin's law) states that
> anyone who invokes an analogy about cars relating to the software
> business automatically loses the argument.
> 

Hm, but you didn't prove this to be right this time. So the law is shown
to be invalid?! ;-)

Greetings

Markus
0
Markus
1/19/2010 7:00:38 PM
Allen Bauer wrote:

> OMG!! It's the dreaded "software is the same as a car" analogy! Yep,
> sometimes it works (but let's not tell Nick, ok? ;-).

FWIW, just this (OK, a little old, but it explains):

<<
Microsoft cuts Visual Studio 2008 upgrade prices as VS 2010 looms
>>

http://searchwindevelopment.techtarget.com/news/article/0,289142,sid8_gci1347126,00.html

Isn't that the same principle again?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Weinberg's Law: If builders built buildings the way programmers 
write programs, then the first woodpecker that came along would 
destroy civilization.
0
Rudy
1/19/2010 7:01:41 PM
Hello,

C++ builder can use and compile Delphi code but Delphi can't use C++ code.

Greetings

Markus
0
Markus
1/19/2010 7:18:42 PM
"Markus Humm" <markus.humm@freenet.de> wrote in message 
news:204494@forums.codegear.com...
> Hello,
>
> C++ builder can use and compile Delphi code but Delphi can't use C++ code.
>
> Greetings
>


Sorry, couldn't understand what it has to do with my post. Can you elaborate 
it a bit?
0
Farshad
1/19/2010 8:20:31 PM
> LOL! So *when* then should we embark on a "obtain new customers"
> ...

LOLing @ existing customers doesn't seem like a sound plan, though.
Cool new young kids don't even know about Delphi, you know...

LP,
Dejan
0
Dejan
1/20/2010 12:22:59 AM
Dejan Stanic wrote:

> > LOL! So when then should we embark on a "obtain new customers"
> > ...
> 
> LOLing @ existing customers doesn't seem like a sound plan, though.

Oh my, are we sensitive. 
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"There are, it has been said, two types of people in the world. 
 There are those who, when presented with a glass that is exactly 
 half full, say: this glass is half full. And then there are 
 those who say: this glass is half empty. The world belongs, 
 however, to those who can look at the glass and say: What's up 
 with this glass? Excuse me? Excuse me? This is my glass? I don't 
 think so. My glass was full! And it was a bigger glass!"
 -- Terry Pratchett, "The Truth"
0
Rudy
1/20/2010 12:46:22 AM
Allen,

 > Thoma-Cressy-Bravo is a private equity firm that purchased Embarcadero,
 > which was a public company, several years ago and took it private. TCB
 > (http://www.tcb.com/) and Embarcadero then went looking for another
 > company to "blend" into the the portfolio with EMBT. That was about the
 > time that CodeGear was still being shopped around. They looked like a
 > good match with very little overlap in similar markets. So TCB ponied
 > up more $$ and purchased CodeGear from Borland and then "assigned" the
 > asset to Embarcadero.
 >
 > When a PE firm does this kind of transaction, they represent a
 > consortium of many investors who give them $$ to invest. Generally,
 > they don't use all their $$ for one investment. They only put in what
 > they feel is an adequate amount of risk and will have the highest
 > return for their investors. The balance of the sale price is then taken
 > out in bank loans, with the company itself as collateral. These loans
 > are not put onto TCB's balance sheet, but are Embarcadero's to bear.
 > So, not only does the company have to pay back the investors, it also
 > on the hook to the banks that have also fronted a huge load of $$. Part
 > of the "terms" of the bank note is that the company must provide a
 > certain EBITDA (http://www.investopedia.com/terms/e/ebitda.asp) in
 > order for the bank to continue to provide "favorable" terms. This is
 > "normal" for many software firms in the industry. For instance,
 > AutomatedQA was purchased by another PE firm a couple years ago.
 >
 > Do not confuse this with venture capital, which has a whole different
 > set of common scenarios. PE investments are usually only done with
 > existing, stable, sometimes profitable, businesses or product lines.
 > VC, by contrast is way more gamble, gut feel, and like playing a game
 > of craps. VC can also pay off way more because the risk is way higher
 > too.

Thank you very much for your explanation and your clear words.
I'm really surprised that you are allowed to give us so many details.

Thank you again.

-- 
Roman
0
Roman
1/20/2010 9:29:42 AM
Allen,

On Fri, 08 Jan 2010 17:37:29 -0000, Allen Bauer  
<abauer@spicedham.codegear.com> wrote:

> Those are all excellent suggestions. I would recommend you contact
> Michael Rozlog, the RAD Studio Product Manager, and voice your
> suggestions. He needs to hear from as many of you as possible. If he
> can come up with a plan and a business case that can clearly show a NET
> positive gain, his life is much easier.

.... and my life would be so much easier if Michael were to do the work for  
which I am paid. <g>

Don't get me wrong - it would be great to think you were open to  
suggestions - but there's not a lot of evidence for that. In fact that  
most suggestions seem to be dismissed because they come from people who  
"think they know better how to run the company than the people who  
actually run it"

-- 
Paul Scott
Information Management Systems
Macclesfield, UK
0
Paul
1/20/2010 5:47:10 PM
Hello,

sorry. My Thunderbird had messed up something.

Greetings

Markus
0
Markus
1/20/2010 6:36:23 PM
Paul Scott wrote:

> In fact
> that most suggestions seem to be dismissed because they come from
> people who "think they know better how to run the company than the
> people who actually run it"

That's blatant nonsense. Micheal Rozlog didn't say something like that,
but I did. And I said that about people who try to tell Embarcadero how
to run their business.

That is, however, not nearly the same as stating what YOU (and/or YOUR
business) would like to see, or would need. The more suggestions like
that, the merrier. That would give Michael a better case to propose to
higher management.

And note that I have never opposed such suggestions either. There is a
big difference between telling Embarcadero how to run their business,
as some here seem to do, and suggesting what would benefit YOUR OWN
business.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A computer makes it possible to do, in half an hour, tasks which
 were completely unnecessary to do before."
0
Rudy
1/21/2010 12:15:41 AM
Rudy Velthuis (TeamB) wrote:

> And note that I have never opposed such suggestions either. There is a
> big difference between telling Embarcadero how to run their business,
> as some here seem to do, and suggesting what would benefit YOUR OWN
> business.

I can say with great assurance that between these two arguments:

"You guy should do <something> because people will buy crazy tons of
Delphi!"

and

"I would buy/upgrade Delphi if you guys did <something>"

The latter will carry /way/ more weight and be much more persuasive.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/21/2010 1:38:57 AM
Nick Hodges wrote:

> I can say with great assurance that between these two arguments:
> 
> "You guy should do <something> because people will buy crazy tons of
> Delphi!"
> 
> and
> 
> "I would buy/upgrade Delphi if you guys did <something>"
> 
> The latter will carry way more weight and be much more persuasive.

That is what I meant, indeed.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The concept is interesting and well-formed, but in order to 
 earn better than a 'C', the idea must be feasible."
 -- A Yale University management professor in response to student
    Fred Smith's paper proposing reliable overnight delivery 
    service (Smith went on to found Federal Express Corp.)
0
Rudy
1/21/2010 2:25:30 AM
Nick Hodges wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > And note that I have never opposed such suggestions either. There
> > is a big difference between telling Embarcadero how to run their
> > business, as some here seem to do, and suggesting what would
> > benefit YOUR OWN business.
> 
> I can say with great assurance that between these two arguments:

I'm not sure what the relation is with what you quoted.

> "You guy should do <something> because people will buy crazy tons of
> Delphi!"

Maybe you copied the above sentence from an internal management report,
I dunno <g,d&r>   Anyway AFAIK no one said something like that in this
group. AFAICT the trend in this group is more about, you may lose
(more?) existing users than gain new users, but most-likely these
opinions are/were biased, but then again the future will tell us who
was right.

> and
> 
> "I would buy/upgrade Delphi if you guys did <something>"

There was at least one, upon recently, who was willing to spend a
couple of bucks for a buggy/slow x64 compiler, but I don't think he
would be willing to spend the millions of bucks required to change
priorities ;)

> The latter will carry way more weight and be much more persuasive.

You forgot to mention a third group who expressed trust about a
possible future direction of Codegear and/or EMBT, those with SA.  But
I don't have the numbers to determine if they put their trust in a x64
or a X-platform future.

-- 
Pieter

"I don’t really miss God, but I sure miss Santa Claus!"
 -- Courtney Love
0
Pieter
1/21/2010 3:23:45 AM
Pieter Zijlstra wrote:

>   Anyway AFAIK no one said something like that in this
> group. 

People say things like that in this group ////all the time////.



-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/21/2010 4:34:58 AM
On Thu, 21 Jan 2010 00:15:41 -0000, Rudy Velthuis  
<newsgroups@rvelthuis.de> wrote:

>> ... most suggestions seem to be dismissed because they come from
>> people who "think they know better how to run the company than the
>> people who actually run it"
>
> That's blatant nonsense. Micheal Rozlog didn't say something like that,
> but I did. And I said that about people who try to tell Embarcadero how
> to run their business.

Rudy,

I know that since you are contractually obliged to reply to each and every  
single message in these forums, you don't have much time left over to  
properly read the messages you're responding to <g>, but I did /not/ say  
that Michael had been the source of that expression.

(That paragraph did originally say "Michael, nor any other EMBT employee,"  
- but see later)


However I /did/ say "there's not a lot of evidence" for EMBT being open to  
suggestions...

Over the years many people have made suggestions for the improvement of  
the product and its marketing. I myself have made proposals as to how EMBT  
could have multiplied their revenue from our company and could increase  
the likelihood of sales into the long-term.

The feedback from EMBT employees has been conspicuous by its absence - not  
in these forums; not by mail; not by private email; not by telephone -  
"not a lot of evidence"


Yes, EMBT employees do occasionally say - as did Allen - "I would  
recommend you contact Xyz and voice your suggestions."

To which my, admittedly flippant, response was along the lines of: "I have  
already voiced my suggestion in this forum.  Why should I have to contact  
Xyz myself?  Why can't Xyz read my comments here?  Why should I have to do  
the extra work to prepare the basis for /his/ presentation to EMBT  
management?  After all, this suggestion could increase EMBT profits."

Surely if any EMBT employee did think that my idea was worth considering,  
then /they/ would be contacting me. Since they haven't, then I can  
probably assume that I would be wasting my (unpaid) time.

... Again, "not a lot of evidence" for EMBT being open to suggestions.


Neither, to the best of my recollection, has any EMBT employee ever  
expressed even the slightest dissent from, or disapproval of, comments  
such as the one which I quoted. In fact, the only comments from EMBT I can  
find are along very similar lines: "Yes - and nothing in it makes me  
believe he knows more about our broad and diverse customer base than we  
do."  https://forums.embarcadero.com/message.jspa?messageID=190431
(Not any particular dig at Nick. Just the first example thrown up by  
Google)

... Again "not a lot of evidence" for EMBT being open to any suggestion  
which doesn't fit in with their current thinking.


However, I would *love* to be proved wrong.

-- 
Paul Scott
Information Management Systems
Macclesfield, UK
0
Paul
1/21/2010 12:37:41 PM
Paul Scott wrote:

> Allen,
> 
> On Fri, 08 Jan 2010 17:37:29 -0000, Allen Bauer  
> <abauer@spicedham.codegear.com> wrote:
> 
> > Those are all excellent suggestions. I would recommend you contact
> > Michael Rozlog, the RAD Studio Product Manager, and voice your
> > suggestions. He needs to hear from as many of you as possible. If he
> > can come up with a plan and a business case that can clearly show a
> > NET positive gain, his life is much easier.
> 
> ... and my life would be so much easier if Michael were to do the
> work for which I am paid. <g>
> 
> Don't get me wrong - it would be great to think you were open to  
> suggestions - but there's not a lot of evidence for that. In fact
> that most suggestions seem to be dismissed because they come from
> people who "think they know better how to run the company than the
> people who actually run it"

What *would* make you think that we're open to suggestions? Remember,
listening and considering input, is *not* equal to agreeing with or
acting on said input. We *do* want you to feel like your voice is
heard. While we do make product decisions unilaterally (it's not a
democracy), we'd also be foolish to blatantly *ignore* input from
customers or potential customers. That means, and we're painfully
cogniscent of this, that we're *not* going to meet the needs of
everyone.

The absolute *best* form of feedback we can get is more along the lines
of "I'm trying to solve problem X" followed by a description of said
problem. Feedback in the form of "You should implement this new feature
in this way" is, quite frankly, not nearly as useful. It places very
severe restriction on how we can act on it.

If we had a lot of suggestions in the form of problems to be solved, we
can aggregate them together. This allows us to find all the common
points among the problems and create solutions that benefit the widest
range of problems. Unlike most application developers that are focused
on a certain, specific problem or class of problems, we *have* think
about how to create solutions that are beneficial and appealing to the
widest range of customers. If we get too specific, we're excluding too
many people. Even then, there will be *some* classes of problems that
may not be solved with our generalized solutions.

So, when you're giving us feedback, rather thant saying, "I need a
64bit compiler, NOW!" saying, "I need to make sure my MS Office
extension will work with all versions of the new Office 2010" or "My
Explorer shell extension needs to work with all the new 64bit versions
of Windows."

I hope people understand the distinction. The first one doesn't convey
the problem you're trying to solve, nor is it implicitly or explcitly
describing how said solution (or lack thereof) would help (or hinder)
your business. We *love* the latter form of feedback, and have real
trouble categorizing and quantifying the former.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/21/2010 6:27:02 PM
Paul Scott wrote:

> >> ... most suggestions seem to be dismissed because they come from
> >> people who "think they know better how to run the company than the
> >> people who actually run it"
> > 
> > That's blatant nonsense. Micheal Rozlog didn't say something like
> > that, but I did. And I said that about people who try to tell
> > Embarcadero how to run their business.
> 
> Rudy,
> 
> I know that since you are contractually obliged to reply to each and
> every single message in these forums, you don't have much time left
> over to properly read the messages you're responding to <g>

Funny.

> but I did not say that Michael had been the source of that expression.

No, but you implied that you would get something like that back, from
him or from someone else from Embarcadero.
 
> However I did say "there's not a lot of evidence" for EMBT being open
> to suggestions...

Thee is not a lot of evidence that they aren't either. Unless you know
all suggestions made to them, you can hardly tell if that is so.

AFAICT (and I do have a little more insight into their internal
processes than you do, I guess), they are and have been open to
suggestions. That does not mean they can follow any whim someone might
have. There very likely other factors (which we can only guess at) that
play an important role in their decision process too. These possible
factors have been discussed oh so many times already, over and over and
over.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Your Highness, I have no need of this hypothesis."
 -- Pierre Laplace (1749-1827), to Napoleon on why his works on 
    celestial mechanics make no mention of God.
0
Rudy
1/21/2010 7:01:58 PM
Nick Hodges wrote:

> Pieter Zijlstra wrote:
> 
> >   Anyway AFAIK no one said something like that in this
> > group. 
> 
> People say things like that in this group ////all the time////.

Yes. I call that "telling Embarcadero how they should run their
business". That is not the same as telling Embarcadero what you are
missing or would like to have in their products to run your own
business. I find the latter valid information, and I'm sure Embarcadero
values it too (they'd be foolish not to).

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"In matters of conscience, the law of majority has no place."
 -- Mohandas Gandhi
0
Rudy
1/21/2010 7:07:06 PM
Allen Bauer wrote:

> 
> So, when you're giving us feedback, rather thant saying, "I need a
> 64bit compiler, NOW!" saying, "I need to make sure my MS Office
> extension will work with all versions of the new Office 2010" or "My
> Explorer shell extension needs to work with all the new 64bit versions
> of Windows."
> 
> I hope people understand the distinction. The first one doesn't convey
> the problem you're trying to solve, nor is it implicitly or explcitly
> describing how said solution (or lack thereof) would help (or hinder)
> your business. We love the latter form of feedback, and have real
> trouble categorizing and quantifying the former.


Yes, I understand but the problem is we really need 64-bit compiler
now. ;o)

I am quite sure that you already know perfectly well the majority of
scenarios where 64-bit compiler is a necessity as far as a strictly
technical point is considered.

However, the other aspect of the situation is uncertainity. Since
Embarcadero is not willing to make a strong commitment about the
*approximate* timeframe when we can expect the new compiler to be here,
it is really difficult for its customers to decide that it is safe to
continue investing in Delphi. Also, there is a growing pressure to
start converting the existing code to something like .Net.


I think it would be beneficial for everyone if Embarcadero could make a
commitment that after X-Platform project is completed the next priority
will be Windows 64-bit suff and not for example support for iPone or
something else.


I see some people downplaying the immediate need for Delphi/CPP Builde
Windows 64-bit compilers but if that is true would you be willing to
advertise Delphi using the slogan like : "Delphi, the worlds best IDE
to write your 32-bit native applications." ?


Regards,
Zenon
0
Zenon
1/21/2010 9:24:43 PM
Zenon Jordan wrote:

> Allen Bauer wrote:
> 
> > 
> > So, when you're giving us feedback, rather thant saying, "I need a
> > 64bit compiler, NOW!" saying, "I need to make sure my MS Office
> > extension will work with all versions of the new Office 2010" or "My
> > Explorer shell extension needs to work with all the new 64bit
> > versions of Windows."
> > 
> > I hope people understand the distinction. The first one doesn't
> > convey the problem you're trying to solve, nor is it implicitly or
> > explcitly describing how said solution (or lack thereof) would help
> > (or hinder) your business. We love the latter form of feedback, and
> > have real trouble categorizing and quantifying the former.
> 
> 
> Yes, I understand but the problem is we really need 64-bit compiler
> now. ;o)

There's always that one guy in the crowd ;-)... 
 
> I am quite sure that you already know perfectly well the majority of
> scenarios where 64-bit compiler is a necessity as far as a strictly
> technical point is considered.
> 
> However, the other aspect of the situation is uncertainity. Since
> Embarcadero is not willing to make a strong commitment about the
> approximate timeframe when we can expect the new compiler to be here,
> it is really difficult for its customers to decide that it is safe to
> continue investing in Delphi. Also, there is a growing pressure to
> start converting the existing code to something like .Net.
 
We're certainly working on the 64bit compiler since I regularly see
checkins like this at least once or more a week:

====
27406 trunk/com/ decl.c 	8/0 	Thu Jan 21 06:05:09 2010 UTC 	ytagawa
27406 trunk/com/ objout.c 	4/0 	Thu Jan 21 06:05:09 2010 UTC 	ytagawa
  	Log:
[dcc64] initial parOff is 16 for x64 instead of 8 for 32bit.
====
 
That doesn't mean it is "all-hands-on-deck" for the 64 bit compiler,
that distinction belongs to the Fulcrum (x-plat) project as that is the
closest release. However, please know that we're working to the best of
our ability to ensure we're going to be able to "hit the ground
running" once we're able to shift focus to 64bit. *If* that is the
release immediately after Fulcrum, I cannot comment.

> I think it would be beneficial for everyone if Embarcadero could make
> a commitment that after X-Platform project is completed the next
> priority will be Windows 64-bit suff and not for example support for
> iPone or something else.

Making a commitment like that today doesn't mean that other events down
the line require a change in priorities. Yes, it doesn't mean that
those event will cause a change either, but the crystal ball gets
murkier and murkier as we peer farther into the future.
 
> I see some people downplaying the immediate need for Delphi/CPP Builde
> Windows 64-bit compilers but if that is true would you be willing to
> advertise Delphi using the slogan like : "Delphi, the worlds best IDE
> to write your 32-bit native applications." ?

I, personally, *don't* want to downplay the importance either. I get it
that for an increasingly larger segment of our customers, it is *very*
important and even critical. The same can be said for x-plat.

There have been times that I've seen management come in and say, "this
is the top priority" and then a week later come back and say "that is
the top priority" and when asked, well which one is more important they
say, they both are... (NOTE: I'm not at all saying that is the way it
is now with EMBT!).

My response is simply, "If *everything* is top priority, then *nothing*
is."

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/21/2010 10:22:55 PM
Allen,

> We're certainly working on the 64bit compiler since I regularly see
> checkins like this at least once or more a week:
>
> ====
> 27406 trunk/com/ decl.c 	8/0 	Thu Jan 21 06:05:09 2010 UTC 	ytagawa
> 27406 trunk/com/ objout.c 	4/0 	Thu Jan 21 06:05:09 2010 UTC 	ytagawa
>    	Log:
> [dcc64] initial parOff is 16 for x64 instead of 8 for 32bit.
> ====

So, you are implementing the compiler with C, aren't you? Shame on you! :-)

Why don't you use the best language in the world? ;-)


> That doesn't mean it is "all-hands-on-deck" for the 64 bit compiler,
> that distinction belongs to the Fulcrum (x-plat) project as that is the
> closest release. However, please know that we're working to the best of
> our ability to ensure we're going to be able to "hit the ground
> running" once we're able to shift focus to 64bit. *If* that is the
> release immediately after Fulcrum, I cannot comment.

I have the impression that you do not have enough staff. Why don't you 
hire one or two developers? Here are a lot of people hanging around who 
would help you at once. ;-)

-- 
Best regards,

Roman
0
Roman
1/22/2010 11:34:15 PM
Hello,

Roman Kassebaum wrote:

> Why don't you use the best language in the world? ;-)

I guess Haskell hasn't been available back then.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/22/2010 11:49:36 PM
Roman Kassebaum wrote:

> So, you are implementing the compiler with C, aren't you? Shame on
> you! :-)
> 
> Why don't you use the best language in the world? ;-)

Probably because it would be a complete rewrite, with all the dangers
that harbours. <g>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"If everything seems under control, you're just not going fast 
 enough." -- Mario Andretti
0
Rudy
1/22/2010 11:56:58 PM
Roman Kassebaum wrote:

> Allen,
> 
> > We're certainly working on the 64bit compiler since I regularly see
> > checkins like this at least once or more a week:
> > 
> > ====
> > 27406 trunk/com/ decl.c 	8/0 	Thu Jan 21 06:05:09 2010 UTC 	ytagawa
> > 27406 trunk/com/ objout.c 	4/0 	Thu Jan 21 06:05:09 2010 UTC
> > ytagawa    	Log:
> > [dcc64] initial parOff is 16 for x64 instead of 8 for 32bit.
> > ====
> 
> So, you are implementing the compiler with C, aren't you? Shame on
> you! :-)

It's been in C since Delphi 2. Prior to that it was all in assembler.
 
> Why don't you use the best language in the world? ;-)

That is the proverbial bootstrapping problem.

> > That doesn't mean it is "all-hands-on-deck" for the 64 bit compiler,
> > that distinction belongs to the Fulcrum (x-plat) project as that is
> > the closest release. However, please know that we're working to the
> > best of our ability to ensure we're going to be able to "hit the
> > ground running" once we're able to shift focus to 64bit. If that is
> > the release immediately after Fulcrum, I cannot comment.
> 
> I have the impression that you do not have enough staff. Why don't
> you hire one or two developers? Here are a lot of people hanging
> around who would help you at once. ;-)

If only it were actually simple. How, exactly, do you propose these new
folks get paid ;-)?

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
1/23/2010 1:37:29 AM
Allen Bauer wrote:

> > I have the impression that you do not have enough staff. Why don't
> > you hire one or two developers? Here are a lot of people hanging
> > around who would help you at once. ;-)
> 
> If only it were actually simple. How, exactly, do you propose these
> new folks get paid ;-)?

Well at least don't charge them if they want to receive the next
official version (*).


(*) Sorry some bad experience from the past about a serial
communication suite, which had a nasty bug costing us a lot of time of
testing, providing info, and giving hints about possible solutions and
when it was finally was fixed and we wanted to receive an official
version containing the fix as suggested by us, we couldn't get it and
were forwarded to their sales department...

This was in the MS-DOS 3.x area and we spent a couple of weeks trying
to get this fixed and then to receive a message like "the update price
of that new fixed version is $40" ...

<suppressing my real feelings about it, to prevent cancellation>
@#$I%^$@$#^@%^&*!!!!!
</>


-- 
Pieter

"The most important job is not to be Governor, or First Lady in 
 my case." -- George W. Bush
0
Pieter
1/23/2010 2:35:02 AM
Pieter Zijlstra wrote:

> 
> Well at least don't charge them if they want to receive the next
> official version (*).
> 
> 
> (*) Sorry some bad experience from the past about a serial
> communication suite, which had a nasty bug costing us a lot of time of
> testing, providing info, and giving hints about possible solutions and
> when it was finally was fixed and we wanted to receive an official
> version containing the fix as suggested by us, we couldn't get it and
> were forwarded to their sales department...
> 
> This was in the MS-DOS 3.x area and we spent a couple of weeks trying
> to get this fixed and then to receive a message like "the update price
> of that new fixed version is $40" ...
> 
> <suppressing my real feelings about it, to prevent cancellation>
> @#$I%^$@$#^@%^&*!!!!!
> </>


I am sorry, but I can't see how your bad experiences are relevant in
the context of Allen's post?




Regards,
Zenon
0
Zenon
1/23/2010 5:16:02 AM
Allen Bauer wrote:

> > 
> > I have the impression that you do not have enough staff. Why don't
> > you hire one or two developers? Here are a lot of people hanging
> > around who would help you at once. ;-)
> 
> If only it were actually simple. How, exactly, do you propose these
> new folks get paid ;-)?


I have found the pictures of the Delphi team
http://wings-of-wind.com/2009/08/25/rad-studio-2010-released/

looks like there are indeed not too many people there especially for a
big product like RAD Studio is.

BTW. It is a sad thing that the owners of the comapny can't seize the
opportunity the Delphi is and are cheap enough to not be able to spare
few million dolars as an investment in the comapany's future.


I wish Delphi community could step in and help you guys to develop a
product.


Regards,
Zenon
0
Zenon
1/23/2010 5:27:05 AM
Roman Kassebaum wrote:

> So, you are implementing the compiler with C, aren't you? Shame on
> you! :-)
>
> Why don't you use the best language in the world? ;-)

There aren't a lot of good lexers and compiler generators available in
Object Pascal unfortunately**. One notable exception was DCG by Mike
Lischke, but it was also quite bug-ridden. My own implementation, which is
based partially on DCG, works perfectly however and it allows you to
implement any parser of your own choice (personally I think it's a much
better alternative then the traditional Lex & YACC). I'm planning to make it
public at some point, but at the moment this is *not* at the top of the 
list.

** I can't say if this is the reason they use C for the implementation.

Mattias
0
Mattias
1/23/2010 8:27:08 AM
Allen,

>> So, you are implementing the compiler with C, aren't you? Shame on
>> you! :-)
>
> It's been in C since Delphi 2. Prior to that it was all in assembler.

AFAIK, you are implementing a new compiler from the stretch. This means 
you are able to change the language.


>> Why don't you use the best language in the world? ;-)
>
> That is the proverbial bootstrapping problem.

Are you sure cause there is already an existing Delphi compiler? 
Although this compiler only produces 32-bit code and is written in C, it 
allows you to compile the next compiler generation.

Please, consider your marketing strategy. You do produce the fastest 
compiler and a wonderful language but you don't use it yourself. :-(


>> I have the impression that you do not have enough staff. Why don't
>> you hire one or two developers? Here are a lot of people hanging
>> around who would help you at once. ;-)
>
> If only it were actually simple. How, exactly, do you propose these new
> folks get paid ;-)?

With the money you do not loose cause of delivering too late. ;-)
Some of us would (an already do) help you without being paid.

-- 
Roman
0
Roman
1/23/2010 8:35:25 AM
Mattias,

> There aren't a lot of good lexers and compiler generators available in
> Object Pascal unfortunately**. One notable exception was DCG by Mike
> Lischke, but it was also quite bug-ridden. My own implementation, which is
> based partially on DCG, works perfectly however and it allows you to
> implement any parser of your own choice (personally I think it's a much
> better alternative then the traditional Lex&  YACC). I'm planning to make it
> public at some point, but at the moment this is *not* at the top of the
> list.

I hope that Allen will read about this.

-- 
Roman
0
Roman
1/23/2010 10:20:47 AM
Hello,

Roman Kassebaum wrote:

> > That is the proverbial bootstrapping problem.
> 
> Are you sure cause there is already an existing Delphi compiler? 

how would you port that to another platform (e.g. Linux in the Kylix
days)?

Also, I'm not so sure whether Delphi is the right language for a
compiler. Delphi is a great tool, but there are a few things which are
better done in C or C++, and IMO this applies to kernel drivers and
compilers.


> Please, consider your marketing strategy. You do produce the fastest 
> compiler and a wonderful language but you don't use it yourself. :-(

DCC is built with C++Builder. Isn't that enough? :)
Also, the IDE is built with Delphi.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/23/2010 10:44:34 AM
Hello,

Mattias Andersson wrote:

> There aren't a lot of good lexers and compiler generators available in
> Object Pascal unfortunately**.

DCC features a hand-written lexer and parser and does not rely on a
generator. Read Barry's comments here:

http://stackoverflow.com/questions/199627/converting-c-source-to-c/201922#201922

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/23/2010 10:44:35 AM
Moritz,

> how would you port that to another platform (e.g. Linux in the Kylix
> days)?

First I would write the compiler and compile it with Delphi32. I can't 
sea a reason why Delphi32 shouldn't be able to produce a 64-bit compiler 
for Linux.


> Also, I'm not so sure whether Delphi is the right language for a
> compiler. Delphi is a great tool, but there are a few things which are
> better done in C or C++, and IMO this applies to kernel drivers and
> compilers.

I'm not an expert in producing compilers. I suppose that the guys from 
Embarcadero will know this better. My original post was only a joke.


> DCC is built with C++Builder. Isn't that enough? :)
> Also, the IDE is built with Delphi.

I would be very happy about a Delphi-built compiler. :-)

-- 
Roman
0
Roman
1/23/2010 10:59:58 AM
> Hello,
>
> DCC features a hand-written lexer and parser and does not rely on a
> generator. Read Barry's comments here:
>
> http://stackoverflow.com/questions/199627/converting-c-source-to-c/201922#201922

Interesting. I wonder what parts of the grammar are not LALR(1) or a LR(1) 
compatible though. I can understand the argument that using a hand-written 
compiler will allow you to more easily extend the language, since it avoids 
the problem of maintaining consistent shift/reduce tables. In my own 
implementation, the non-terminals of the AST are represented as separate 
classes, which makes it very easy to perform any kind of recursive 
processing.

Mattias
0
Mattias
1/23/2010 11:27:48 AM
Mattias Andersson schrieb:

>> So, you are implementing the compiler with C, aren't you? Shame on
>> you! :-)
>>
>> Why don't you use the best language in the world? ;-)
> 
> There aren't a lot of good lexers and compiler generators available in
> Object Pascal unfortunately**.

CoCo/R exists since many years, and I created an OO version of it. While 
C has one LL[2] part in its grammar, C++ may require more lookahead. But 
this should not be a really limiting factor, most production LL parsers 
are handcrafted, maybe based on a skeleton made by an compiler generator.

DoDi
0
Hans
1/23/2010 12:03:45 PM
Hello,

Hans-Peter Diettrich wrote:

> C++ may require more lookahead.

infinite lookahead, AFAIK.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/23/2010 12:34:37 PM
Hans-Peter Diettrich wrote:
> CoCo/R exists since many years, and I created an OO version of it.
> While C has one LL[2] part in its grammar, C++ may require more
> lookahead. But this should not be a really limiting factor, most
> production LL parsers are handcrafted, maybe based on a skeleton made
> by an compiler generator.

That's very cool. On the other hand, C can be perfectly parsed with an LR(1) 
parser. I think I did implement an LL parser too, but compared to 
implementing an LR parser, that was quite a bit less painful.

I found the following page that I think partially answered my question 
though (it's about why C++ can not be parsed with an LR(1) parser):

http://stackoverflow.com/questions/243383/why-c-cannot-be-parsed-with-a-lr1-parser

However, after reading the answer, I understand that the kind of compiler 
generator I've implemented will actually produce a GLR parser; which is 
capable of resolving this problem.

Mattias
0
Mattias
1/23/2010 12:59:11 PM
Mattias Andersson wrote:

> However, after reading the answer, I understand that the kind of
> compiler generator I've implemented will actually produce a GLR
> parser; which is capable of resolving this problem.

Actually it does not produce a GLR parser and I think a GLR parser has some 
disadvantages in terms of performance. However, it should be possible to 
resolve conflicts in a way similar to what a GLR parser does.

Mattias
0
Mattias
1/23/2010 1:41:21 PM
Allen Bauer wrote:

> > So, you are implementing the compiler with C, aren't you? Shame on
> > you! :-)
> 
> It's been in C since Delphi 2. Prior to that it was all in assembler.
>  
> > Why don't you use the best language in the world? ;-)
> 
> That is the proverbial bootstrapping problem.

Really? I rather guess back in 199x it has been a strategic decision
(in order to reuse parts for C++) or just due historical reasons
(because there were already C++ compilers for Win32 and the compiler
could be native from start).

I think you could have started to write the 9.0 Win32 compiler with the
7.0 or 8.0 16-bit compiler and when the RTL was done and it was able to
compile itself it just had compiled itself.

Now the reason is either that you don't rewrite it 100% from scratch or
the usage of the backend for C++.

I don't have a problem with the fact that the compiler is written in
C/C++, but a Delphi compiler not written in Delphi is an argument
related to trust in Delphi/keeping the faith. A Delphi compiler written
in Delphi is not necessarily the better Delphi compiler, because the
compiler is written by humans and not by the language.
-- 
Uwe
0
Uwe
1/23/2010 4:48:03 PM
Moritz Beutel wrote:

> Roman Kassebaum wrote:
> 
> > > That is the proverbial bootstrapping problem.
> > 
> > Are you sure cause there is already an existing Delphi compiler? 
> 
> how would you port that to another platform (e.g. Linux in the Kylix
> days)?

First cross compilation and when the RTL is done then you can build the
native compiler. Right?

> Also, I'm not so sure whether Delphi is the right language for a
> compiler. 

With my little knowledge I don't see a reason why a Delphi compiler
written in Delphi would be slower or why it would take longer to add
new features to it/it would be harder to maintain.

> Delphi is a great tool, but there are a few things which are
> better done in C or C++, and IMO this applies to kernel drivers and
> compilers.

About kernel drivers you can find some information here

"Writing Drivers in Delphi"
http://w-shadow.com/blog/2006/10/12/writing-drivers-in-delphi/

Related to the compiler - FPC does meanwhile compile itself.
-- 
Uwe
0
Uwe
1/23/2010 5:07:29 PM
Hello,

Uwe Schuster wrote:

> First cross compilation and when the RTL is done then you can build
> the native compiler. Right?

using GCC to build a Linux version of your sources sure beats that.


> > Also, I'm not so sure whether Delphi is the right language for a
> > compiler. 
> 
> With my little knowledge I don't see a reason why a Delphi compiler
> written in Delphi would be slower or why it would take longer to add
> new features to it/it would be harder to maintain.

I just don't see how a compiler would benefit from Delphi's
higher-level features. This is different in C++.

Anyway, the discussion is moot, since rewriting DCC in another language
just for the sake of it would be insane, IMHO.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/23/2010 5:26:15 PM
Uwe,

> I don't have a problem with the fact that the compiler is written in
> C/C++, but a Delphi compiler not written in Delphi is an argument
> related to trust in Delphi/keeping the faith. A Delphi compiler written
> in Delphi is not necessarily the better Delphi compiler, because the
> compiler is written by humans and not by the language.

+1

-- 
Roman
0
Roman
1/23/2010 5:46:23 PM
Hello,

Uwe Schuster wrote:

> but a Delphi compiler not written in Delphi is an argument related to
> trust in Delphi/keeping the faith.

just like Office being written in native C++ is an argument related to
..NET?

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/23/2010 5:49:27 PM
Moritz,

>> but a Delphi compiler not written in Delphi is an argument related to
>> trust in Delphi/keeping the faith.
>
> just like Office being written in native C++ is an argument related to
> .NET?

I still think that Delphi is the best language. I made the experience 
that it is easier to write something with Delphi than with C.
Why shouldn't the implementation of a compiler shouldn't be easier with 
Delphi?

-- 
Roman
0
Roman
1/23/2010 7:21:25 PM
Moritz Beutel wrote:

> > but a Delphi compiler not written in Delphi is an argument related
> > to trust in Delphi/keeping the faith.
> 
> just like Office being written in native C++ is an argument related to
> .NET?

I don't think that this comparison does work here and BTW, doesn't use
VStudio 2010 WPF, which is .NET, and VS2010 has been delayed, because
of the slowness of WPF?

You know that people often use arguments, which aren't arguments, but
they seem to be arguments when not thinking about them. I haven't read
all these 64-bit or "Delphi is dead" threads, but maybe someone used
the fact that the Delphi compiler is not written in Delphi/won't be
rewritten in Delphi to proof that Delphi is dead and to tell us that we
should rather look for another Dev tool.

C/C++ isn't that bad, but Delphi is the language of my choice and it's
not that different with my relation to SCM systems.
-- 
Uwe
0
Uwe
1/23/2010 8:40:33 PM
Moritz Beutel <Moritz Beutel schrieb:

> Hans-Peter Diettrich wrote:
> 
>> C++ may require more lookahead.
> 
> infinite lookahead, AFAIK.

Infinite lookahead is not a solution for ambiguous grammars. IMO it's 
perfectly valid if a compiler asks the user to disambiguate the source 
code himself, instead of guessing what could have been meant.

DoDi
0
Hans
1/23/2010 9:12:14 PM
Mattias Andersson wrote:

> Roman Kassebaum wrote:
> 
> > So, you are implementing the compiler with C, aren't you? Shame on
> > you! :-)
> > 
> > Why don't you use the best language in the world? ;-)
> 
> There aren't a lot of good lexers and compiler generators available in
> Object Pascal unfortunately**.

I assume they would write their own. That's their business, isn't it?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The corporation is a true Frankenstein's monster, an
 artificial person run amok, responsible only to its own
 soulless self."
 -- William Dugger
0
Rudy
1/23/2010 10:45:26 PM
Rudy Velthuis (TeamB) wrote:

>>> Why don't you use the best language in the world? ;-)
>>
>> There aren't a lot of good lexers and compiler generators available
>> in Object Pascal unfortunately**.
>
> I assume they would write their own. That's their business, isn't it?

Honestly Rudy, I've not expressed an opinion along these lines at all. I did 
read some of the comments made by Barry Kelly and I think that was really a 
bit of en eye-opener for me. I didn't fully comprehend the nature of 
commercial compiler development earlier. At the same time, I'm curious about 
what are the limiting factors when using a compiler generator as opposed to 
using a hand-written compiler.

I think you should try to leave that car incident behind.

Mattias
0
Mattias
1/23/2010 11:05:54 PM
Mattias Andersson wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> >>> Why don't you use the best language in the world? ;-)
> > > 
> >> There aren't a lot of good lexers and compiler generators available
> >> in Object Pascal unfortunately**.
> > 
> > I assume they would write their own. That's their business, isn't
> > it?
> 
> Honestly Rudy, I've not expressed an opinion along these lines at
> all. 

I don't follow, sorry. They do write compilers, don't they? That makes
me think they are not dependent on existing compiler generators.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Why don't you write books people can read?"
 -- Nora Joyce to her husband James (1882-1941)
0
Rudy
1/23/2010 11:33:10 PM
"Rudy Velthuis (TeamB)" <newsgroups@rvelthuis.de> wrote in message 
news:206121@forums.codegear.com...
> Mattias Andersson wrote:
>
>> Rudy Velthuis (TeamB) wrote:
>>
>> >>> Why don't you use the best language in the world? ;-)
>> > >
>> >> There aren't a lot of good lexers and compiler generators available
>> >> in Object Pascal unfortunately**.
>> >
>> > I assume they would write their own. That's their business, isn't
>> > it?
>>
>> Honestly Rudy, I've not expressed an opinion along these lines at
>> all.
>
> I don't follow, sorry. They do write compilers, don't they? That makes
> me think they are not dependent on existing compiler generators.

I think the question was why doesn't Embarcadero write the new 64-bit 
compiler and/or cross-compiler in Delphi.

My guesses would be 1) because a lot of the existing C code of the 32-bit 
compiler can be reused, and 2) folks who are experts at writing compilers 
use C (C++).

- David Harper
0
David
1/23/2010 11:45:46 PM
David Harper wrote:

> I think the question was why doesn't Embarcadero write the new 64-bit 
> compiler and/or cross-compiler in Delphi.

Yes, indeed. I said the fact they couldn't find a useful compiler
generator can't be the reason.
 
> My guesses would be 1) because a lot of the existing C code of the
> 32-bit compiler can be reused, and 2) folks who are experts at
> writing compilers use C (C++).

My guess is that they don't want to rewrite the compiler. The original
TP/Delphi 1 compiler was written in assembler, and rewritten in C for
Delphi 2. From there on, it was only modified/enhanced.

Rewriting has one severe disadvantage: it is error prone. Even if they
just translated the code from C to Delphi, the chance they'd introduce
errors would be considerable. The fact they must change code generation
is already a big source of possible errors.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"I have yet to meet a C compiler that is more friendly and easier 
 to use than eating soup with a knife." -- unknown
0
Rudy
1/23/2010 11:55:38 PM
Rudy Velthuis (TeamB) wrote:

> I don't follow, sorry. They do write compilers, don't they? That makes
> me think they are not dependent on existing compiler generators.

Well, a lot of compilers are dependent on existing compiler generators -- I 
don't know why you would think otherwise.

Mattias
0
Mattias
1/24/2010 12:19:03 AM
Hello,

Roman Kassebaum wrote:

> I still think that Delphi is the best language. I made the experience 
> that it is easier to write something with Delphi than with C.

mind you, I often find things easier to implement in C or C++. The
cause might be that I'm used to C++, and you are used to Delphi. I can
write software in Delphi, in Java or even in BASIC if I need to, and I
appreciate the assets they have when compared to C++, but at the end of
the day I can't disclaim some kind of affinity to the tools I grew up
with.

What I've learned in the last years, however, is that this experience
doesn't qualify to judge which language would be the "best".


> Why shouldn't the implementation of a compiler shouldn't be easier
> with Delphi?

Since you're the one who requests a rewrite, please do explain why it
should :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/24/2010 12:26:43 AM
Hello,

Uwe Schuster wrote:

> I don't think that this comparison does work here

.... because?
Every rewrite costs a lot of time and causes an endless plethora of new
bugs and incompatibilities. Rewriting a large and important piece of
software just for the fun of it is commercial suicide.


> and BTW, doesn't use VStudio 2010 WPF

Yes.


> which is .NET

Which is one of the libraries provided for the .NET framework. WPF
being slow doesn't disqualify .NET.


> and VS2010 has been delayed, because of the slowness of WPF?

I don't know about WPF (or about VS 2010), but on a related note, I
know that WinForms is often considered slow. The reason is that
WinForms uses GDI+ for graphics, a pretty native library which is
dog-slow due to lack of hardware acceleration.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/24/2010 12:26:44 AM
Moritz,

> mind you, I often find things easier to implement in C or C++. The
> cause might be that I'm used to C++, and you are used to Delphi. I can
> write software in Delphi, in Java or even in BASIC if I need to, and I
> appreciate the assets they have when compared to C++, but at the end of
> the day I can't disclaim some kind of affinity to the tools I grew up
> with.

I also have to work with different languages, C++, C#, Visual Basic, 
Delphi and Prism. Most of the time for me it is easier to work with Delphi.


> What I've learned in the last years, however, is that this experience
> doesn't qualify to judge which language would be the "best".

You shouldn't take this statement as a serious conclusion. I justed 
wanted to make some kind of advertisement for Delphi. :)


> Since you're the one who requests a rewrite, please do explain why it
> should :)

AFAIK the guys from Embarcadero had to rewrite the compiler. This is 
what I read in one blog.

-- 
Roman
0
Roman
1/24/2010 12:41:45 AM
Zenon Jordan wrote:

> Pieter Zijlstra wrote:
> 
> > Allen Baur wrote:
> >
> > > If only it were actually simple. How, exactly, do you propose
> > > these new folks get paid ;-)?
> > 
> > Well at least don't charge them if they want to receive the next
> > official version (*).
> > 
> > [snipped the irrelevant bad experience part] 
> 
> I am sorry, but I can't see how your bad experiences are relevant in
> the context of Allen's post?

I was aiming at the "how ... folks get paid" part from Allen's post.

I'm aware that the "bad experience" I described happened a long time
ago in a totally different world and amounts of work/money involved.

What I was thinking about is that there might be some developers here
who might be interested in helping to develop a new compiler and have
the acquired knowledge (JFTR I'm not one of them).

Some of them might be willing to do that for "free", either just as a
hobby or thinking that "the costs" (read: time) may be better spent on
helping EMBT than on switching to another Language / Framework / IDE /
Compiler.

The point was: If there are some here who qualify and can add a
substantional amount of work/time in to that project ... don't charge
them for the next release containing (parts of) their work.

Not that I really think something like this will ever happen ...

.... but OTOH, you never know.

-- 
Pieter

"Probably no nation is rich enough to pay for both war and
 education."
 -- Braham Flexner
0
Pieter
1/24/2010 1:21:58 AM
Mattias Andersson wrote:

> Rudy Velthuis (TeamB) wrote:
> 
> > I don't follow, sorry. They do write compilers, don't they? That
> > makes me think they are not dependent on existing compiler
> > generators.
> 
> Well, a lot of compilers are dependent on existing compiler
> generators

So what? They already have a compiler. Converting that to Delphi should
not require the generation of a new one by a compiler generator.

Which compilers are actually dependent on existing compiler generators?
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"It's not at all important to get it right the first time. It's
 vitally important to get it right the last time." 
 -- Andrew Hunt and David Thomas
0
Rudy
1/24/2010 5:49:36 AM
Rudy Velthuis (TeamB) wrote:
> Mattias Andersson wrote:
>
>> Rudy Velthuis (TeamB) wrote:
>>
>>> I don't follow, sorry. They do write compilers, don't they? That
>>> makes me think they are not dependent on existing compiler
>>> generators.
>>
>> Well, a lot of compilers are dependent on existing compiler
>> generators
>
> So what? They already have a compiler. Converting that to Delphi
> should not require the generation of a new one by a compiler
> generator.

I was not making any claims about "converting to Delphi". I was simply 
responding to your assertion that there is no dependency between the 
compiler and the compiler generator.

> Which compilers are actually dependent on existing compiler
> generators?

If you want to change the grammar of the language then this requires you to 
recreate the shift/reduce tables of the parser. The compiler generator will 
also give you skeleton code that you will have to integrate in the existing 
parser. This process may be more demanding depending on what compiler 
generator you're using. It's obviously a different work methodology than 
writing a compiler "by hand".

Mattias
0
Mattias
1/24/2010 9:29:44 AM
Hello,

Roman Kassebaum wrote:

> AFAIK the guys from Embarcadero had to rewrite the compiler. This is 
> what I read in one blog.

ah, I see. My understanding was that Embarcadero wasn't planning for a
total rewrite but rather an evolution. Looking at all the time and
effort that is put into the new OS X and x64 backend, one could hardly
imagine Embarcadero to just throw that work away.

However, this is something Allen or Nick could clear up.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/24/2010 12:22:52 PM
Mattias Andersson wrote:

> >> Well, a lot of compilers are dependent on existing compiler
> >> generators
> > 
> > So what? They already have a compiler. Converting that to Delphi
> > should not require the generation of a new one by a compiler
> > generator.
> 
> I was not making any claims about "converting to Delphi". I was
> simply responding to your assertion that there is no dependency
> between the compiler and the compiler generator.

I never claimed anything like that. I merely said they didn't need any,
since they already have a functioning compiler.

> > Which compilers are actually dependent on existing compiler
> > generators?
> 
> If you want to change the grammar of the language then this requires
> you to recreate the shift/reduce tables of the parser.

I know what a compiler generator does.

I meant: give me examples of existing, widely used compilers that were
generated with the aid of a compiler generator.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Law Of Continuity: Experiments should be reproducible.  They 
should all fail in the same way.
0
Rudy
1/24/2010 12:51:37 PM
Rudy Velthuis (TeamB) wrote:
> Mattias Andersson wrote:
>
>>> Which compilers are actually dependent on existing compiler
>>> generators?
>>
>> If you want to change the grammar of the language then this requires
>> you to recreate the shift/reduce tables of the parser.
>
> I know what a compiler generator does.

Of course you do. It's the one that produce the chassis, before they are 
mounted. <g>

> I meant: give me examples of existing, widely used compilers that were
> generated with the aid of a compiler generator.

If you would have read any literature on "compiler construction", you would 
have learned how to use a compiler generator and most probably not how to 
write it by hand. My guess would be that the vast majority of compilers are 
dependent on a compiler generator, but I don't have the statistics to either 
confirm or refute this.

Mattias
0
Mattias
1/24/2010 1:52:41 PM
Mattias Andersson wrote:

> > I meant: give me examples of existing, widely used compilers that
> > were generated with the aid of a compiler generator.
> 
> If you would have read any literature on "compiler construction", you
> would have learned how to use a compiler generator and most probably
> not how to write it by hand. 

Not what I asked. Anyway, I only read the Dragon Book.

> My guess would be that the vast majority of compilers are dependent on
> a compiler generator

My guess would be that the mainstream ones, like C, C++, C#, Java,
Pascal, Python, Ruby, Perl, etc. are not. I could be wrong, though.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The greatest deception men suffer is from their own opinions."
 -- Leonardo da Vinci
0
Rudy
1/24/2010 2:09:05 PM
Rudy Velthuis (TeamB) wrote:

> > My guess would be that the vast majority of compilers are dependent
> > on a compiler generator
> 
> My guess would be that the mainstream ones, like C, C++, C#, Java,
> Pascal, Python, Ruby, Perl, etc. are not. I could be wrong, though.

OK, I was wrong about Perl and Ruby. Apparently, these use Yacc or
something very similar. Python doesn't use one, AFAICT. Pascal, C and
C++ certainly don't.

I know that the Free Pascal Compiler parser started out as a TP YACC
generated file, but I don't think it still is.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"The right things to do are those that keep our violence in
 abeyance; the wrong things are those that bring it to the
 fore."
 -- Robert J. Sawyer
0
Rudy
1/24/2010 2:43:43 PM
Most likely, the guys writing the compiler write *all* the compilers and 
know 'C'/C++
To write the Delphi compiler in another language that they might not be 100% 
in
would make for a worse compiler.
And now that the compiler is written, you don't re-write it in Delphi just 
because
you can. Companies go bust doing that......
Rgds Pete

"Roman Kassebaum" <roman@nospamremoveitkassebaum.eu> wrote in message 
news:206074@forums.codegear.com...
> Moritz,
>
>>> but a Delphi compiler not written in Delphi is an argument related to
>>> trust in Delphi/keeping the faith.
>>
>> just like Office being written in native C++ is an argument related to
>> .NET?
>
> I still think that Delphi is the best language. I made the experience
> that it is easier to write something with Delphi than with C.
> Why shouldn't the implementation of a compiler shouldn't be easier with
> Delphi?
>
> -- 
> Roman
0
Pete
1/24/2010 3:08:59 PM
Rudy Velthuis (TeamB) wrote:
> Rudy Velthuis (TeamB) wrote:
>
>>> My guess would be that the vast majority of compilers are dependent
>>> on a compiler generator
>>
>> My guess would be that the mainstream ones, like C, C++, C#, Java,
>> Pascal, Python, Ruby, Perl, etc. are not. I could be wrong, though.
>
> OK, I was wrong about Perl and Ruby. Apparently, these use Yacc or
> something very similar. Python doesn't use one, AFAICT. Pascal, C and
> C++ certainly don't.
>
> I know that the Free Pascal Compiler parser started out as a TP YACC
> generated file, but I don't think it still is.

IMO, YACC does not provide the most optimal flexibility when building a 
compiler. I can certainly understand why you would want to look at other 
solutions.

Mattias
0
Mattias
1/24/2010 3:12:40 PM
Rudy Velthuis (TeamB) schrieb:

>>> I assume they would write their own. That's their business, isn't
>>> it?
>> Honestly Rudy, I've not expressed an opinion along these lines at
>> all. 
> 
> I don't follow, sorry. They do write compilers, don't they? That makes
> me think they are not dependent on existing compiler generators.

You are writing applications, aren't you? Then it's your choice whether 
to do that all alone, or using an existing development system and 
related tools (form designers...).

Parser generators create code from a given grammar, while handwritten 
parsers do not always conform to a grammar, in detail when there exists 
no complete formal OPL grammar (last seen in D2).

DoDi
0
Hans
1/24/2010 3:48:00 PM
> {quote:title=Moritz Beutel wrote:}{quote}
 
> Also, I'm not so sure whether Delphi is the right language for a
> compiler. Delphi is a great tool, but there are a few things which are
> better done in C or C++, and IMO this applies to kernel drivers and
> compilers.
[/quote]

Strange remark, specially since C and C++ are further apart than e.g. C++ and Delphi.

I don't see why C++ would be anywhere more fit for a compiler than Delphi. And Free Pascal
proves a multiarchitecture compiler based on the delphi dialect is no problem
0
Marco
1/24/2010 4:07:36 PM
Hello,

Marco van de Voort wrote:

> I don't see why C++ would be anywhere more fit for a compiler than
> Delphi.

Well, in C++ you can always ignore the whole half-baked class model and
use templates to replace your type-unsafe C macros. Not so in Delphi <g>

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/24/2010 7:40:47 PM
"Mattias Andersson" <mattias@centaurix.com> wrote in message 
news:205973@forums.codegear.com...
> Roman Kassebaum wrote:
>
>> So, you are implementing the compiler with C, aren't you? Shame on
>> you! :-)
>>
>> Why don't you use the best language in the world? ;-)
>
> There aren't a lot of good lexers and compiler generators available in
> Object Pascal unfortunately**. One notable exception was DCG by Mike
> Lischke, but it was also quite bug-ridden. My own implementation, which is
> based partially on DCG, works perfectly however and it allows you to
> implement any parser of your own choice (personally I think it's a much
> better alternative then the traditional Lex & YACC). I'm planning to make 
> it
> public at some point, but at the moment this is *not* at the top of the
> list.
>
> ** I can't say if this is the reason they use C for the implementation.
>
> Mattias

Hi Mattias,
    Slightly off topic here, but would you be willing to share your 
DCG-based compiler generator now?

I am really into parser/compiler generators right now LOL

if so, fee free to email me (paulfnicholls AT gmail DOT com)...

I quite understand if you don't want to share till you are ready though :)

cheers,
Paul
0
Paul
1/25/2010 12:01:58 AM
Paul Nicholls wrote:
>
> Hi Mattias,
>    Slightly off topic here, but would you be willing to share your
> DCG-based compiler generator now?
>
> I am really into parser/compiler generators right now LOL
>
> if so, fee free to email me (paulfnicholls AT gmail DOT com)...
>
> I quite understand if you don't want to share till you are ready
> though :)

Let me try to evaluate the state of the project. There are some parts that I 
want to rewrite (particularly the lexer isn't very pretty). On the other 
hand, there is a risk that the project is delayed indefinitely.

I'll send a private e-mail tomorrow.

Mattias
0
Mattias
1/25/2010 1:25:08 AM
"Mattias Andersson" <mattias@centaurix.com> wrote in message 
news:206333@forums.codegear.com...
> Paul Nicholls wrote:
>>
>> Hi Mattias,
>>    Slightly off topic here, but would you be willing to share your
>> DCG-based compiler generator now?
>>
>> I am really into parser/compiler generators right now LOL
>>
>> if so, fee free to email me (paulfnicholls AT gmail DOT com)...
>>
>> I quite understand if you don't want to share till you are ready
>> though :)
>
> Let me try to evaluate the state of the project. There are some parts that 
> I
> want to rewrite (particularly the lexer isn't very pretty). On the other
> hand, there is a risk that the project is delayed indefinitely.
>
> I'll send a private e-mail tomorrow.
>
> Mattias

Thanks for your time, Mattias :)

cheers,
Paul
0
Paul
1/25/2010 1:32:31 AM
Marco van de Voort wrote:

> > {quote:title=Moritz Beutel wrote:}{quote}
>  
> > Also, I'm not so sure whether Delphi is the right language for a
> > compiler. Delphi is a great tool, but there are a few things which
> > are better done in C or C++, and IMO this applies to kernel drivers
> > and compilers.
> [/quote]
> 
> Strange remark, specially since C and C++ are further apart than e.g.
> C++ and Delphi.

Syntactically, they certainly aren't. And C++ is a superset of C, so I
see nothing strange about his remark.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Once you have seen certain things, you can't un-see them, and
 seeing nothing is as political an act as seeing something."
 -- Arundhati Roy
0
Rudy
1/25/2010 2:25:06 AM
Moritz Beutel wrote:

> Hello,
> 
> Marco van de Voort wrote:
> 
> > I don't see why C++ would be anywhere more fit for a compiler than
> > Delphi.
> 
> Well, in C++ you can always ignore the whole half-baked class model
> and use templates to replace your type-unsafe C macros. Not so in
> Delphi <g>

Delphi can also ignore its class model. It does not have macros, so
they don't have to be replaced. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Increasingly, people seem to misinterpret complexity as
 sophistication, which is baffling - the incomprehensible should
 cause suspicion rather than admiration. Possibly this trend
 results from a mistaken belief that using a somewhat mysterious
 device confers an aura of power on the user." -- Niklaus Wirth
0
Rudy
1/25/2010 2:26:41 AM
Moritz Beutel wrote:

> Also, I'm not so sure whether Delphi is the right language for a
> compiler.

Based on what? Of course Delphi is just as suitable for creating a compiler
as C, or probably more so.

But why should Embarcadero port C code that works (probably on more than one
platform)  to a new implementation in Delphi (which still only exists on one
platform) - without any benefit either for E-o or their customers? No, spend
time and money where it makes a difference!

-- 
Anders Isaksson, Sweden
BlockCAD: http://www.blockcad.net  
Gallery: http://www.blockcad.net/gallery/index.htm
0
Anders
1/25/2010 12:02:16 PM
Hello,

Anders Isaksson wrote:

> > Also, I'm not so sure whether Delphi is the right language for a
> > compiler.
> 
> Based on what? Of course Delphi is just as suitable for creating a
> compiler as C, or probably more so.

the question is more like C++ vs. Delphi, not C vs. Delphi. The only
compiler I've ever worked on was mostly written in C, and I remember
that I saw various opportunities to simplify its structure using C++
templates, but I didn't see much use for Delphiisms.


> But why should Embarcadero port C code that works (probably on more
> than one platform)  to a new implementation in Delphi (which still
> only exists on one platform) - without any benefit either for E-o or
> their customers? No, spend time and money where it makes a difference!

Exactly.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/25/2010 1:40:28 PM
Hello,

Rudy Velthuis (TeamB) wrote:

> Delphi can also ignore its class model.

I must have forgotten about that. :)


> It does not have macros, so they don't have to be replaced. <g>

The compiler likely has lots of them - it's written in C. Translating
them to Delphi should be fun. Or not :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/25/2010 1:40:29 PM
Anders Isaksson wrote:

> But why should Embarcadero port C code that works (probably on more
> than one platform)  to a new implementation in Delphi (which still
> only exists on one platform) - without any benefit either for E-o or
> their customers?

We might do that if we were, say, redesigning the front end.....

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/25/2010 4:53:45 PM
Moritz Beutel wrote:

> Hello,
> 
> Rudy Velthuis (TeamB) wrote:
> 
> > Delphi can also ignore its class model.
> 
> I must have forgotten about that. :)
> 
> 
> > It does not have macros, so they don't have to be replaced. <g>
> 
> The compiler likely has lots of them - it's written in C. Translating
> them to Delphi should be fun. Or not :)

Translating macros is not so hard. If they are simple #defines, they
can be replaced by constants. If they are macros, they can often be
replaced by inline functions. Some of them, that define structures
(like DEFINE_GUID ofr whatever it is called) can be done with keyboard
macros (once and for all) that convert them to real code.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A pessimist sees the difficulty in every opportunity; an 
 optimist sees the opportunity in every difficulty."
 -- Sir Winston Churchill (1874-1965)
0
Rudy
1/25/2010 6:38:21 PM
Anders Isaksson wrote:

> But why should Embarcadero port C code that works (probably on more
> than one platform)  to a new implementation in Delphi (which still
> only exists on one platform) - without any benefit either for E-o or
> their customers? 

Fully agreed.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Sometimes a scream is better than a thesis."
 -- Ralph Waldo Emerson
0
Rudy
1/25/2010 6:38:22 PM
Moritz Beutel wrote:

> Hello,
> 
> Anders Isaksson wrote:
> 
> > > Also, I'm not so sure whether Delphi is the right language for a
> > > compiler.
> > 
> > Based on what? Of course Delphi is just as suitable for creating a
> > compiler as C, or probably more so.
> 
> the question is more like C++ vs. Delphi, not C vs. Delphi. The only
> compiler I've ever worked on was mostly written in C, and I remember
> that I saw various opportunities to simplify its structure using C++
> templates, but I didn't see much use for Delphiisms.

Define what you mean with "Delphiisms". 

FWIW, it is very well possible and not unreasonable at all to write
compilers in Delphi. If I had to write one, I would use Delphi, since
it is the language I know best and I can express almost anything with
it.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"It's dangerous to underestimate the intelligence of a customer
 who grew a business that's successful enough to require a large
 and complex set of software" -- Grady Booch
0
Rudy
1/25/2010 6:38:24 PM
Hello,

Rudy Velthuis (TeamB) wrote:

> Translating macros is not so hard.

obviously you haven't seen my macro collection :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/25/2010 7:11:31 PM
Hello,

Rudy Velthuis (TeamB) wrote:

> Define what you mean with "Delphiisms". 

all the things that set Delphi apart of C (many of which are now shared
by e.g. C#), e.g. subclassing polymorphism (for both classes and
objects), anonymous methods and other kinds of syntactical sugar.


> FWIW, it is very well possible and not unreasonable at all to write
> compilers in Delphi.

Sure. It's just that C++ /may/ offer advantages here that Delphi can't
offer; mostly the flexibility of templates.


> If I had to write one, I would use Delphi

Of course you would :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/25/2010 7:11:32 PM
Moritz Beutel <"Moritz Beutel" <>> wrote:

> all the things that set Delphi apart of C (many of which are now shared
> by e.g. C#), e.g. subclassing polymorphism (for both classes and
> objects), anonymous methods and other kinds of syntactical sugar.

Why you might want to use anonymous methods: if you want to delay
evaluation of some kind, such as symbol table lookup, but not have to
write some elaborate fixup or callback mechanism (and possibly need to
worry about arguments). A simple list of closure references can work
nicely here, with variable capture transporting the arguments.

Subclassing polymorphism isn't a Delphiism distinct from C++, but it is
also very useful in compiler implementation, as any kind of interface
encapsulation would be in any system broken up into modules. For
example, consider porting a compiler across multiple different back ends
or platforms: substituting different implementations of a common
interface is far preferable to a liberal sprinkling of #ifdefs and
alternating linker command lines, relying of linker resolution for
different implementations of the same symbols, but without the type
safety.

> Sure. It's just that C++ /may/ offer advantages here that Delphi can't
> offer; mostly the flexibility of templates.

On the other hand, I see templates beyond generic data structure
definition and traversal of relatively little sensible use.

Pattern matching in the style of a functional language, or automatic
support for type equality and memoization, or garbage collection, on the
other hand, would provide large advantages for compiler implementation
over and above either Delphi or C++.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
1/26/2010 12:50:25 AM
Moritz Beutel wrote:

> Hello,
> 
> Rudy Velthuis (TeamB) wrote:
> 
> > Translating macros is not so hard.
> 
> obviously you haven't seen my macro collection :)

No, I haven't. Macros are evil, evil, evil. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"So I went to the dentist. He said "Say Aaah." I said "Why?"
 He said "My dog's died.'" -- Tommy Cooper
0
Rudy
1/26/2010 1:25:52 AM
Moritz Beutel wrote:

> > FWIW, it is very well possible and not unreasonable at all to write
> > compilers in Delphi.
> 
> Sure. It's just that C++ may offer advantages here that Delphi can't
> offer; mostly the flexibility of templates.

Perhaps. 
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A sense of humor is part of the art of leadership, of getting 
 along with people, of getting things done." 
 -- Dwight D. Eisenhower (1890-1969)
0
Rudy
1/26/2010 1:28:10 AM
Hello,

Barry Kelly wrote:

> Why you might want to use anonymous methods: if you want to delay
> evaluation of some kind, such as symbol table lookup, but not have to
> write some elaborate fixup or callback mechanism (and possibly need to
> worry about arguments). A simple list of closure references can work
> nicely here, with variable capture transporting the arguments.

it might be different in your case, but for the compiler I was working
on, the fixups were pretty straightforward (one additional pass after
compilation which simply swapped a few values), and using closures for
those fixups might have doubled or tripled the compilation time since
they were many. (Not to mention that I would have had to write a memory
manager first. <g>)


> Subclassing polymorphism isn't a Delphiism distinct from C++, but it
> is also very useful in compiler implementation, as any kind of
> interface encapsulation would be in any system broken up into
> modules. For example, consider porting a compiler across multiple
> different back ends or platforms: substituting different
> implementations of a common interface is far preferable to a liberal
> sprinkling of #ifdefs and alternating linker command lines, relying
> of linker resolution for different implementations of the same
> symbols, but without the type safety.

Again YMMV, but something like EmitMove(a,b) being a /virtual/ method
would have impacted performance perceptibly in my case.


> On the other hand, I see templates beyond generic data structure
> definition and traversal of relatively little sensible use.

Templates make it possible to have a polymorphic EmitMove(a,b), without
dirty linker tricks and without a virtual function call :) I rarely opt
for static template polymorphism in everyday programming, but I think
it has its uses when performance is critical.


> Pattern matching in the style of a functional language, or automatic
> support for type equality and memoization, or garbage collection, on
> the other hand, would provide large advantages for compiler
> implementation over and above either Delphi or C++.

I don't know about the performance aspects of those (and it seems that
for DCC, performance is highly critical), but I'd certainly agree that
modern functional languages would allow for much more /elegant/
compilers than the classic procedural approach, and that isn't specific
to compilers.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/26/2010 1:43:28 AM
Moritz Beutel <"Moritz Beutel" <>> wrote:

> Barry Kelly wrote:
> 
> > Why you might want to use anonymous methods: if you want to delay
> > evaluation of some kind, such as symbol table lookup, but not have to
> > write some elaborate fixup or callback mechanism (and possibly need to
> > worry about arguments). A simple list of closure references can work
> > nicely here, with variable capture transporting the arguments.
> 
> it might be different in your case, but for the compiler I was working
> on, the fixups were pretty straightforward (one additional pass after
> compilation which simply swapped a few values), and using closures for
> those fixups might have doubled or tripled the compilation time since
> they were many. (Not to mention that I would have had to write a memory
> manager first. <g>)

Not for actual executable or object file fixups, no (tables have to be
produced for those anyway), but things can get complicated if you're
e.g. trying to parse generics in a single pass, where e.g. a method of a
generic type may return an inner type of the type being compiled -
essentially requiring the compiler to instantiate a partial type.

> > Subclassing polymorphism isn't a Delphiism distinct from C++, but it
> > is also very useful in compiler implementation, as any kind of
> > interface encapsulation would be in any system broken up into
> > modules. For example, consider porting a compiler across multiple
> > different back ends or platforms: substituting different
> > implementations of a common interface is far preferable to a liberal
> > sprinkling of #ifdefs and alternating linker command lines, relying
> > of linker resolution for different implementations of the same
> > symbols, but without the type safety.
> 
> Again YMMV, but something like EmitMove(a,b) being a /virtual/ method
> would have impacted performance perceptibly in my case.

EmitMove is too low a level for what I'm talking about, it would be e.g.
at the GenCode(expressionTree) level.

> > On the other hand, I see templates beyond generic data structure
> > definition and traversal of relatively little sensible use.
> 
> Templates make it possible to have a polymorphic EmitMove(a,b), without
> dirty linker tricks and without a virtual function call :) I rarely opt
> for static template polymorphism in everyday programming, but I think
> it has its uses when performance is critical.

Yes, but that would require you to thread the type you are
discriminating the template instantiation by throughout the program,
from the compiler driver through to the code generator, solely to take
advantage of template specialization for this very low-level (in terms
of the abstraction stack) task. Essentially, every method on the call
chain would need to be templated.

> > Pattern matching in the style of a functional language, or automatic
> > support for type equality and memoization, or garbage collection, on
> > the other hand, would provide large advantages for compiler
> > implementation over and above either Delphi or C++.
> 
> I don't know about the performance aspects of those (and it seems that
> for DCC, performance is highly critical), but I'd certainly agree that
> modern functional languages would allow for much more /elegant/
> compilers than the classic procedural approach, and that isn't specific
> to compilers.

When programmers start thinking about performance, odd things start
happening in their heads. Implementations they are familiar with from
past experience become much more desirable than implementations that are
alien to them, or even implementations they haven't thought much about.

There are two kinds of pieces: the set of data structure types to be
processed, and the different pieces of code - the operations - which are
going to work with them. The job is to match the two up. The task is
dynamic, so some kind of runtime lookup is going to be involved (so no
outs via e.g. templates). Typical approaches:

* C: use an enum-discriminated union for the data structure, and a
lookup table of function pointers for the operations. Maintainability
can be improved by e.g. using a header that instantiates an
include-point defined macro, so that you can do e.g.:

fn_ptr ops[] = {
#define T(x) Gen##x
#include "kinds.h"
};

and rely on the compiler finding GenFoo, GenBar etc.

* Object-oriented (C++ / Delphi, though these could use a C-like
approach): use double-dispatch (the visitor pattern) to separate the
code from the data structure definitions, or alternatively include the
operations as virtual methods of the types.

* Functional: use sum types for the data structures and pattern-matched
functions for the operations. This way, the operations are separated
from the data structure definitions, but the implementation is free to
use e.g. the C-style approach of a lookup table for the actual
implementation.

The functional approach enables the combination of better type safety
than the C approach (it's easy to muck up your discriminated unions in
C), better modularization in terms of separating code from data (the
code could be one of many analysis passes, wouldn't want to include
every possible pass in the data structure definitions etc.), but without
the double indirection penalty of the OO approach.

Moreover, pattern matching is more flexible than simple tag-based
lookup. It could look up on multiple arguments, or on fields of the data
structures, but still not pay any penalty for tag-based lookups, by
making the first lookup phase a table lookup on tag, followed by search
trees to narrow down those more specific patterns.

With respect to dcc32's speed, it has grown from maintenance such that
it is hard to disentangle various threads to optimize particular aspects
independent of semantics. C's lack of abstractions hasn't helped. For
example, dcc32 uses hash codes of 1 byte - an unsigned char - throughout
for symbol tables. It's particularly obvious in compiling Windows.pas -
compilation slows down dramatically towards the end of the unit as the
hash bucket chains grow to silly lengths. (This is a reason to keep the
Windows unit early in the uses list, as symbol lookups are performed in
reverse order of uses.) Fixing this hash code issue would mean changing
large portions of the source; most of the hash code lookups are
hand-coded directly, rather than encapsulated in any reasonable way. A
simple comparison of e.g. MS C# compilation speed against dcc32 using
roughly transliterated code - just parsing of declarations, with empty
method bodies - is revealing: dcc32 is usually slower. Dcc32 can win in
other ways, as it can save unit state to DCU while C# must recompile all
..cs in an assembly every time, but it is certainly clear that dcc32 is
no longer benefiting so much from all the assumptions baked into it back
in the early 90s, when machines were less powerful and programs much
smaller.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
1/26/2010 2:20:53 AM
Rudy,

| Macros are evil, evil, evil. <g>

Something else on which we agree! <g>

-- 

   Q

01/25/2010 21:10:01

XanaNews Version 1.19.1.269  [Q's Messing Around Mods]
0
Quentin
1/26/2010 5:12:47 AM
Hello All,

If you want to develop cross-platform software in Delphi. You can do this today using our VGScene library. One code compiled in Delphi and Lazarus and work in Windows, Linux and Mac OS X.

VGScene home - www.ksdev.com

Software was made - www.binerus.com

VGScene speeds the development of all graphical application, providing: a graphical editor integrated in IDE, graphical objects, simplify animation, advanced windows and controls, maximum performance, skinning engine, bitmap effects. VGScene can be used as development tools for SCADA, GIS, CAD and KIOSK applications.
+ Powerful vector engine like Adobe Flash or Microsoft WPF
+ Fast realtime anti-aliased vector graphics, resolution independent, alpha blending, gradient and special visual filling
+ WYSIWYG design-time and run-time designer and property editors
+ Advanced GUI engine - window, button, textbox, numberbox, memo, anglebox, list box and much much more
+ Advanced skinning engine based on vector graphics styles. Cool exists styles - Dark, Modern, Vista, Air.
+ VGScene provides shape primitives for 2D graphics along with a built-in set of brushes, pens, geometries, and transforms
+ Advanced animations techniques calculated in background thread. Easy to use, accuracy, minimal CPU usage and automatic FPS correction
+ VGScene provides for bitmap effects, however, they are rendered in software. Special effects such as dropshadows and blurring are built in.
+ VGScene can be used as development tools for SCADA, GIS, CAD and KIOSK applications
+ Path object have SVG, WPF path data format
+ Very easy to use and powerful layouts. The child elements are recursively arranged by their parents.
+ Layered forms, unicode enabled
+ DB-Aware controls - TvgDBNavigator, TvgDBLabel, TvgDBTextBox and more
+ Jpeg, Png, Tiff and Gif format read/write support on Windows, Mac OS X and Linux
+ Fast thumbnail creation and image processing
+ Cross-platform solution available on Microsoft Windows, Apple Mac OS X and Linux

Eugene
0
Evgeny
1/26/2010 12:50:21 PM
Hello Barry,

first, thanks for taking the time to explain things at length. As
usually I'm learning a lot from reading your posts.


Barry Kelly wrote:

> Yes, but that would require you to thread the type you are
> discriminating the template instantiation by throughout the program,
> from the compiler driver through to the code generator, solely to take
> advantage of template specialization for this very low-level (in terms
> of the abstraction stack) task. Essentially, every method on the call
> chain would need to be templated.

FWIW, I don't like this either, but in fact this is how many C++
libraries are implemented; this is what "modern C++" is considered
today. If you have a look at Boost, you see that most of the libraries
are implemented in the header files only, even the really large ones -
Spirit, Graph, Regex (mostly), not to speak of pathological examples
such as MPL or Preprocessor.

I dislike this as much as everyone who isn't used to fighting swordplay
during compilation. Points are: a) this is not uncommon in C++ code,
and b) it /can/ be of advantage performance-wise.


> When programmers start thinking about performance, odd things start
> happening in their heads. Implementations they are familiar with from
> past experience become much more desirable than implementations that
> are alien to them, or even implementations they haven't thought much
> about.

Yes, I admit that I didn't yet try to implement a compiler in LISP. I
guess I should :)


> * Functional: use sum types for the data structures and
> pattern-matched functions for the operations. This way, the
> operations are separated from the data structure definitions, but the
> implementation is free to use e.g. the C-style approach of a lookup
> table for the actual implementation.
> 
> The functional approach enables the combination of better type safety
> than the C approach (it's easy to muck up your discriminated unions in
> C), better modularization in terms of separating code from data (the
> code could be one of many analysis passes, wouldn't want to include
> every possible pass in the data structure definitions etc.), but
> without the double indirection penalty of the OO approach.

Do you have any pointers for further reading, or even an example? This
sounds very interesting, and I'd love to learn how to better leverage
functional approaches for well-known problems.

Pattern matching - is that like specialized templates in C++, but being
dispatched at runtime?


> With respect to dcc32's speed, it has grown from maintenance such that
> it is hard to disentangle various threads to optimize particular
> aspects independent of semantics. C's lack of abstractions hasn't
> helped. For example, dcc32 uses hash codes of 1 byte - an unsigned
> char - throughout for symbol tables. It's particularly obvious in
> compiling Windows.pas - compilation slows down dramatically towards
> the end of the unit as the hash bucket chains grow to silly lengths.
> (This is a reason to keep the Windows unit early in the uses list, as
> symbol lookups are performed in reverse order of uses.) Fixing this
> hash code issue would mean changing large portions of the source;
> most of the hash code lookups are hand-coded directly, rather than
> encapsulated in any reasonable way. A simple comparison of e.g. MS C#
> compilation speed against dcc32 using roughly transliterated code -
> just parsing of declarations, with empty method bodies - is
> revealing: dcc32 is usually slower. Dcc32 can win in other ways, as
> it can save unit state to DCU while C# must recompile all .cs in an
> assembly every time, but it is certainly clear that dcc32 is no
> longer benefiting so much from all the assumptions baked into it back
> in the early 90s, when machines were less powerful and programs much
> smaller.

Ah, I see. I didn't specifically compare DCC's speed to the speed of cs
or javac. My assumption was mostly based on BCC which probably is the
fastest contemporary C++ compiler out there. I used to tribute this to
it's relatively low-level implementation (as Keimpe stated at
http://home.comcast.net/~spacedomain/spacedomain/resume.html,
preprocessor and character scanner are plain x86 assembly) - but
perhaps I'm wrong :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/26/2010 2:32:51 PM
Quentin Correll wrote:

> Rudy,
> 
> | Macros are evil, evil, evil. <g>
> 
> Something else on which we agree! <g>

Actually, macros that are used to define complete structures or similar
actually make sense and even Delphi could benefit from them, especially
if they could actually have typed parameters. And simple #defines of
values are in fact like pure constants in Delphi.

But macros that are meant to inline code snippets or as a poor
replacement for generics, or are meant to serve similar purposes, are
evil.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Naturally we feel that mentally ill people are not what we are
 looking for when we hire programmers - although there is no
 empirical data to support or contradict that view... Is it
 appropriate to give tests for mental illness to anyone applying
 for any kind of job?" 
 -- Weinberg The Psychology of Computer Programming
0
Rudy
1/26/2010 6:32:07 PM
On Mon, 25 Jan 2010 11:11:31 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>obviously you haven't seen my macro collection :)

that would be quite interesting to see those macros you use to work
with bcb

I personally have lots of one-liners such as
BEGIN_END_UPDATE(SomeObject)
SAVE_RESTORE_PROPERTY(PropName,TObject*,SetValue)
SHOW_HIDE_BUSY(BusyMessage,ProgressMin,ProgressMax)
SAVE_RESTORE_CURSOR
DISABLE_ENABLE_CONTROLS(DataSet)
SAVE_RESTORE_BOOKMARK(DataSet)
etc. not to mention numerous ON_BLOCK_EXIT, ON_BLOCK_EXIT_OBJ and
other scopeguards created from variadic macros

that would be lots of deeply nested try/finally's nightmare if I used
delphi to create the very same code

so while using macros are error-prone sometimes (especially for those
who have no experience with them) they're inevitable at the same time
for those who like to write compact and expressive code

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/27/2010 8:40:03 AM
Hello,

Vladimir Ulchenko wrote:

> > obviously you haven't seen my macro collection :)
> 
> that would be quite interesting to see those macros you use to work
> with bcb

that was a joke. I have written numerous macros which would easily
resist being ported to Delphi, but I don't really use them in
production code :)


> I personally have lots of one-liners such as
> BEGIN_END_UPDATE(SomeObject)
> SAVE_RESTORE_PROPERTY(PropName,TObject*,SetValue)
> SHOW_HIDE_BUSY(BusyMessage,ProgressMin,ProgressMax)
> SAVE_RESTORE_CURSOR
> DISABLE_ENABLE_CONTROLS(DataSet)
> SAVE_RESTORE_BOOKMARK(DataSet)
> etc. not to mention numerous ON_BLOCK_EXIT, ON_BLOCK_EXIT_OBJ and
> other scopeguards created from variadic macros

They all sound reasonable.

The only one I'm using regularly is a generic scopeguard macro:

// -----
#define UCL_PP_EXPAND(...) __VA_ARGS__
#define UCL_PP_CAT2_(a,...) UCL_PP_EXPAND(a ## __VA_ARGS__)
#define UCL_PP_CAT2(a,...) UCL_PP_CAT2_(a, __VA_ARGS__)
#define UCL_SAFEGUARD(arg, init, exit)
\
    class UCL_PP_CAT2(_SG_, __LINE__)                                  \
    {                                                                  \
        typedef decltype (arg) ArgType; /* should be a pointer type */ \
        ArgType object;                                                \
    public:                                                            \
        UCL_PP_CAT2(_SG_, __LINE__) (ArgType _object)                  \
         : object (_object)                                            \
        { init; }                                                      \
        ~UCL_PP_CAT2(_SG_, __LINE__) (void) { exit; }                  \
    } UCL_PP_CAT2(_vSG_, __LINE__) (arg)
// -----

Usage:
// -----
void __fastcall TMyForm::SomeButtonClick(TObject* Sender)
{
  UCL_SAFEGUARD (MyListView->Items,
    object->BeginUpdate (), object->EndUpdate ());
  ...
}
// -----

Works in C++Builder 2009 onwards (it relies on decltype()).

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/27/2010 2:12:34 PM
On Wed, 27 Jan 2010 06:12:34 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>that was a joke. I have written numerous macros which would easily
>resist being ported to Delphi, but I don't really use them in
>production code :)

why not? I do it all the time

>Works in C++Builder 2009 onwards (it relies on decltype()).

looks really interesting
as I still use bcb2006 and don't know yet what that decltype staff is
all about I have to use something like this

#define BEGIN_END_UPDATE(Obj) ScopeGuard
ANONYMOUS_VARIABLE(scopeGuard)=MakeBeginEndUpdate((Obj));
(void)(ANONYMOUS_VARIABLE(scopeGuard));

I wonder whether is is possible to implement something similar in
newer delphi versions in order to avoid aforementioned ubiquitous
nested try/finally boredom?

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/27/2010 3:18:48 PM
Rudy Velthuis (TeamB) laid this down on his screen :
> Moritz Beutel wrote:
>
>> Hello,
>> 
>> Rudy Velthuis (TeamB) wrote:
>> 
>>> Delphi can also ignore its class model.
>> 
>> I must have forgotten about that. :)
>> 
>> 
>>> It does not have macros, so they don't have to be replaced. <g>
>> 
>> The compiler likely has lots of them - it's written in C. Translating
>> them to Delphi should be fun. Or not :)
>
> Translating macros is not so hard. If they are simple #defines, they
> can be replaced by constants. If they are macros, they can often be
> replaced by inline functions. Some of them, that define structures
> (like DEFINE_GUID ofr whatever it is called) can be done with keyboard
> macros (once and for all) that convert them to real code.

I don't think you've tried to translate some
of the headers that I have.
The automatic converters help with the easy stuff.
What remains quickly gets intractable.

Brad.
0
Brad
1/27/2010 3:54:59 PM
Brad White wrote:

> I don't think you've tried to translate some
> of the headers that I have.

Oh, you can make this pretty hard, but that is what makes macros so
evil. <g>

> The automatic converters help with the easy stuff.

I don't do automatic conversions. A few days ago, I tried a few of them
again, and they don't cut it at all. I prefer to convert manually, but
with the aid of this simple tool:

  http://rvelthuis.de/programs/convertpack.html

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A casual stroll through the lunatic asylum shows that faith
 does not prove anything."
 -- Nietzsche
0
Rudy
1/27/2010 4:07:51 PM
Hello,

Vladimir Ulchenko wrote:

> > that was a joke. I have written numerous macros which would easily
> > resist being ported to Delphi, but I don't really use them in
> > production code :)
> 
> why not? I do it all the time

the small ones are all right, but I was rather thinking of a little
framework which I built upon macros and templates and which basically
emulated Delphi's "safecall" convention (i.e. COM exception
firewalling) in C++.


> I wonder whether is is possible to implement something similar in
> newer delphi versions in order to avoid aforementioned ubiquitous
> nested try/finally boredom?

With Delphi's generics it's possible to build some kind of equivalent
for std::auto_ptr<>. However generics differ from templates in that
they're strictly typed at declaration time. I assume your
MakeBeginEndUpdate() is a function template that generates calls to
obj->BeginUpdate() and obj->EndUpdate() regardless of what type obj has
(some kind of static duck typing). You can't do that with generics;
you'd have to write specific scopeguards for TListBox, TTreeView etc.

My generic scope guard, however, is easily portable using anonymous
methods:

// -----
uses
  SysUtils;

type
  TScopeGuard = record
  private
    FExitProc: TProc;
  public
    constructor Create (InitProc, ExitProc: TProc);
  end;

constructor TScopeGuard.Create (InitProc, ExitProc: TProc);
begin
  InitProc;
  FExitProc := ExitProc; // note: assign AFTER calling InitProc!
end;

....
procedure TForm1.Button1Click (Sender: TObject);
var
  LVSG: TScopeGuard;
begin
  LVSG.Create (procedure begin ListView1.BeginUpdate end,
    procedure begin ListView1.EndUpdate end);
  ...
end;
// -----

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/27/2010 6:20:00 PM
Moritz Beutel wrote:

> > I wonder whether is is possible to implement something similar in
> > newer delphi versions in order to avoid aforementioned ubiquitous
> > nested try/finally boredom?
> 
> With Delphi's generics it's possible to build some kind of equivalent
> for std::auto_ptr<>.

A simpler version was already possible using interfaces without
generics.

Alernatively, using anonymous methods (and generics) you can implement
something like C#'s "using()" construct.
    
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"A poem is never finished, only abandoned."
 -- Paul Valery (1871-1945)
0
Rudy
1/27/2010 7:40:46 PM
On Wed, 27 Jan 2010 10:20:00 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>the small ones are all right, but I was rather thinking of a little
>framework which I built upon macros and templates and which basically
>emulated Delphi's "safecall" convention (i.e. COM exception
>firewalling) in C++.

you mean something similar to IErrorInfo support implemented in ATL
headers?

>they're strictly typed at declaration time. I assume your
>MakeBeginEndUpdate() is a function template that generates calls to
>obj->BeginUpdate() and obj->EndUpdate() regardless of what type obj has
>(some kind of static duck typing). You can't do that with generics;

template <class Obj>
class BeginEndUpdate : public ScopeGuardImplBase
{
public:
	static BeginEndUpdate<Obj> MakeGuard(Obj& obj)
	{
		return BeginEndUpdate<Obj>(obj);
	}
	~BeginEndUpdate() throw()
	{
 		SafeExecute(*this);
	}
  void EndUpdate()
  {
  	if(!dismissed_)
    {
	  	obj_.EndUpdate();
      dismissed_=true;
    }
  }
  void Execute() const
  {
  	EndUpdate();
  }
protected:
	BeginEndUpdate(Obj& obj)
		: obj_(obj)
  {
  	obj_.BeginUpdate();

    V_ASSERT(!dismissed_);
  }
	Obj& obj_;
};

template <class Obj>
inline BeginEndUpdate<Obj> MakeBeginEndUpdate(Obj & obj)
{
	return BeginEndUpdate<Obj>::MakeGuard(obj);
}

>  LVSG.Create (procedure begin ListView1.BeginUpdate end,
>    procedure begin ListView1.EndUpdate end);

I'm yet to learn all those newer delphi concepts. doesn't look very
appealing though :) I guess I'll stick with my evil macros for bcb
projects while trying to grasp new methods instead of try/finally for
new delphi projects

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/28/2010 12:10:46 PM
On Wed, 27 Jan 2010 11:40:46 -0800, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:

>A simpler version was already possible using interfaces without
>generics.
>
>Alernatively, using anonymous methods (and generics) you can implement
>something like C#'s "using()" construct.
    
will you please show your alternatives?

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/28/2010 12:11:49 PM
Vladimir Ulchenko wrote:

> On Wed, 27 Jan 2010 11:40:46 -0800, Rudy Velthuis (TeamB)
> <newsgroups@rvelthuis.de> wrote:
> 
> > A simpler version was already possible using interfaces without
> > generics.
> > 
> > Alernatively, using anonymous methods (and generics) you can
> > implement something like C#'s "using()" construct.
>     
> will you please show your alternatives?

The simpler version was integrated in the JCL (not sure how they call
the classes now, I called them guard interfaces).

I'll try to find an example of the Using() procedure.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"He has the attention span of a lightning bolt." 
 -- Robert Redford
0
Rudy
1/28/2010 12:47:55 PM
Hello,

Vladimir Ulchenko wrote:

> you mean something similar to IErrorInfo support implemented in ATL
> headers?

don't know about that. Does ATL provide more than AtlSetErrorInfo()?


> I'm yet to learn all those newer delphi concepts. doesn't look very
> appealing though :)

I find them very appealing. The new RTTI and the support for custom
attributes allows for things which were only possible with .NET or Java
previously. Anonymous methods are sorely missing in C++. And Generics
are better suited than templates for most purposes.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/28/2010 1:10:05 PM
On Thu, 28 Jan 2010 05:10:05 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>don't know about that. Does ATL provide more than AtlSetErrorInfo()?

I guess you better look out ATL headers provided with bcb, I'm not
sure what exactly you're looking for

>I find them very appealing. The new RTTI and the support for custom

I only meant the syntax :)

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/28/2010 2:58:41 PM
On Thu, 28 Jan 2010 04:47:55 -0800, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:

>The simpler version was integrated in the JCL (not sure how they call
>the classes now, I called them guard interfaces).

I wonder how delphi counterpart to one of my one-liners (say
BEGIN_END_UPDATE) could be implemented using JCL ISafeGuard? in
addition I'd like to avoid declaring any guard variables manually (one
of the things I dislike very much in delphi)
I'd like to see ready for use example I could borrow to replace
numerous try/finally in my delphi-based projects with something as
expressive as my bcb macros (no nesting of resource release code
needed)

>I'll try to find an example of the Using() procedure.

thank you

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/28/2010 3:24:39 PM
Vladimir Ulchenko wrote:

> On Wed, 27 Jan 2010 11:40:46 -0800, Rudy Velthuis (TeamB)
> <newsgroups@rvelthuis.de> wrote:
> 
> > A simpler version was already possible using interfaces without
> > generics.
> > 
> > Alernatively, using anonymous methods (and generics) you can
> > implement something like C#'s "using()" construct.
>     
> will you please show your alternatives?

Allen Bauer did it here:


http://blogs.embarcadero.com/abauer/2008/09/25/38870


-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
1/28/2010 5:21:45 PM
Vladimir Ulchenko wrote:

> On Thu, 28 Jan 2010 04:47:55 -0800, Rudy Velthuis (TeamB)
> <newsgroups@rvelthuis.de> wrote:
> 
> > The simpler version was integrated in the JCL (not sure how they
> > call the classes now, I called them guard interfaces).
> 
> I wonder how delphi counterpart to one of my one-liners (say
> BEGIN_END_UPDATE) could be implemented using JCL ISafeGuard? 

I guess one could use a function taking an anonymous method that
performed the body, and which surrounded the body with BeginUpdate and
EndUpdate.

My guards were more meant to free objects when they leave scope. Some
kind of simple RAII objects.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Which is it, is man one of God's blunders or is God one of
 man's?"
 -- Nietzsche
0
Rudy
1/28/2010 5:42:18 PM
Nick Hodges wrote:

> Vladimir Ulchenko wrote:
> 
> > On Wed, 27 Jan 2010 11:40:46 -0800, Rudy Velthuis (TeamB)
> > <newsgroups@rvelthuis.de> wrote:
> > 
> > > A simpler version was already possible using interfaces without
> > > generics.
> > > 
> > > Alernatively, using anonymous methods (and generics) you can
> > > implement something like C#'s "using()" construct.
> >     
> > will you please show your alternatives?
> 
> Allen Bauer did it here:
> 
> 
> http://blogs.embarcadero.com/abauer/2008/09/25/38870

Ah, thanks! I knew I had seen an implementation, but didn't remember
where. <g>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Rules of Optimization:
 Rule 1: Don't do it.
 Rule 2 (for experts only): Don't do it yet."
 -- M.A. Jackson
0
Rudy
1/28/2010 5:43:52 PM
On Thu, 28 Jan 2010 09:42:18 -0800, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:

>I guess one could use a function taking an anonymous method that
>performed the body, and which surrounded the body with BeginUpdate and
>EndUpdate.

I have no experience whatsoever with anonymous delphi methods and have
no rs2010 handy at the moment to try. please show actual code meeting
all my aforementioned requirements if possible. I also looked at
Allen's blog post describing Using but still having troubles figuring
out what analog of mine one-liner DISABLE_ENABLE_CONTROLS(SomeDataset)
will look like? right now I have to type the following
SomeDataSet.DisableControls();
try
  ....
finally
  SomeDataset.EnableControls();
end;

>My guards were more meant to free objects when they leave scope. Some
>kind of simple RAII objects.

understood thanks, but I want something more than that

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/29/2010 7:24:47 AM
Am 29.01.2010 08:24, Vladimir Ulchenko wrote:
> all my aforementioned requirements if possible. I also looked at
> Allen's blog post describing Using but still having troubles figuring
> out what analog of mine one-liner DISABLE_ENABLE_CONTROLS(SomeDataset)
> will look like? right now I have to type the following
> SomeDataSet.DisableControls();
> try
>    ....
> finally
>    SomeDataset.EnableControls();
> end;
>

In the simplest case it'd look something like this:

DisableEnableControls(SomeDataSet, procedure
begin
   // Your code here
end);

-- 
Regards
Jens
0
Utf
1/29/2010 1:02:04 PM
Hello,

Vladimir Ulchenko wrote:

> I have no experience whatsoever with anonymous delphi methods and have
> no rs2010 handy at the moment to try. please show actual code meeting
> all my aforementioned requirements if possible. I also looked at
> Allen's blog post describing Using but still having troubles figuring
> out what analog of mine one-liner DISABLE_ENABLE_CONTROLS(SomeDataset)
> will look like?

the only way to have that statement as an one-liner, I believe, is by
manually adjusting stack pointer and exception frame. I don't see how
this could be achieved in plain Delphi.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/29/2010 1:28:26 PM
On Fri, 29 Jan 2010 05:02:04 -0800, Jens M?hlenhoff
<j.muehlenhoff@accurata.com> wrote:

>In the simplest case it'd look something like this:
>
>DisableEnableControls(SomeDataSet, procedure
>begin
>   // Your code here
>end);

perhaps that code will look even more ugly than original nested
try/finally's when one needs to acquire/release several resources

if it's really minimal possible code to get needed functionality then
I guess it's impossible to achieve what I want in current delphi
(without borrowing from cpp macros and automatic variables)

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/29/2010 3:00:47 PM
On Fri, 29 Jan 2010 05:28:26 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>manually adjusting stack pointer and exception frame. I don't see how
>this could be achieved in plain Delphi.

that was my impression as well. even in modern delphi versions it is
still impossible to make some useful things I accustomed to use in cpp

though it really looks like it borrowed several useful concepts from
other languages in the past few years since bds2006 why it couldn't
bring the most useful techniques from cpp is behind my comprehension.
I mean automatic variables declared in place and evil macros i.e.
preprocessing stuff

anyway thanks for everyone explaining all those new delphi "tricks" I
didn't know before

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/29/2010 3:08:47 PM
Vladimir Ulchenko wrote:

> On Fri, 29 Jan 2010 05:28:26 -0800, Moritz Beutel <"Moritz Beutel" <>>
> wrote:
> 
> >manually adjusting stack pointer and exception frame. I don't see how
> >this could be achieved in plain Delphi.
> 
> that was my impression as well.

FWIW, I had to read earlier in the thread to see what the expansion was
supposed to be in order to understand what was meant:

> 
> Allen's blog post describing Using but still having troubles figuring
> out what analog of mine one-liner DISABLE_ENABLE_CONTROLS(SomeDataset)
> will look like? right now I have to type the following
> SomeDataSet.DisableControls();
> try
>   ....
> finally
>   SomeDataset.EnableControls();
> end;

But on the other hand, it is easy enough to do in Delphi, after the
definition of some utilities. The only "gotcha" is that Delphi scopes
are flat, they cannot be nested like C++ with extra {}. But if you're
going to waste extra lines on the '{' and '}', then the anonymous method
technique will work just as well.

uses SysUtils;

type
  TScopeNotifier = class(TInterfacedObject)
  private
    FProc: TProc;
  public
    constructor Create(const AProc: TProc);
    destructor Destroy; override;
  end;

constructor TScopeNotifier.Create(const AProc: TProc);
begin
  FProc := AProc;
end;

destructor TScopeNotifier.Destroy;
begin
  if Assigned(FProc) then
    FProc;
  inherited;
end;

// Utility function to guarantee conversion to interface
function MakeScopeNotifier(const AProc: TProc): IInterface;
begin
  Result := TScopeNotifier.Create(AProc);
end;

function EnableDisableControls(const AControl: string): IInterface;
begin
  Writeln('Disable controls on ', AControl);
  Result := MakeScopeNotifier(procedure
  begin
    Writeln('Enable controls on ', AControl);
  end);
end;

procedure P;
begin
  EnableDisableControls('Foo');
  Writeln('Controls are disabled now');
end;

begin
  P;
end.

Output:

Disable controls on Foo
Controls are disabled now
Enable controls on Foo

It is equivalent to the try / finally etc. owing to the mechanism behind
reference counting.

-- Barry

-- 
http://barrkel.blogspot.com/
0
Barry
1/29/2010 7:02:39 PM
Vladimir Ulchenko wrote:

> On Fri, 29 Jan 2010 05:28:26 -0800, Moritz Beutel <"Moritz Beutel" <>>
> wrote:
> 
> > manually adjusting stack pointer and exception frame. I don't see
> > how this could be achieved in plain Delphi.
> 
> that was my impression as well. even in modern delphi versions it is
> still impossible to make some useful things I accustomed to use in cpp

That is not necessarily true. It is just done differently. See my reply
to Moritz.


-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Work like you don't need the money. Love like you've never
 been hurt. Dance like nobody's watching."
 -- Satchel Paige
0
Rudy
1/29/2010 8:56:33 PM
Hello,

Barry Kelly wrote:

> [...]
>
> procedure P;
> begin
>   EnableDisableControls('Foo');
>   Writeln('Controls are disabled now');
> end;
> 
> begin
>   P;
> end.
> 
> Output:
> 
> Disable controls on Foo
> Controls are disabled now
> Enable controls on Foo
> 
> It is equivalent to the try / finally etc. owing to the mechanism
> behind reference counting.

wow - discarded ref-counted return values are actually kept alive until
end of scope? That's INCREDIBLY useful :)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/29/2010 11:02:56 PM
Moritz Beutel wrote:

> wow - discarded ref-counted return values are actually kept alive
> until end of scope? That's INCREDIBLY useful :)

Well, apparently it is. <g>

The smallest scope in Delphi is the routine. Any interface created will
not be released until the end of that scope is reached. To make this
happen, "discarded" return values are assigned to hidden (or anonymous,
whatever you prefer) variables.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Ask her to wait a moment - I am almost done."
 -- Carl Friedrich Gauss (1777-1855), while working, when 
    informed that his wife is dying
0
Rudy
1/29/2010 11:40:46 PM
Hello,

Rudy Velthuis (TeamB) wrote:

> The smallest scope in Delphi is the routine. Any interface created
> will not be released until the end of that scope is reached. To make
> this happen, "discarded" return values are assigned to hidden (or
> anonymous, whatever you prefer) variables.

yes, I've read Barry's blog as well, thanks.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/30/2010 12:33:37 AM
Hello,

> My generic scope guard, however, is easily portable using anonymous
> methods:
> 
> [...]

damn - I forgot to call FExitProc :)

Of course this call complicates the situation a bit:

// -----
uses
  SysUtils;

type
  TScopeGuard = record
  private
    FGuard: IInterface;
    FVMT: Pointer;
    FExitProc: TProc;
  public
    constructor Create (InitProc, ExitProc: TProc);
  end;

function NopQueryInterface (Self: Pointer; const iid: TGUID;
  out Obj): HRESULT; stdcall;
begin
  Pointer (Obj) := nil;
  Result := E_NOINTERFACE;
end;
procedure NopAddRef (Self: Pointer); stdcall;
begin
end;
procedure ScopeGuardRelease (Self: Pointer); stdcall;
type
  PScopeGuard = ^TScopeGuard;
begin
  Self := PByte (Self) - SizeOf (IInterface);
  if Assigned (PScopeGuard (Self).FExitProc) then
    PScopeGuard (Self).FExitProc ();
end;

constructor TScopeGuard.Create (InitProc, ExitProc: TProc);
const
  VMT: array[0..2] of Pointer = (
    @NopQueryinterface,
    @NopAddRef,
    @ScopeGuardRelease
  );
begin
  InitProc;
  FVMT := @VMT;
  Pointer (FGuard) := @FVMT;
  FExitProc := ExitProc;
end;
// -----

Note that I'm using nasty hacks to avoid allocating another object. To
see how to do it cleanly, read Barry's blog. Also, I guess in reality
you would use Barry's one-liner anyway. This is just to fix my broken
example.

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/30/2010 7:10:51 PM
> {quote:title=Moritz Beutel wrote:}{quote}
 
> > It does not have macros, so they don't have to be replaced. <g>
> 
> The compiler likely has lots of them - it's written in C. T

(C++ afaik?)

>Translating
> them to Delphi should be fun. Or not :)

That's a legacy argument, and something else then the delphi 
language not being fit to write a compiler.

And there all kinds of strange legacies in Delphi (and compatibles) land,
like Virtual Pascal, a D2 level compiler that is entirely in assembler.
0
Marco
1/30/2010 7:18:20 PM
On Fri, 29 Jan 2010 11:02:39 -0800, Barry Kelly
<bkelly@nospam.codegear.com> wrote:

>It is equivalent to the try / finally etc. owing to the mechanism behind
>reference counting.

thank you, that was the closest approach to what I was looking for.
that's fine for specific types of guards and I definitely will use
that interface-based way. moreover I just discovered that I already
used the very same approach back in 2008 when I implemented
delphi-based component TVPool for general purpose pooling. there are
two functions for getting pooled instance: GetObjInstance and
GetIntfInstance. second one returning interface. quite strange I
didn't propogated it broadly

now what about general purpose scoped guard which is created and used
via ON_BLOCK_EXIT(SomeFunc,Type1 var1,Type2 var2,Type3 var3) and
ON_BLOCK_EXIT_OBJ(SomeObject,TSomeObject::MemberFunc,Type1
param1,Type2 param2,Type3 param3)

is it possible to implement those using say generics or something?

thanks again for your explanation

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/30/2010 9:57:16 PM
Hello,

Vladimir Ulchenko wrote:

> now what about general purpose scoped guard which is created and used
> via ON_BLOCK_EXIT(SomeFunc,Type1 var1,Type2 var2,Type3 var3) and
> ON_BLOCK_EXIT_OBJ(SomeObject,TSomeObject::MemberFunc,Type1
> param1,Type2 param2,Type3 param3)
> 
> is it possible to implement those using say generics or something?

using Barry's code, that should be as simple as

// -----
begin
  MakeScopeNotifier(procedure begin SomeObject.MemberFunc(param1) end);
  ...
end;
// -----
...

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
1/30/2010 10:21:08 PM
On Sat, 30 Jan 2010 14:21:08 -0800, Moritz Beutel <"Moritz Beutel" <>>
wrote:

>  MakeScopeNotifier(procedure begin SomeObject.MemberFunc(param1) end);

not that bad. I think I'll start to use that technique in new delphi
projects when (if) we port to rs2010. I'm used to RAII and glad that
delphi allows me to set resource release guard as one-liner

-- 
Vladimir Ulchenko aka vavan
0
Vladimir
1/31/2010 4:49:22 PM
Allen,

Sorry about the delay in replying to your question, I've been away and  
when I got back there are so many posts to skim - and then I found this  
(and several other) bons mots had not actually been delivered but had  
somehow got stuck in my Outbox.

On Thu, 21 Jan 2010 18:27:02 -0000, Allen Bauer
<abauer@spicedham.codegear.com> wrote:

> What *would* make you think that we're open to suggestions?

The very fact that you are contributing here is a good start! (and Nick  
and Michael Swindell - although Mr Rozlog does seem to have gone quiet  
recently)

But I would guess that you will have a long, uphill struggle to regain  
trust from long-time customers who have been burned in the
past. So if you want to minimise that timescale, you're going to have to  
open up "above and beyond".

Personally, I think it comes down to "you" making it clear to "us" that  
you realise that...

1) You're no longer a small company - which can be excused if it doesn't  
provide the full service.

2) You're no longer a large company - which can dictate what (and when)  
customers +must+ accept.

and..

3) Stop putting all the blame on to the previous management - While a lot  
of bad things did happen back then, the tactic of blaming all the current  
troubles on the previous management loses its efficacy very, very quickly  
(and you've had /much/ longer than Obama) - even more so when many of the  
names are still the same.


I don't really want to post an exhaustive list, but off the top of my  
head, communication about...

1) Roadmaps - yes, they are difficult and yes, you'll get hammered if you  
don't meet the deadlines. Maybe you could take advice from some of your  
partners who do seem capable of producing roadmaps +and+ shipping product  
every three months... http://www.remobjects.com/ROadmap.aspx

2) Activation - Nick said this was "still on the stove" back in November  
2007 - surely it has come to the boil by now?

3) Support of previous versions of your product - Even at the most  
generous reading, RAD Studio 2009 was only in "Active Support" for ten  
months  http://support.codegear.com/article/37740. Not everyone wants to  
(or is capable of) upgrading 15 years of legacy software that often.

4) Active contribution from EMBT employees...
a. in these newsgroups - I'm full of admiration for the help that Peter,  
Wayne, Rudy and others provide for free - but it is *your* product after  
all.
b. following up QC reports rather than passively sitting back waiting for  
user input.

I'm sure others will be able to think of more.


> Remember,
> listening and considering input, is *not* equal to agreeing with or
> acting on said input.

Yes, I do realise!

If you have been, thanks for listening.

-- 
Paul Scott
Information Management Systems
Macclesfield, UK
0
Paul
2/15/2010 3:48:31 PM
Paul Scott wrote:

> 3) Stop putting all the blame on to the previous management - While a
> lot of bad things did happen back then, the tactic of blaming all the
> current troubles on the previous management loses its efficacy very,
> very quickly (and you've had much longer than Obama) - even more so
> when many of the names are still the same.

I'm in complete agreement here that there is no point in blaming
previous management.  But I don't think that happens much if at all.
None of us really talks or thinks about Borland much anymore.  We
certainly recognize that the past is past and that it is time to move
forward.  I don't think it is fair to accuse us of blaming problems on
previous manageemnt.

I do understand why you think that it does happen.  Previous management
is raised all the time here, and we have to point out that we aren't
part of that any more.  Witness how many times someone types the
ever-witty 'BorInriCodeGedero" or
"Borland/Inprise/Borland/CodeGear/Embarcadero". We aren't the one's
bringing up the previous administration much if at all.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
2/15/2010 5:42:24 PM
On 2/15/2010 9:42 AM, Nick Hodges wrote:
>
> I do understand why you think that it does happen.  Previous management
> is raised all the time here, and we have to point out that we aren't
> part of that any more.  Witness how many times someone types the
> ever-witty 'BorInriCodeGedero" or
> "Borland/Inprise/Borland/CodeGear/Embarcadero". We aren't the one's
> bringing up the previous administration much if at all.
>


I'm sure "W" is happy to hear that... <G>

David Erbas-White
0
David
2/15/2010 5:53:27 PM
Paul Scott formulated the question :
> 3) Support of previous versions of your product - Even at the most  
> generous reading, RAD Studio 2009 was only in "Active Support" for ten  
> months  http://support.codegear.com/article/37740. Not everyone wants to  
> (or is capable of) upgrading 15 years of legacy software that often.
>

Nick,

Any comment on this request?
Two years, or two versions, seems like
a minimum to me.

All of our customers are required to be
on a maintenance plan, similar I think to
SourceGear Vault.  So theoretically we
could force all users to upgrade.

Even in that situation, we actively support
two and sometimes three versions, depending
on when in the release cycle.

HTH,
Brad.
0
Brad
2/16/2010 5:20:10 PM
Brad White wrote:

> Any comment on this request?

Check with the support guys -- I don't know what the policy is.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
2/16/2010 8:32:58 PM
Paul Scott wrote:

> Allen,
> 
> Sorry about the delay in replying to your question, I've been away
> and when I got back there are so many posts to skim - and then I
> found this (and several other) bons mots had not actually been
> delivered but had somehow got stuck in my Outbox.
> 
> On Thu, 21 Jan 2010 18:27:02 -0000, Allen Bauer
> <abauer@spicedham.codegear.com> wrote:
> 
> > What would make you think that we're open to suggestions?
> 
> The very fact that you are contributing here is a good start! (and
> Nick and Michael Swindell - although Mr Rozlog does seem to have gone
> quiet recently)
> 
> But I would guess that you will have a long, uphill struggle to
> regain trust from long-time customers who have been burned in the
> past. So if you want to minimise that timescale, you're going to have
> to open up "above and beyond".

We are all too painfully aware of this very thing. Its isn't going to
happen overnight, and we have a lot to prove. All we can do is continue
to try to make the best decisions we can.
 
> Personally, I think it comes down to "you" making it clear to "us"
> that you realise that...

As to the size of the company, I can certainly have my own opinions on
this one (below).
 
> 1) You're no longer a small company - which can be excused if it
> doesn't provide the full service.
> 
> 2) You're no longer a large company - which can dictate what (and
> when) customers +must+ accept.

I'd say that we're in a particularly tough place in terms of our size.
We're too big to be "small." IOW, we should be making some decisions
based on being a larger company. On the other side, we're also too
small to be "big." So we still have to be quick, agile an responsive to
the market. That is a really tough thing to balance. We're still
figuring it out... A clear example of this is how we're trying to get
our roadmaps out publicly.
 
> 3) Stop putting all the blame on to the previous management - While a
> lot of bad things did happen back then, the tactic of blaming all the
> current troubles on the previous management loses its efficacy very,
> very quickly (and you've had much longer than Obama) - even more so
> when many of the names are still the same.

Not all the blame is being placed on them. However, the damage that was
done and the scar-tissue that has built up will take a while to fix. I
don't think we're perfect, but I *do* think we are moving the right
direction. We've been out from under Borland's thumb for a mere 1.5
years. While that is considered eons in "Internet time," it is still
going to be very hard to undo nearly a decade of "fun" while with
Borland.

I have to admit that it is really hard for me to maintain some
perspective on that whole era and not be embittered. That is my "cross
to bear." However, I will "set the record" straight when there seems to
be some sentiment of "nothing has changed because the same bozos are in
charge."
 
> I don't really want to post an exhaustive list, but off the top of my
> head, communication about...
> 
> 1) Roadmaps - yes, they are difficult and yes, you'll get hammered if
> you don't meet the deadlines. Maybe you could take advice from some
> of your partners who do seem capable of producing roadmaps +and+
> shipping product every three months...
> http://www.remobjects.com/ROadmap.aspx

Since there is a lot of strategic planning going on internally (more is
happening today, AAMOF), we really, really have to make sure our ducks
are in a row before we roll things out. I know it sounds like a brush
off, but trying to eat a half-baked cake is pretty gross ;-). (See the
above about the company size)
 
> 3) Support of previous versions of your product - Even at the most  
> generous reading, RAD Studio 2009 was only in "Active Support" for
> ten months  http://support.codegear.com/article/37740. Not everyone
> wants to (or is capable of) upgrading 15 years of legacy software
> that often.

There are some hotfixes we're looking at releasing for RS2009. I don't
know the full scope or the timescale yet, but I know some are in the
works.

I wish we were a larger company, and might be able to have a separate
"maintenance team" that could provide fixes and patches. We try and do
the best we can. Regardless, if you've purchased a support contract, we
*will* support the product in accordance with the contract and have, in
fact, provided custom patches and solutions in the past.
 
> 4) Active contribution from EMBT employees...
> a. in these newsgroups - I'm full of admiration for the help that
> Peter, Wayne, Rudy and others provide for free - but it is your
> product after all.

While we don't have a dedicated "newsgroup team" a lot EMBT employees
do at least read these groups.
 
> b. following up QC reports rather than passively sitting back waiting
> for user input.

I know, personally, that we *do* follow up on many QC reports and have
them brought to our attention all the time. I also know that the team
managers spend a large portion of time mining QC. Every entry has to be
triaged, which means that some will continue to sit. If every report
were the highest priority, then *none* of them are.

That being said, if there are specific ones you feel have been
overlooked, please bring them up here. One or more of the highly
capable QC admins can look at those reports and ensure they're ready
for internal consumption.

> > Remember,
> > listening and considering input, is not equal to agreeing with or
> > acting on said input.
> 
> Yes, I do realise!
> 
> If you have been, thanks for listening.

I hope I have been listening. And thank you for taking the time to
respond. I hope I've respected that by being as equally detailed in my
response.

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
2/16/2010 9:38:00 PM
Allen Bauer wrote:

> Paul Scott wrote:
> 
> > b. following up QC reports rather than passively sitting back
> > waiting for user input.
>
> I know, personally, that we do follow up on many QC reports and have
> them brought to our attention all the time. I also know that the team
> managers spend a large portion of time mining QC. Every entry has to
> be triaged, which means that some will continue to sit. If every
> report were the highest priority, then none of them are.

When I compare the situation today with the situation three years ago I
think it got much better when speaking about the "Reported" reports and
the reports that got opened or otherwise handled. Takahashi-san is
doing a good job and most of the reports get opened very fast.

> That being said, if there are specific ones you feel have been
> overlooked, please bring them up here. One or more of the highly
> capable QC admins can look at those reports and ensure they're ready
> for internal consumption.

The best is to post in the QC newsgroup

embarcadero.public.developernetwork.qualitycentral

Developer Network\QualityCentral
https://forums.embarcadero.com/forum.jspa?forumID=9
-- 
Uwe
0
Uwe
2/16/2010 11:48:59 PM
Uwe Schuster wrote:

> Allen Bauer wrote:
> 
> > Paul Scott wrote:
> > 
> > > b. following up QC reports rather than passively sitting back
> > > waiting for user input.
> > 
> > I know, personally, that we do follow up on many QC reports and have
> > them brought to our attention all the time. I also know that the
> > team managers spend a large portion of time mining QC. Every entry
> > has to be triaged, which means that some will continue to sit. If
> > every report were the highest priority, then none of them are.
> 
> When I compare the situation today with the situation three years ago
> I think it got much better when speaking about the "Reported" reports
> and the reports that got opened or otherwise handled. Takahashi-san is
> doing a good job and most of the reports get opened very fast.
> 
> > That being said, if there are specific ones you feel have been
> > overlooked, please bring them up here. One or more of the highly
> > capable QC admins can look at those reports and ensure they're ready
> > for internal consumption.
> 
> The best is to post in the QC newsgroup
> 
> embarcadero.public.developernetwork.qualitycentral
> 
> Developer Network\QualityCentral
> https://forums.embarcadero.com/forum.jspa?forumID=9

Thanks, Uwe. You're contribution does not go unnoticed within the walls
here. You, and several others are frequently referred to by name... in
a good way ;-).

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
2/17/2010 12:38:42 AM
Allen Bauer wrote:
> Paul Scott wrote:
> 
>> Allen,
>>
>> Sorry about the delay in replying to your question, I've been away
>> and when I got back there are so many posts to skim - and then I
>> found this (and several other) bons mots had not actually been
>> delivered but had somehow got stuck in my Outbox.
>>
>> On Thu, 21 Jan 2010 18:27:02 -0000, Allen Bauer
>> <abauer@spicedham.codegear.com> wrote:
>>
>>> What would make you think that we're open to suggestions?
>> The very fact that you are contributing here is a good start! (and
>> Nick and Michael Swindell - although Mr Rozlog does seem to have gone
>> quiet recently)
>>
>> But I would guess that you will have a long, uphill struggle to
>> regain trust from long-time customers who have been burned in the
>> past. So if you want to minimise that timescale, you're going to have
>> to open up "above and beyond".
> 
> We are all too painfully aware of this very thing. Its isn't going to
> happen overnight, and we have a lot to prove.

One of your main challenges. But I think that you should be a little bit 
more innovative in the Delphi area. 3rd Raid was a good, innovative 
product (hmmm... why I'm speaking at past tense?) but it seems that in 
the Delphi's land the thing are somewhat 'usual'.

And I think that without a/some very-catchy-feature(s) (productivity is 
a feature here), the Delphi for Mac won't gain market share.

> 
> So we still have to be quick, agile an responsive to
> the market. That is a really tough thing to balance. We're still
> figuring it out... A clear example of this is how we're trying to get
> our roadmaps out publicly.
>

One of your main weapons. And in fact, one of your *few* weapons against 
Microsoft, Adobe & Sun. Mind you, you aren't a FOSS foundation.

You must minimize your response time and for this one of the key things 
is to know ASAP what will be our problems tomorrow (where the ball is 
heading, not where the ball is). And for this, your participation here 
is crucial.


> 
> Not all the blame is being placed on them. However, the damage that was
> done and the scar-tissue that has built up will take a while to fix. I
> don't think we're perfect, but I *do* think we are moving the right
> direction. We've been out from under Borland's thumb for a mere 1.5
> years. While that is considered eons in "Internet time," it is still
> going to be very hard to undo nearly a decade of "fun" while with
> Borland.
>

+1

> That is my "cross to bear."

This is a big reason for us to have trust in you. Pride (aka. 'the 
piece-of-cake' effect) is one of the most destructive things for a 
programmer.


> 
> Since there is a lot of strategic planning going on internally (more is
> happening today, AAMOF), we really, really have to make sure our ducks
> are in a row before we roll things out. I know it sounds like a brush
> off, but trying to eat a half-baked cake is pretty gross ;-). (See the
> above about the company size)
>  

Imho, you (as company) are *too* afraid about (short-term) revenues. 
Yes, I read your other posts and I understand from where it comes - but 
I think that you should be more confident more free to innovate. Just a 
little bit. And ask us about what it should be in the product. As you 
know, we are pretty skilled to be vocal if something is wrong.

And don't be afraid to show something which won't be released. Remember 
the 'Delphi Parallel Library'. There was a *good* feedback on that even 
if it wasn't released.

Go ahead and show us new things. But, btw, don't use your skills to 
convince us that the language must be kept as is <vbg>. We really need 
an 'using' keyword. Of course, imho.

>  
>> 4) Active contribution from EMBT employees...
>> a. in these newsgroups - I'm full of admiration for the help that
>> Peter, Wayne, Rudy and others provide for free - but it is your
>> product after all.
> 
> While we don't have a dedicated "newsgroup team" a lot EMBT employees
> do at least read these groups.
>  

I think that's the better approach. The team must focus mainly on their 
job. But they definitely must keep the contact with the 'outside reality'.

-- 

m. Th.

On the Wings of the Wind...
http://wings-of-wind.com/
0
m
2/18/2010 9:30:49 AM
m. Th. formulated on Thursday :
>  We really need 
> an 'using' keyword. Of course, imho.
>
What in the world for??

Whether you mean the VB or the C# incarnation,
Delphi already has that.

IMHO, the C# 'using' was put in place to make
up for the lack in functionality that Delphi
already had.

HTH,
Brad.
0
Brad
2/18/2010 4:43:27 PM
Allen Bauer explained :
> That is a really tough thing to balance. We're still
> figuring it out... A clear example of this is how we're trying to get
> our roadmaps out publicly.
>  

That really threw me.    8: -)
When I first read it, I thought you said
'quickly' instead of 'publicly'

Thanks for the laugh,
Brad.
0
Brad
2/18/2010 4:45:39 PM
Brad White wrote:

> What in the world for??

You already can do "using" in delphi:

http://blogs.embarcadero.com/abauer/2008/09/25/38870

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
2/18/2010 6:33:56 PM
Brad White wrote:

> IMHO, the C# 'using' was put in place to make
> up for the lack in functionality that Delphi
> already had.

Such as? AFAICT, Delphi only has try-finally, which C# also has.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Simplicity is the ultimate sophistication."
 -- Leonardo da Vinci
0
Rudy
2/18/2010 7:42:34 PM
Rudy Velthuis (TeamB) submitted this idea :
> Brad White wrote:
>
>> IMHO, the C# 'using' was put in place to make
>> up for the lack in functionality that Delphi
>> already had.
>
> Such as? AFAICT, Delphi only has try-finally, which C# also has.

The reason that we have to use 'using' in C#
is to make finalization deterministic.
Everything is guaranteed to be cleaned up when
it leaves the scope.
http://msdn.microsoft.com/en-us/library/yh598w02%28VS.80%29.aspx

In Delphi that is called Free.
Or, if you are using interfaces, := nil.

HTH,
Brad.
0
Brad
2/18/2010 9:04:32 PM
Brad White wrote:


> The reason that we have to use 'using' in C#
> is to make finalization deterministic.
> [...]
> In Delphi that is called Free.

	No. That's not right. The closest thing to Delphi's Free in C# is
IDisposable. The following code samples are more or less equivalent:

Delphi:

    foo = TFoo.Create;
    foo.Bar;
    foo.Free;

C#

    foo = new Foo();
    foo.Bar();
    foo.Dispose();

	Neither one is robust. Better would be (again, these are sort of
similar in what they do):

Delphi:

    foo = TFoo.Create;
    try
      foo.Bar;
    finally
      foo.Free;
    end;

C#

    using (var foo = new Foo())
    {
        foo.Bar();
    }

	Like Rudy said, C#'s using is closer to Delphi's try/finally (though
not the same).

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
2/18/2010 9:27:52 PM
After serious thinking Craig Stuntz wrote :
> Brad White wrote:
>
>
>> The reason that we have to use 'using' in C#
>> is to make finalization deterministic.
>> [...]
>> In Delphi that is called Free.
>
> 	No. That's not right. The closest thing to Delphi's Free in C# is
> IDisposable. 

OK, so I didn't give a very good example.
But it has to do with making sure that
everything gets cleaned up deterministicly.

From the source I quoted:
> Using: Defines a scope, outside of which an object or objects 
> will be disposed.
> 
>  Remarks
> 
> C#, through the .NET Framework common language runtime (CLR),
>  automatically releases the memory used to store objects that 
> are no longer required. The release of memory is non-deterministic; 
> memory is released whenever the CLR decides to perform garbage 
> collection. However, it is usually best to release limited 
> resources such as file handles and network connections as 
> quickly as possible.
> 
> The using statement allows the programmer to specify when 
> objects that use resources should release them. The object 
> provided to the using statement must implement the IDisposable 
> interface. This interface provides the Dispose method, which 
> should release the object's resources.
> 
> 

So in effect it wraps the block with Try..Finally
and calls Dispose when the objects go out of scope.

So a better parallel is an interface that goes out of scope.
Sure you could clean up manually, but the point is to have
it be deterministic without calling dispose explicitly.

This Delphi can do with interfaces and C# can't without
using the 'using' clause.

HTH,
Brad.
0
Brad
2/18/2010 9:57:36 PM
Brad White wrote:

> This Delphi can do with interfaces and C# can't without
> using the 'using' clause.

	Again, it's not really a good analogy, since you *must* clean up 95%
of what you allocate in Delphi (exceptions being things like interfaces
and ownership) and you don't need to do that for 95% of what you write
in C# (exceptions being things like file handles and DB transactions).

	Really, it's just different there. C# "can't do" what it largely
doesn't need to do.

	The Delphi user's argument has always been that programmers know
better, but the current raging debate about the most basic aspects of
memory management (the whole FreeAndNil jihad) makes me wonder about
that. :)

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
2/18/2010 10:06:14 PM
Craig Stuntz wrote:

> (the whole FreeAndNil jihad)

LOL!

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
2/18/2010 10:13:16 PM
Hello,

Craig Stuntz wrote:

> (exceptions being things like interfaces and ownership)

.... and exceptions :)

(SCNR.)

-- 
Moritz

"Hey, it compiles! Ship it!"
0
Moritz
2/18/2010 10:15:53 PM
Moritz Beutel wrote:

> > (exceptions being things like interfaces and ownership)
> 
> ... and exceptions :)
> 
> (SCNR.)

	Nice. :)

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
2/18/2010 10:21:01 PM
Moritz Beutel wrote:

> Hello,
> 
> Craig Stuntz wrote:
> 
> > (exceptions being things like interfaces and ownership)
> 
> ... and exceptions :)
> 
> (SCNR.)

And sometimes for..in enumerators...

-- 
Allen Bauer
Embarcadero Chief Scientist
http://blogs.embarcadero.com/abauer
0
Allen
2/18/2010 10:22:49 PM
Brad White wrote:

> Rudy Velthuis (TeamB) submitted this idea :
> > Brad White wrote:
> > 
> >> IMHO, the C# 'using' was put in place to make
> >> up for the lack in functionality that Delphi
> >> already had.
> > 
> > Such as? AFAICT, Delphi only has try-finally, which C# also has.
> 
> The reason that we have to use 'using' in C#
> is to make finalization deterministic.

It is meant to get rid of all resources beside memory. In Delphi, you
do the same, but you must also take care of memory using try-finally.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

Correspondence Corollary: An experiment may be considered a 
success if no more than half of your data must be discarded to 
obtain correspondence with your theory.
0
Rudy
2/18/2010 11:53:31 PM
Brad White wrote:

> So in effect it wraps the block with Try..Finally
> and calls Dispose when the objects go out of scope.

Indeed.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Some cause happiness wherever they go; others, whenever 
 they go." -- Oscar Wilde
0
Rudy
2/18/2010 11:54:29 PM
Moritz Beutel wrote:

> Hello,
> 
> Craig Stuntz wrote:
> 
> > (exceptions being things like interfaces and ownership)
> 
> ... and exceptions :)
> 
> (SCNR.)

LOL!

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"Man was born free, and everywhere he is in chains."
 -- Rousseau
0
Rudy
2/18/2010 11:55:14 PM
Nick Hodges wrote:
> Brad White wrote:
> 
>> What in the world for??
> 
> You already can do "using" in delphi:
> 
> http://blogs.embarcadero.com/abauer/2008/09/25/38870
> 

This was afraid of.

And do you think that that is a natural, clear, lean-and-mean, compact, 
readable, maintainable Delphi/Pascal syntax?

Even I know Allen's post since it was issued, and it is pretty 
straightforward how he did it, I need every time to stay and think how 
to write the so-called 'using'...

Also, there are enough quirks with the above kludge. Just one of them:

Try to compile the code bellow:

procedure TForm7.btn2Click(Sender: TObject);

   function Foo: string; //simple function
   begin
     Result:='';

     Obj.Using<TStringList>(TStringList.Create, procedure (List: 
TStringList)  {syntax := yeck!}
     begin
       List.Add('Enter a value');
       List.Add('which will be shown');
       List.Add('if the "Using" works ok.');
       Result:=InputBox('Testing "Using"', List.Text, '');
     end);
   end;

begin
   ShowMessage(Foo);
end;

It will not.

(The 'Result' variable cannot be "captured" by the anonymous procedure)

See
http://qc.embarcadero.com/wc/qcmain.aspx?d=63369

and the (somewhat) related...

http://wings-of-wind.com/2010/02/11/community-pulse-delphis-killer-feature/
(The part about variables. Btw, the results of the poll are a little bit 
surprising, at least for me... :-))

Also you can implement a slightly different...

using <ref=type.constructor> do
begin
  //code
end;

....and have it only for objects.

my2c, HTH & Food for thought.

-- 

m. Th.

On the Wings of the Wind...
http://wings-of-wind.com/
0
m
2/19/2010 6:09:49 AM
Brad White wrote:
> m. Th. formulated on Thursday :
>>  We really need 
>> an 'using' keyword. Of course, imho.
>>
> What in the world for??
> 
> Whether you mean the VB or the C# incarnation,
> Delphi already has that.
> 
> IMHO, the C# 'using' was put in place to make
> up for the lack in functionality that Delphi
> already had.
> 
> HTH,
> Brad.

Aside the relationship between Delphi and .NET resource protection 
structures (thing which was discussed already), there is another thing 
which wasn't touched: code readability, code quality.

Mind you, can be many nested 'try' blocks and sometimes you must be 
careful what is handled/protected where.

Also, by using 'using' your intent is more clearer (to use locally a 
(usually) short-lived with auto-managed lifetime object) whereas 'try' 
has a much more general meaning.

my0.02c,

-- 

m. Th.

On the Wings of the Wind...
http://wings-of-wind.com/
0
m
2/19/2010 6:27:00 AM
m. Th. wrote:

> And do you think that that is a natural, clear, lean-and-mean,
> compact, readable, maintainable Delphi/Pascal syntax?

I wasn't making any claim as such -- just pointing out that Allen wrote
some pretty cool code.

-- 
Nick Hodges
Delphi Development Manager
Embarcadero Technologies
0
Nick
2/19/2010 6:42:41 AM
Nick Hodges wrote:
> m. Th. wrote:
> 
>> And do you think that that is a natural, clear, lean-and-mean,
>> compact, readable, maintainable Delphi/Pascal syntax?
> 
> I wasn't making any claim as such -- just pointing out that Allen wrote
> some pretty cool code.
> 

In this case we agree. :-)

-- 

m. Th.

On the Wings of the Wind...
http://wings-of-wind.com/
0
m
2/19/2010 1:42:16 PM
Craig Stuntz expressed precisely :
> Brad White wrote:
>
>> This Delphi can do with interfaces and C# can't without
>> using the 'using' clause.
>
> 	Again, it's not really a good analogy, since you *must* clean up 95%
> of what you allocate in Delphi (exceptions being things like interfaces
> and ownership) and you don't need to do that for 95% of what you write
> in C# (exceptions being things like file handles and DB transactions).
>
> 	Really, it's just different there. C# "can't do" what it largely
> doesn't need to do.
>

We must be talking about different things.

Let's take this from the top.

Here is the original point that we are responding to:
> Go ahead and show us new things. But, btw, don't use your skills to 
> convince us that the language must be kept as is <vbg>. We really 
> need an 'using' keyword. Of course, imho.

I think I've made my argument.

In C#, Dispose *will* get called if there is one.
The only thing that 'using' adds is making it
deterministic, which was impossible without 'using'.

I don't see why Delphi needs a using statements.

I see two ways to refute that argument.
1) That description differs from what 'using' really does
2) Delphi does need that functionality for some reason.

But you seem to be arguing with someone else:
> you *must* clean up 95%
> of what you allocate in Delphi 
> and you don't need to do that for 95% of what you write
> in C#

Your turn.

Thanks,
Brad.
0
Brad
2/19/2010 2:48:12 PM
m. Th. explained on 2/19/2010 :
> Brad White wrote:
>> m. Th. formulated on Thursday :
>>>  We really need 
>>> an 'using' keyword. Of course, imho.
>>> 
>> What in the world for??
>> 
>> Whether you mean the VB or the C# incarnation,
>> Delphi already has that.
>> 
>> IMHO, the C# 'using' was put in place to make
>> up for the lack in functionality that Delphi
>> already had.
>> 
>> HTH,
>> Brad.
>
> there is another thing 
> which wasn't touched: code readability, code quality.
>
> Also, by using 'using' your intent is more clearer (to use locally a 
> (usually) short-lived with auto-managed lifetime object) whereas 'try' 
> has a much more general meaning.
>
If I understand your point, 'using' would extend lifetime
management to objects without interfaces, whereas interfaces
could use it but wouldn't need it.

And you think that would make the code more readable.

I'm open to being persuaded, but the only example
I've seen was Allen's.  While he did fine job demonstrating
some very cool things that you could do with generics
and an anonymous procedure, it made the code much
less readable, IMHO.

Do you have an example where it would increase redability
or quality?

Thanks,
Brad.
0
Brad
2/19/2010 3:00:12 PM
Brad White wrote:

> We must be talking about different things.

	I'm mostly trying to keep things technically accurate, which it hasn't
been. It's hard to discuss the benefit of something when it is so
thoroughly wrongly described.

> In C#, Dispose *will* get called if there is one.

	That is wrong. Finalizers *will* get called, although they are very
rarely used. Dispose won't, unless you call it (and sometimes don't
need to be called, anyway*). using has nothing to do with a finalizer.

> The only thing that 'using' adds is making it
> deterministic, which was impossible without 'using'.

	That is also wrong. First, using adds more than determinism, and
second because it's not impossible withoug using, as Rudy correctly
pointed out.

	-Craig

* For example, if you start a transaction and commit it in a finally,
there is no need to Dispose it.

-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
2/19/2010 3:10:05 PM
Brad White wrote:

> In C#, Dispose will get called if there is one.

Not at all. It must be called explicitly, or can be called implicitly
in a using() statement. That is exactly why using() statements exist.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com

"He is a self-made man and worships his creator." 
 -- John Bright
0
Rudy
2/19/2010 5:28:45 PM
> {quote:title=Allen Bauer wrote:}

> Wow, what faith. I'm touched.
> 

Allen, im sorry about that. 
Happens we feel a select group of people in a closed room are thinking wich is the best way to take this road, and this choice will affect the live of a lot of developers.
You are lossing all the linux and mac object pascal experienced developres, help to take the rigth way.

Why dont do to it a little more focus in the community, after all we are the customers, and we will not buy your product if the solution is sub qualified. 
We already have FPC and Lazarus, doing many things better than delphi today. Will not bea smart step from embarcadero publish some blue print of the ideas behind the projext cross x, to get some feedback?
 
What are the fears? Criticisms? Be copied for some another company? Forget it, nobody have the strength to put money in pascal this days, and start from zero. You and we are alone here, just let's talk. ;)

Best regards.
0
german
2/19/2010 5:38:25 PM
Brad White wrote:

> 
> I'm open to being persuaded, but the only example
> I've seen was Allen's.  While he did fine job demonstrating
> some very cool things that you could do with generics
> and an anonymous procedure, it made the code much
> less readable, IMHO.
> 

+1. Entirely.

> Do you have an example where it would increase redability
> or quality?
> 
> Thanks,
> Brad.

In a perfect world it would be something like:

function GetUserName: string;
begin
	Result:='';

	using temp:=TStringList.Create do
	begin
		temp.Add('Please be so kind');
		temp.Add('in order to enter');
		temp.Add('your beloved name');
		Result:=InputBox(temp.Text, '');
	end;

	if Result='' then //some bogus processing
	begin
		ShowMessage('You did not enter a name');
		Result:='guest'; //whatever
	end;
end;

There are some very interesting things to note however:

1. The above construction resembles (from *user* POV) to 'with' aliasing 
which is (AFAIS from QC and from here) the community's preferred 
solution for the 'Infamous "with" resolution'. IOW something like:

//for ex. some very big name here
with tbl:=MainCustomerDataModule.ProblematicOrderDataSource.Dataset do
begin
	tbl.SQL:='SELECT * FROM ORDERS WHERE STATUS=8'; //whatever
	tbl.Open;
end;

- or -

with temp:=TStringList.Create do
begin
	temp.Add('blah!'); //do something
	ShowMessage(temp.text);
	temp.Free;	//<---!
end;

As you see the main difference between 'with' aliasing and 'using' is 
that 'with' doesn't manage the lifetime of the aliased object.

In the 'using' case this gives the (at least theoretical) the 
possibility for some checks for the compiler such as:

var
	nastyRef: TStringList; //global

procedure Foo;
begin
   using temp:=TStringList.Create do
   begin
	temp.Add('blah!'); //do something
	nastyRef:=temp; //Compiler warning like: 'nastyRef is outside'
	ShowMessage(temp.text);	
   end;
   //temp destroyed here. So nastyRef is dangling.
end;

And this cannot be checked at the compile time neither in the case of 
'with' aliasing neither in the classical case of today which is 
try...finally block.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

2. Another thing which perhaps you (as experienced Delphi developer) 
cannot see at the first glance is that

   using temp:=TStringList.Create do
   begin
	temp.Add('blah!'); //do something
//snip

gives a clear indication that the compiler will take care of the 
lifetime of temp and you should only concentrate on your coding (human) 
problem to solve.

Ok, perhaps if you'll see the code...

   temp:=TStringList.Create;
   try
     ...
//snip

....you will automatically search for a temp.Free (or similar) in a 
'finally' block. But this can be *your* habit and also can be a little 
bit tedious if the finally block is outside of screen. And also, the 
temp.free in the 'finally' block, being more manual is prone to error 
(you have to accomplish more steps to build a try/finally block). Using 
'using' is much safer.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

3. Also, a nested try/finally is (imho) much more less readable. Compare 
the following equivalent snippets:

MyComp := TComponent.Create(Self);
try
   MyComp.Name:='FooComponent';
   MyComp.Tag:=1; //and many other things...
   myLabel := TLabel.Create(Self);
   try
     myLabel.Parent:=Self;
     myLabel.Caption:=MyComp.Name;
     myLabel.Color:=clMagenta;
     //etc. etc.
     ShowModal;
   finally
     myLabel.Free;
   end;
finally
   MyComp.Free;
end;

---8<------8<------8<--- vs ---8<------8<------8<---


using MyComp := TComponent.Create(Self) do
begin
   MyComp.Name:='FooComponent';
   MyComp.Tag:=1; //and many other things...
   using myLabel := TLabel.Create(Self) do
   begin
     myLabel.Parent:=Self;
     myLabel.Caption:=MyComp.Name;
     myLabel.Color:=clMagenta;
     //etc. etc.
     ShowModal;
   end;
end;

....and I didn't put a 3rd level of nesting, neither a try..exception 
block there... :-)

Did I convinced you? :-)

-- 

m. Th.

On the Wings of the Wind...
http://wings-of-wind.com/
0
m
2/19/2010 5:59:13 PM
+ 1 for vgscene + dxscene
0
Utf
2/26/2010 9:12:13 AM
Reply:

Similar Artilces:

Delphi Prism for cross-platform projects: Started a project
As I suspected Delphi Prism is ideal for my purposes. Since I am a hobby linguist, my program is a Hebrew verb conjugation application. I am trying to formulate all necessary rules including all exceptions in Pascal. Last year I implemented a working prototype in Objective-C. http://web.mac.com/ajbrehm/Home/Software.html It worked, but wasn't portable; and Cocoa is a bit of a hassle when it comes to string manipulation since it offers no native support for unicode regular expressions. I can re-use the GUI. This is how I am planning to proceed, slowly, of course, since I am lazy an...

delphi.Net Delphi 2005 Project Upgrades?
Our company aquired the software property from another last year. Most of the projects were written in Delphi 2007. We purchased Delphi XE which gave us access to previous versions, including D 2007... all is well. However, 3 projects were written Delphi 2005 for .Net. The VM we received from this company included D2005 but it was licensed from the previous developer. I've contacted Embarcadero about obtaining a copy and or a license+registration for Delphi 2005 and was told this product is no longer available. I'm under the impression Delphi for .Net was abandoned. My qu...

Project Manager Delphi 2007 vs Delphi 5
I am in the midst of moving from Delphi 5 to Delphi 2007. I have a .BAT file that I use to do some post processing on the executable after it is built. In Delphi 5, I just added the .BAT file to the project manager. Then when I wanted to execute the .BAT file I just right clicked its entry in the project manager and selected Execute. There doesn't seem to be anyway to add the .BAT file to the project manager in Delphi 2007. How can I set up something similar to what I had in Delphi 5? I thought about using a Post Build event but I don't necessarily want to execute the .BAT fi...

delphi 2010 memory not released when closing delphi project
each time im runing delphi 2010 the memory that was used was not release after closing a project and the memory don't stop to grow and the browsing for file becoming slow any idea ? Thanks Pierre Auger wrote: > each time im runing delphi 2010 the memory that was used was not > release after closing a project and the memory don't stop to grow and > the browsing for file becoming slow > > any idea ? You are using some 3rd-party components that do not properly release memory in their design-time packages would be my guess. A design-time package stays l...

Convert a Delphi 2006 WinForms project to Delphi Prism
How can I go about doing this short of recreating the project and transfering code? Just wondering what to expect if we go to Prism. Thanks. -- Don Gollahon Don Gollahon wrote: > How can I go about doing this short of recreating the project and > transfering code? > > Just wondering what to expect if we go to Prism. > > Thanks. Hi Don, Have you checked out the migration tool Oxidizer ? http://prismwiki.codegear.com/en/Oxidizer Cheers, John -- John Moshakis wrote: >Don Gollahon wrote: > >> How can I go about doing th...

Delphi and Delphi for .Net
It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. I would like to know is it true all .Net application is slower than Win32 native applicaiton or it is Delphi for .Net only. Your information is great appreciated, Inung On 2011-06-21 18:20:17 +0100, Inung Huang said: > It seems that Delphi for .Net is slower than Delphi Win32 native applicaiton. > I would like to know is it true all .Net application is slower than > Win32 native applicaiton or it is Delphi for .Net only. If you are only running the code in the application once then, yes, yo...

Delphi 2010 and Delphi XE5 shuts down when opening projects
Over the last week I have found it increasingly difficult to open projects. Even really simple projects, some more complex. For example if start Delphi 2010 Enterprise Edition. I see the list of recently opened projects. I then click on a simple existing project, I get a hour glass for about a second and then Delphi IDE has gone. In the windows task manager, there are now no applications running. I have not changed the installation, being using Delphi 2010 enterprise on the same computer for a few years. I'm not a full time developer, but do internal development of our compa...

Delphi 2010 and Delphi XE5 shuts down when opening projects
Over the last week I have found it increasingly difficult to open projects. Even really simple projects, some more complex. For example if start Delphi 2010 Enterprise Edition. I see the list of recently opened projects. I then click on a simple existing project, I get a hour glass for about a second and then Delphi IDE has gone. In the windows task manager, there are now no applications running. I have not changed the installation, being using Delphi 2010 enterprise on the same computer for a few years. I'm not a full time developer, but do internal development of our compa...

Importing Delphi 2009 project in Delphi 2006
I've been using Delphi 2006 for a while and have never really felt the need to upgrade to a newer release given the expense. I'm looking at taking over on a project from someone else who developed it in Delphi 2009. The only code incompatibilities he can think of is some of the Unicode changes that were introduced after D2006 but that should be fairly easy to fix. My main concern is whether or not a project that was created in Delphi 2009 can even be *opened* in Delphi 2006. I don't know how file exte nsions or formats have changed between the two versions. Can anyone give me...

Delphi 2010 can't upgrade Delphi 2007 projects
If I open any of my Delphi 2007 projects in Delphi 2010 it prompts me that it will upgrade it. Unfortunately, that leaves Delphi 2010 to give errors about not knowing where to find system and other core units. On the other hand, if I delete all the BDS project files and only leave the .dpr, Delphi 2010 can successfully open and compile my project. However, besides that quirk, I have another problem. I need to have both a working Delphi 2007 project and Delphi 2010, so I can compile using both without being prompted each and every time about upgrading project :) So... Any ideas to what m...

Need help to allow a working Delphi 3 project to build on Delphi XE
How do I adjust this working Delphi 3 program that uses OLEAUTO and OLE2 to work on the newer Delphi XE, Program code is below this, errors are here : Checking project dependencies... Compiling admn_api.dproj (Debug, Win32) dcc command line for "admn_api.dpr" c:\program files (x86)\embarcadero\rad studio\8.0\bin\dcc32.exe -$O- -$W+ --no-config -M -Q -AWinTypes=Windows;WinProcs=Windows;DbiTypes=BDE; DbiProcs=BDE;DbiErrs=BDE -DDEBUG -I"c:\program files (x86)\embarcadero\rad studio\8.0\lib\Win32\release";"C:\Users\Administrator\Documents\RAD Studio...

Project X is a Delphi for Mac
Hi i have read any info about Next Delphi for MAC and Linux ( *Project X* ) how work ? * IDE is Delphi under windows or native Mac IDE / Linux ? * Can i porting Delphi2009-VCL application under MAC / Linux ( without modify.. ) ? Mauro Botta a écrit : > i have read any info about Next Delphi for MAC and Linux ( *Project X* ) > > how work ? Nobody knows. We can only guess, but it wil not be the "next" Delphi. It is an R&D project as far as we can tell. > * IDE is Delphi under windows or native Mac IDE / Linux ? We ...

Delphi 2009 OpenFileLink with red X: Projects cannot be loaded. Why?
Hello, Since today in my delphi2009 I cannot load my projects anymore. There is this Note (in German IDE: Hinweise) "OpenFileLink" with red X. If I click the red X the Note is closed. But all my Delphi2009 projects cannot be loaded. If I delete the dproj file, then the dpr file will be loaded, but I am losing all my project options. What can be the reason for that nuisance? Sincerely Peter Hello, I have forgotten to mention, if I close a project and want to reopen it later, it will not be opened and I have to delete3 the dprog again.... This is very annoying. ...

An OS X GUI Delphi app without FireMonkey
Yes, I did it! I already thought it should be possible, but expected I'd have to do a lot of translating of headers, etc. Not so. The Macapi.* units for OS X provided almost everything that was needed to write an AppKit (Open Source equivalent of Cocoa) app, using "native" components. This is a naked (console!) app without a .nib or .xib file. It creates a window with a few OS-X-native buttons, labels, edit boxes and combo boxes on it, and reacts to certain events, like a button click, a combobox selecton change, a timer firing, etc. No FireMonkey required. It is ...

SEPA components for Delphi with Source Code (Delphi 5
Hi all, in the european union change next year the Bankingformat to the SEPA Format. All peoples and companies must change the bankingssoftware and the costumer data form acountnummers in the new IBAN and BIC numbers. See: http://www.arma-it.de/shop/artikelueber.php?wgruppeid=211&wgruppe_offen=211 Functions: - generate SEPA XML'S - Calc IBAN - BIC Database (DE,AT and CH) Questions: vertrieb@arma-it.de PS: Bankinssoftware for Develpoers (Germany only) http://www.arma-it.de/shop/artikelueber.php?wgruppeid=212&wgruppe_offen=212 El 26/10/13 21:38, A...

Delphi and virus, or virus and Delphi.
Hi all. There is some discussion about a 'new' virus, that targets Delphi (and developers). The article is in danish: <http://www.version2.dk/artikel/11833-delphi-udviklere-jages-af-ny-type-malware> but refers to this article: <http://news.cnet.com/8301-27080_3-10312628-245.html> From the Danish article POV, it seems like Delphi itself is vunerable, which is not true. As far as i can see, is the attack vector, injection of (source) code in the 'Sysconst' unit. What's going on? -- Best regards Stig Johansen Perhaps checking other thre...

Delphi XE / Delphi 2010
Hello! I noticed that Embarcadero® Delphi® 2010 Version is not on the list of products on Embarcadero page. Or is it still possible to buy it? Will RAD Studio XE compile programs written in Delphi 2010 without problems.? Thanks. Am 13.09.2010 09:04, schrieb Petra Nemec: > Will RAD Studio XE compile programs written in Delphi 2010 without problems.? As always you will probably have to recreate the projects as the import is still a bit -- special. Christian Hello! Does anybody know if it is still possible to get a Delphi2010 trial version (if yes where)? ...

from delphi 6 to delphi 2010
Hi. It is possible, with component RX, dxforumlibrary, InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. Thank by comments. excequiel arostica wrote: >Hi. > It is possible, with component RX, dxforumlibrary, >InfoPower3000Pro, StringAlignGrid. Accepts communication BDE. > >Thank by comments. Rx is dead and sources are taken over by jcl/jvcl. I dont know about the rest of the components and i have no experiences with bde over the last 9 years. excequiel arostica wrote: > Hi. > It is possible, with component RX, dxforumlibrary,...

Delphi 7 to Delphi XE2
Hi, Still using that old workhorse, Delphi7, but am going to the conference in London hosted by Embarcadero on Delphi XE2. Although I would like to "move with the times" and am keen to get the UNICODE and 64-bit support offered by the latest IDEs, I confess to being more than a little scared about all the UNICODE/String/AnsiString and 32/64 bit issues I'm probably going to fall over. Anyone recently upgraded from Delphi7 to one of the latest Delphi IDEs? Thanks, Alain On 03/02/2012 08:55, Alain Dekker wrote: > Still using that old workhorse, Delphi7, but am going to the conference in > London hosted by Embarcadero on Delphi XE2. > > Although I would like to "move with the times" and am keen to get the > UNICODE and 64-bit support offered by the latest IDEs, I confess to being > more than a little scared about all the UNICODE/String/AnsiString and 32/64 > bit issues I'm probably going to fall over. Anyone recently upgraded from > Delphi7 to one of the latest Delphi IDEs? I recently upgraded a sizeable (Paradox) app from D3 to XE2 and was pleasantly surprised. About 20-30 hours once I understood how XE2 works. Andrew -- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021 ----- Recently moved a lexicographic application from D2007 to XE2 with little pain. As you would imagine, it is heavily string-based, with much use of TStringLists, cuttin...

Delphi for PHP or Delphi PRISM
Hi, I have the opportunity to develop a web-based library management system. Nothing fancy, just being able to do the usual CRUD stuff for books and provide a search facility. Borrowing is to be done via an email request to the library admin who then sends out the book(s). Since both Delphi for PHP and Delphi PRISM will enable me to develop the app, which one will allow me to deliver it in less time and also increase (even how small) my marketability as a web developer? Thanks. Phillip Flores Phillip Flores wrote: > Hi, > > I have the opportunity to develop a...

Delphi 7 to Delphi XE
Have been using Delphi 7 for many moons ( have got later versions but never upgraded to ) My first problem is: Component Palette. in XE it is a small toolbar docked in top right in Delphi 7 it gives a large view of all the components. I am struggling to be able to cope/access my components.in Delphi XE. Can I make the component pallette tool bar the same size as Delphi 7, or is there a fast way to view/choose all available components in XE, that I have not spotted yet? Kind Regards, Robert. Hi, What I know is that in Delphi 2010 and XE you can choose between t...

Delphi 5 To Delphi 2009
I upgraded to Delphi 2009 from D5. The install says I can install Delphi and/or C++. Delphi installed OK but I see nothing of C++. What am I missing or does my upgrade not include C++? Thanks It depends on what you bought. If you bought Delphi 2009 only, that's what you get. If you bought Delphi 2009 and C++ Builder 2009 you get both. My guess is you got Delphi 2009 only. The simplest way to verify is look your invoice - it should say I would think. You could also go to members.embarcadero.com, login, then click on my registered products. There will be a textual description of...

Delphi 2007 to Delphi 7
I've written a class in Delphi 2007 that is not supported in Delphi 7. What would be the best way to achive what I've done in Delphi 2007 in Delphi 7? Thanks, Tom type BondConstants = class { Bond Types } type BondType = record const TREASURY = 3; AGENCY = 0; CORP = 1; MUNI = 2; SBA = 5; MBS = 4; CMO = 6; end; { Day Count Methods } type DayCount = record const ACTUAL_360 = 2; ACTUAL_365 = 1; ACTUAL_ACTUAL = 1; d30_360 = 0; ...

Delphi 5 to Delphi 6 and up
Dear List, Trying to add 7Zip compression support to my delphi application. I am using the ported 7Zip sdk (see their website, they have a link). I am stumped on how to rewrite a single function: function ReverseDecode(var Models: array of SmallInt; ....): ..... where the input is mostly a fixed size array of SmallInt. This code perfectly compiles and functions in Delphi 6 and up, but in Delphi 5 I get the error: There is no overloaded version of 'ReverseDecode' that can be called with these arguments And obviously, the input (fixed) isn't the same as the param definition (dynamic sized). However, my question is just as obvious: How do I rewrite this function so it will behave correctly in Delphi 5? (If this is even possible) I hope I don't have to overload it to something like: function ReverseDecode(var Models: array[0..xxx] of SmallInt....... Thanks in advance for any assistance, Rory Rory Slegtenhorst wrote: > Dear List, > > Trying to add 7Zip compression support to my delphi application. > I am using the ported 7Zip sdk (see their website, they have a link). > > I am stumped on how to rewrite a single function: > > function ReverseDecode(var Models: array of SmallInt; ....): ..... > > where the input is mostly a fixed size array of SmallInt. > This code perfectly compiles and functions in Delphi 6 and up, but in > Delphi 5 I get the error: There is no overloaded version...

Web resources about - Delphi Project X Cross GUI - embarcadero.delphi.non-tech

Project - Wikipedia, the free encyclopedia
For the urban low-income housing buildings called projects, see public housing . For other uses, see Project (disambiguation) . The word project ...

The Project Shrink - Welcome To Shrinkonia.
... about the importance of the environment we work in and the stories we tell, we should have a Set Designer and a Storyteller on our projects. ...

Better Projects
I think this book by Tobias is beautifully written. There is real craftmanship in the prose here. The book is made up of independent self contained ...

NBN: Government urged to embrace fibre to home, Ziggy Switkowski denies project behind schedule
... Government is urged to consider an about-face and embrace fibre to the home for the NBN. Politicians continue to use the nation-building project ...

Adobe releases first Experience Design preview for Mac, its ‘Project Comet’ UX design tool
... design prototypes. The latest Creative Cloud tool was first announced last October at Adobe’s Max Creative Conference under the name Project ...

Smartsheet delivers greater visibility into collaborative projects
Enabling efficient collaboration on projects is key to success in business and there are many platforms to enable it. But it can sometimes be ...

Google's latest plan for Charleston East office project in Mountain View (slideshow) - Silicon Valley ...
Google is retaining the general idea of its original plan: A "canopy" draping a flexible workplace with lots of green space threading through ...

Wounded Warrior Project chair on recovery from spending scandal
Charity fired two top executives following a CBS News investigation that exposed only 60 percent of donations were spent directly on vets

Cyber soul project promises immortality – but what should Christians think?
The idea that someone's mind can live independently of their body, uploaded into another human being or into some form of software, has been ...

Renault To Supply 150 Of Its ZOE EVs To Utrecht For Solar Smart-Charging Project
... a test fleet of 150 Renault ZOE electric cars to the city of Utrecht (through the year 2017) as part of a new solar smart-charging project, ...

Resources last updated: 3/17/2016 4:43:11 AM