Re-Write
Rita
but Borland got certain parts wrong, what parts would u put
up as their mistakes ?
Has anyone here ever written a pascal compiler that could
be close to that of Borlands ?
How much would it cost to develop a pascal compiler from
the ground up ?
Rita
theo
> Has anyone here ever written a pascal compiler that could
> be close to that of Borlands ?
> How much would it cost to develop a pascal compiler from
> the ground up ?
>
http://www.freepascal.org/
http://www.lazarus.freepascal.org/
none
> Suppose someone sat down and said Kylix was a good thing
> but Borland got certain parts wrong, what parts would u put
> up as their mistakes ?
1. Forget about Pascal. Target only C and C++
2. Use GTK+ instead of CLX or VCL
3. Avoid all pascalisms.
> Has anyone here ever written a pascal compiler that could
> be close to that of Borlands ?
> How much would it cost to develop a pascal compiler from
> the ground up ?
Freepascal and lazarus appear to be outdoing Borland on a budget of $0.
http://www.lazarus.freepascal.org/modules.php?op=modload&name=StaticPage&file=index&sURL=about
Michael Schnell
for Windows (PC), WinCE (ARM PDAs) and Linux (PC, Mac, Amiga, ARM PDAs
and some more).
2) Chrome (running on Visual Studio) (commercial product by RemObject):
Creates .NET assemblies running (supported by the supplier) on .NET (On
Windows PCs) Microsoft compact Framework (ARM PDAs), Mono (On Windows
PCs, Linux PCs and lots of different platforms <see www.mono.org>) and I
suppose there is a compact Mono version, too. I suppose it can do
DotGNU, as well.
-Michael
Mike Gallets
Running the Kylix development environment
is more tricky than running a compiled
application. I can still run apps made
with Kylix on SUSE 10. My vote (for
now) is to wait for a clearer path because
changing development tools is hard.
If your target is Microsoft/Net then take
a look at C# (Not C or C++). This is the
best connect for .NET and the language
was designed by the same guy that made
Turbo Pascal and Delphi - Anders Hejlsberg.
-- Mike Gallets, Giant Systems
theo
>
> Running the Kylix development environment
> is more tricky than running a compiled
> application. I can still run apps made
> with Kylix on SUSE 10.
I can still run the IDE on SuSE 10.
> My vote (for
> now) is to wait for a clearer path because
> changing development tools is hard.
Happy waiting!
> If your target is Microsoft/Net then take
> a look at C# (Not C or C++).
The thread is about Kylix/Linux.
Michael Schnell
> a look at C# (Not C or C++).
IMHO this recommendation holds for Linux, too, _if_ you want to go the
way of a .NET framework. There are several ways to create C# programs
(under Windows and Linux) and deploy them for Mono so that the binaries
will run in Windows and in Linux.
-Michael
Victor Helsing
10.1) with considerable success. I do have a few font related issues, and
it took some effort to convert my large program from VCL to CLX, but overall
have been very pleased with how well Kylix seems to be working so far.
Unfortunately, the number of good third party components for Kylix is rather
limited, so if you want to do sophisticated things with Linux may end up
writing the code yourself (and quite possibly bumping up against the
limitations of the QT architecture).
By the way, I used theo's patch for Kylix (search on google: Kylix Suse 10
theo).
Good luck.
"Rita" <sp...@nospam.com> wrote in message
news:45b42e49$1...@newsgroups.borland.com...
Martin Schreiber
MSEide+MSEgui, just released version 1.0:
http://mypage.bluewin.ch/msegui/
Screenshots:
http://sourceforge.net/project/screenshots.php?group_id=165409
Martin
Michael Schnell
That did seem interesting but no activity since 2005. No traffic in the
newsgroups either.
-Michael
Michael Schnell
I just installed the latest version of Lazarus (on Windows to start
with) and was amazed to find that it now really works like expected.
-Michael
Michael Schnell
There are a lot of very active newsgroups and mailing lists in English
and German.
-Michael
Vincent Snijders
My impression is otherwise.
220 svn commits in the last 60 days:
http://sourceforge.net/project/stats/detail.php?group_id=165409&ugn=mseide-msegui&type=svn&mode=60day
I don't have the count here, but at least that many messages in the newsgroup at
news://news.dxmachine.com/public.mseide-msegui.talk
Vincent
Michael Schnell
> I don't have the count here, but at least that many messages in the
> newsgroup at news://news.dxmachine.com/public.mseide-msegui.talk
Thanks for the hint! I once attached to several msegui newsgroup that
had been announced at that time and after some initial traffic there
were no more messages since. I'll try the group you suggest right now.
-Michael
Marco van de Voort
> Suppose someone sat down and said Kylix was a good thing
> but Borland got certain parts wrong, what parts would u put
> up as their mistakes ?
I'd say
- too much geared towards recompiling Delphi apps.
- too much focus on GUI. (maybe a crosscompile/remote debug solution
for server Linux apps would have been more succesful, that's
where the money was)
Also I think Linux simply has a tradition of not paying for software.
> Has anyone here ever written a pascal compiler that could be close to that
> of Borlands ? How much would it cost to develop a pascal compiler from the
> ground up ?
A pascal compiler, a simple graduate project.
Something that can replace Kylix/Delphi (compiler only) at least 100k, more
likely several times that. More for the rest.
James K Smith
> - too much focus on GUI. (maybe a crosscompile/remote debug solution
> for server Linux apps would have been more succesful, that's
> where the money was)
Right on! Thanks to Martin's work (MSE-IDE) with dedicated user suggestions
(like those from Ivanko), and Lazarus work, cross-gui has made huge leaps,
but IMO, potential users just stop at this hurdle if they can't replicate
gui capability from Delphi. We have to get past that, because thin clients
will take larger and larger bites out of desktop dev in the future.
For the future, attention has to be focused on centralized and mobilized
computing, and not computing spread evenly across every desktop. FPC could
shine in this area. BTW, I host the news.dxmachine.com groups as a volunteer
service. Anybody who has a cross-platform FPC project feel free to get in
touch with me for newsgroup space.
James
Marco van de Voort
>> - too much geared towards recompiling Delphi apps.
>> - too much focus on GUI. (maybe a crosscompile/remote debug solution
>> for server Linux apps would have been more succesful, that's
>> where the money was)
>
> Right on! Thanks to Martin's work (MSE-IDE) with dedicated user suggestions
> (like those from Ivanko), and Lazarus work, cross-gui has made huge leaps,
> but IMO, potential users just stop at this hurdle if they can't replicate
> gui capability from Delphi.
Depends on what you mean by "replicate". The simple truth is that if you go
crossplatform, you will have to pay attention to that what functionality
(components, calls) you use is platform-independant, and will have to take
certain limitations for granted. Kylix didn't encourage making this
realisation and, probably for marketing reasons, emphasized "simply recompile"
too much.
This increased the required functionality of the OS too much, which
(potentially) is the root of the libc problems. Even if you don't even use
the GUI. IOW, there should have been at least a barebones application model,
that was as portable as possible.
Another Kylix ugliness was the libc unit, which unnecessarily exposed (and
thus encouraged useof ) internals that are/were not long term portable.
Often not even to Linux installations on other architectures from the same
time. Probably this was a result of an effort to create a "windows" unit
equivalent, but the situation on Linux was simply different.
Also since part of the problem was the emerging of Kylix in a time of
Linux/libc API instability (e.g. threading wise). Which is of course not
CG's fault.
> We have to get past that, because thin clients will take larger and larger
> bites out of desktop dev in the future.
What can become browser based, will become browser based. There is no
stopping that. Specially since now ASP.NET and Ajax will make webdevelopment
a bit more productive and the product a bit more friendly.
Of course this will make fat clients more "high-end", since webapps will be
the commodity. So consider the low hanging fruit lost to webapps, and focus
on places where fat clients shine (complex UIs), the server end of things,
conversions/adaptations/migrations etc.
> For the future, attention has to be focused on centralized and mobilized
> computing, and not computing spread evenly across every desktop.
I subscribe to the principle that FPC should basically take Delphi code to
where Delphi can't go (or can only limp, e.g. Mono). Putting too much effort
into replicating Delphi into the most minime details and perfecting its
userfriendliness is IMHO not done, since that takes ages, and the result can
readily be bought from Borland^H^H^H^HCodegear already.
> FPC could shine in this area. BTW, I host the news.dxmachine.com groups as
> a volunteer service. Anybody who has a cross-platform FPC project feel
> free to get in touch with me for newsgroup space.
I use the FPC/Lazarus own channels as much as possible to avoid
fragmentation. I hope to get an Indy10 httpclient working on wince this
weekend (I've seen reports that it works, but want to have final
verification)
Currently, I think FPC (and Delphi oriented Open Source too) need
good examples more than yet another forum/website etc.
James Smith
> stopping that. Specially since now ASP.NET and Ajax will make
> webdevelopment
> a bit more productive and the product a bit more friendly.
>
> Of course this will make fat clients more "high-end", since webapps will
> be
> the commodity. So consider the low hanging fruit lost to webapps, and
> focus
> on places where fat clients shine (complex UIs), the server end of things,
> conversions/adaptations/migrations etc.
If the low hanging fruit is lost to webapps, then ultimately fat clients
will be the exception to complete the rule that webapps make the most
business sense. Ultimately, there will only be a tiny number of identifiable
gui tasks that can't be delivered via web browser presentation. The most
important fat client of the future should be the browser itself.
I certainly understand the usefulness of an app framework, but the
impression I get from many Delphi developers is that other platforms are not
worthwhile simply because it's too difficult to create the same fat client
on them as one can in windows. Thanks to the work already done to support
FPC based gui development, and because clients are getting thinner anyway,
this barrier to entry is quickly fading away.
> I subscribe to the principle that FPC should basically take Delphi code to
> where Delphi can't go (or can only limp, e.g. Mono). Putting too much
> effort
> into replicating Delphi into the most minime details and perfecting its
> userfriendliness is IMHO not done, since that takes ages, and the result
> can
> readily be bought from Borland^H^H^H^HCodegear already.
That's great, but what I'm referring to is how FPC can contribute to how
computing in general is changing. The days of evenly distributed computing
power are slowly coming to an end, and because a single unit of computing
power will always cost something, I think natively compiled servers have a
major role to play. So FPC can potentially provide a fairly distinct
business opportunity because of its platform-agnostic bent.
> I use the FPC/Lazarus own channels as much as possible to avoid
> fragmentation. I hope to get an Indy10 httpclient working on wince this
> weekend (I've seen reports that it works, but want to have final
> verification)
Excellent. But get a good Indy 10 server running, and let the browser do the
client work!
>
> Currently, I think FPC (and Delphi oriented Open Source too) need
> good examples more than yet another forum/website etc.
Sure, and if the FPC/Lazarus channels will volunteer newsgroups space for
specific projects, that's especially good. But more info is still better
than less, so that's why I'm volunteering newsgroup space.
James
Ed
> Suppose someone sat down and said Kylix was a good thing
> but Borland got certain parts wrong, what parts would u put
> up as their mistakes ?
For one thing, I would've preferred them not gear it for
any specific distro, but list the typical libraries required
to use it. Stating Kylix requires (so-and-so) distro decreases
the usage scope. However, stating that Kylix requires these
libraries (and list them out) would be more distro-neutral.
You'd then just grab the libraries and boom, you're running.
Also having Kylix being fixated on one particular library
version (i.e. MySQL for Kylix 1 and 2, IIRC) would limit
its flexibility. Say, if the server's MySQL was upgraded to
3.0.55 (for example), and Kylix is still stuck in the 3.0.24
version libraries (again, an example), possible vulnerabilities
would exist, no?
Anyway, while I haven't given up on Kylix, I'm still hoping,
I haven't really done much. It would be great if there
was a Kylix 4.
Ed