Board index » kylix » Re: Borland Classic Products

Re: Borland Classic Products


2005-09-06 09:19:34 AM
kylix1
Jeff Overcash (TeamB) wrote:
Quote


Not being able to put any faith in roadmaps and deliverables.
You mean like Borland and dbExpress.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 
 

Re:Re: Borland Classic Products

Thomas Miller wrote:
Quote
>- after a few commits the compilation by Delphi was already broken
>

AND???
Well, nobody fixed it but the sources were filled with ifdefs.
 

Re:Re: Borland Classic Products

On 2005-09-06, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
I don't think the LCL should be poluted with what I want to do.

People suggest to me to help with the LCL instead of pursuing
this project.

I still have to live in the Delphi world while Lazarus either
ganes more ground on Delphi's VCL or the UOPL project starts
getting some steam. Either way it isn't reasonable for
thousands of programmers to drop what they are doing in
Delphi and immediately move to Lazarus. They will have to
do it gradually and that is one major reason for having
the UOPL.
Simply improving the VCL compat of the LCL means they actually
move less, since they can keep on using VCL on Windows.
However it will be interesting to see what you guys come up with. Where
can development versions (however incomplete just to get an idea of the
architecture) be obtained ?
 

{smallsort}

Re:Re: Borland Classic Products

Marco van de Voort wrote:
Quote
On 2005-09-06, Thomas Miller < XXXX@XXXXX.COM >wrote:

>I don't think the LCL should be poluted with what I want to do.
>
>People suggest to me to help with the LCL instead of pursuing
>this project.
>
>I still have to live in the Delphi world while Lazarus either
>ganes more ground on Delphi's VCL or the UOPL project starts
>getting some steam. Either way it isn't reasonable for
>thousands of programmers to drop what they are doing in
>Delphi and immediately move to Lazarus. They will have to
>do it gradually and that is one major reason for having
>the UOPL.


Simply improving the VCL compat of the LCL means they actually
move less, since they can keep on using VCL on Windows.

However it will be interesting to see what you guys come up with. Where
can development versions (however incomplete just to get an idea of the
architecture) be obtained ?

This is where the project has stalled. I did major amounts of research
and now we need someone that understands the base objects to jump in
and tell the 5 or 6 of us that are interested in doing this on what
needs to be done. I am mainly a DB guy. First step is to try and
make sure we do this as a UNICODE system. I don't know the ins and
outs of this, but ready to learn if we can find someone to take the
lead.
My hope is to break up the project into categories, assign a lead
for that category and then let that person put a team together.
I have already assigned myself as the DB group leader. I already
have people on my team ready to go. I don't want to do anything
until the base objects get started and I might have two or three
people to help with that project, but they also feel uncomfortable
being the lead because of the lack of UNICODE experience.
I need someone to take the base object category so we can get
moving on coding. Any takers here?
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Borland Classic Products

Thomas Miller wrote:
Quote
Marco van de Voort wrote:

>On 2005-09-06, Thomas Miller < XXXX@XXXXX.COM >wrote:
>
>>I don't think the LCL should be poluted with what I want to do.
>>
>>People suggest to me to help with the LCL instead of pursuing
>>this project.
>>
>>I still have to live in the Delphi world while Lazarus either
>>ganes more ground on Delphi's VCL or the UOPL project starts
>>getting some steam. Either way it isn't reasonable for
>>thousands of programmers to drop what they are doing in
>>Delphi and immediately move to Lazarus. They will have to
>>do it gradually and that is one major reason for having
>>the UOPL.
>
>
>
>Simply improving the VCL compat of the LCL means they actually
>move less, since they can keep on using VCL on Windows.
>
>However it will be interesting to see what you guys come up with. Where
>can development versions (however incomplete just to get an idea of
>the architecture) be obtained ?
>

This is where the project has stalled. I did major amounts of research
and now we need someone that understands the base objects to jump in
and tell the 5 or 6 of us that are interested in doing this on what
needs to be done. I am mainly a DB guy. First step is to try and
make sure we do this as a UNICODE system. I don't know the ins and
outs of this, but ready to learn if we can find someone to take the
lead.

My hope is to break up the project into categories, assign a lead
for that category and then let that person put a team together.
I have already assigned myself as the DB group leader. I already
have people on my team ready to go. I don't want to do anything
until the base objects get started and I might have two or three
people to help with that project, but they also feel uncomfortable
being the lead because of the lack of UNICODE experience.

I need someone to take the base object category so we can get
moving on coding. Any takers here?

That's not how OSS works, recommended reading
www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
:)
 

Re:Re: Borland Classic Products

I read the intro and will finish it later when I have time. I still
need someone to help us with UNICODE. The small band of developers
all agree with me it would be a waste not to put it in at the lowest
levels, but none of us have ever used it. So we have no practical
experience. We also would like, but not necessary, to have someone
with GTK2 experience so we don't do something stupid up front and
have to spend months undoing an innocent, yet stupid, mistake.
Florian Klaempfl wrote:
Quote
That's not how OSS works, recommended reading
www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
:)
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Borland Classic Products

Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
I read the intro and will finish it later when I have time. I still
need someone to help us with UNICODE. The small band of developers
all agree with me it would be a waste not to put it in at the lowest
levels, but none of us have ever used it. So we have no practical
experience.
Exactly what sort of help do you need regarding Unicode?
Kind regards,
Jan Goyvaerts
--
The world's most powerful grep tool just got better.
www.powergrep.com/
 

Re:Re: Borland Classic Products

Us Americans don't really use UNICODE yet. ASCII is about it. We
want to do UNICODE right and start from the ground up. The idea is
to take the code from FPC and UNICODE it. We also have permission
from TNT to {*word*16}ize it. I need someone to take over the core.
Things like sysutil, windows, classes, and things like that. I even
will find you help from our users group. I just need someone that
feels very comfortable in the UNICODE world and with the CORE modules
of Delphi to take the lead. Like I have said in other posts, my area
will be DB.
Jan Goyvaerts wrote:
Quote
Thomas Miller < XXXX@XXXXX.COM >wrote:


>I read the intro and will finish it later when I have time. I still
>need someone to help us with UNICODE. The small band of developers
>all agree with me it would be a waste not to put it in at the lowest
>levels, but none of us have ever used it. So we have no practical
>experience.


Exactly what sort of help do you need regarding Unicode?

Kind regards,
Jan Goyvaerts

--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Borland Classic Products

Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
The idea is to take the code from FPC and UNICODE it.
If I understand you correctly, you want to convert existing code written for
AnsiStrings to use WideStrings?
There's basically 3 steps:
1. Replace "string" and "AnsiString" with WideString,
and "char" and AnsiChar with WideChar.
2. Remove all code that deals with DBCS
(i.e. checking the FarEast flag, LeadBytes, ByteType(), etc.)
3. Fix all code that expects a character to equal one byte.
Generally, using WideStrings is easier than using AnsiStrings, since you
don't have the DBCS mess to deal with for Far East languages.
The only time Unicode gets hairy, at least in Delphi, is when you want to
deal with Unicode code points higher than 0xFFFF. In a Delphi WideString,
these take up two positions in the string. However, unlike DBCS, there's a
unique range of characters for the first character in the pair, and a unique
range for the second character. So parsing WideStrings is relatively easy,
and you really only need to take this into account when you want to
calculate the number of graphemes (user-visible characters) in a string.
The only problem is that Delphi doesn't have a 4-byte character type.
WideChar is 16-bit and can only store code points up to 0xFFFF.
However, code points above 0xFFFF are still rarely used, mostly because
there are very few fonts that support them.
Kind regards,
Jan Goyvaerts
--
The world's most powerful grep tool just got better.
www.powergrep.com/
 

Re:Re: Borland Classic Products

At 02:59:53, 02.10.2005, Jan Goyvaerts wrote:
Quote
Thomas Miller < XXXX@XXXXX.COM >wrote:

>The idea is to take the code from FPC and UNICODE it.

If I understand you correctly, you want to convert existing code
written for AnsiStrings to use WideStrings?

There's basically 3 steps:
1. Replace "string" and "AnsiString" with WideString,
and "char" and AnsiChar with WideChar.
2. Remove all code that deals with DBCS
(i.e. checking the FarEast flag, LeadBytes, ByteType(), etc.)
3. Fix all code that expects a character to equal one byte.
3 is by far the biggest challenge, BTW.
--
Rudy Velthuis [TeamB] velthuis.homepage.t-online.de
"640K ought to be enough for anybody."
-- Bill Gates (1955-), in 1981
 

Re:Re: Borland Classic Products

Jan Goyvaerts wrote:
Quote
Thomas Miller < XXXX@XXXXX.COM >wrote:


>The idea is to take the code from FPC and UNICODE it.


If I understand you correctly, you want to convert existing code written for
AnsiStrings to use WideStrings?

There's basically 3 steps:
1. Replace "string" and "AnsiString" with WideString,
and "char" and AnsiChar with WideChar.
Why using WideString i.e. UCS-2 encoding? Use UTF-8 and you've basically
to change some string comparisons and search routines. When WideStrings
were invented, UTF-8 wasn't available but I think today, UTF-8 is the
way to go: for a lot languages UTF-8 requires less space than UCS-2. And
if you want to parse widestrings today ,you need also complicated
routines because of the surrogation pairs which weren't present when
widestrings were invented iirc.
 

Re:Re: Borland Classic Products

I would think UTF-8 would be the way to go to since I believe that
is what Delphi is already using in places and is what Danny has in
mind for the 64bit VCL.
What issues might we need to watch out for moving to UTF-8?
Florian Klaempfl wrote:
Quote
Jan Goyvaerts wrote:


>Thomas Miller < XXXX@XXXXX.COM >wrote:
>
>
>
>>The idea is to take the code from FPC and UNICODE it.
>
>
>If I understand you correctly, you want to convert existing code written for
>AnsiStrings to use WideStrings?
>
>There's basically 3 steps:
>1. Replace "string" and "AnsiString" with WideString,
>and "char" and AnsiChar with WideChar.


Why using WideString i.e. UCS-2 encoding? Use UTF-8 and you've basically
to change some string comparisons and search routines. When WideStrings
were invented, UTF-8 wasn't available but I think today, UTF-8 is the
way to go: for a lot languages UTF-8 requires less space than UCS-2. And
if you want to parse widestrings today ,you need also complicated
routines because of the surrogation pairs which weren't present when
widestrings were invented iirc.
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Borland Classic Products

On 2005-10-03, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
I would think UTF-8 would be the way to go to since I believe that
is what Delphi is already using in places and is what Danny has in
mind for the 64bit VCL.

What issues might we need to watch out for moving to UTF-8?
See if Windows supports it (for access to locale tables for e.g. uppercasing
in a locale dependant way)
Besides if you want to do that, you widen the scope from "just" duplicating
the VCL to duplicating bot hthe RTL+VCL, since all internal routines have to
be recoded to be UTF8 clean.
Moreover, it will break compability with existing (VCL) code, or at least
modifiations. (e.g. to fully work, userprograms have to be updated to be UTF8
clean in their ansistring handling too. Something they usually aren't).
 

Re:Re: Borland Classic Products

Marco van de Voort wrote:
Quote
On 2005-10-03, Thomas Miller < XXXX@XXXXX.COM >wrote:

>I would think UTF-8 would be the way to go to since I believe that
>is what Delphi is already using in places and is what Danny has in
>mind for the 64bit VCL.
>
>What issues might we need to watch out for moving to UTF-8?


See if Windows supports it (for access to locale tables for e.g. uppercasing
in a locale dependant way)

Besides if you want to do that, you widen the scope from "just" duplicating
the VCL to duplicating bot hthe RTL+VCL, since all internal routines have to
be recoded to be UTF8 clean.

Moreover, it will break compability with existing (VCL) code, or at least
modifiations. (e.g. to fully work, userprograms have to be updated to be UTF8
clean in their ansistring handling too. Something they usually aren't).

Going from ASCII to UNICODE isn't going to be easy. Danny has already
talked about the fact that the 64 VCL won't be backwards compatible.
What about GTK#2? What is it doing?
--
Thomas Miller
Wash DC Delphi SIG Chairperson
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
www.cpcug.org/user/delphi/index.html
https://sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re:Re: Borland Classic Products

On 2005-10-04, Thomas Miller < XXXX@XXXXX.COM >wrote:
Quote
>Moreover, it will break compability with existing (VCL) code, or at least
>modifiations. (e.g. to fully work, userprograms have to be updated to be UTF8
>clean in their ansistring handling too. Something they usually aren't).
>

Going from ASCII to UNICODE isn't going to be easy.
Correct. Moreover it will be hard, if not impossible to keep stuff running.
Quote
Danny has already talked about the fact that the 64 VCL won't be backwards
compatible.
That's logical, partially. However that is still a while away (if I can
believe the blogs), and compability is not an absolute thing. "largely"
compatible is often enough. (e.g. tcomponent.tag is often abused for
integers<->pointers)
Quote
What about GTK#2? What is it doing?
GTK#2 ? What's that? Do you mean GTK# v2 or GTK number 2? (GTK# is C# .NET
GTK)
Anyway, GTK is an engine under the LCL/VCL/CLX layer, just like GDI or QT
is. (and in the future Carbon). Win32(GDI) specific stuff of course won't work
unless emulated.