Re: [fpc-devel] don't you think it's time to update delphimodecompatibility? - IDispatch, implements
On Sat, 28 May 2005 08:26:20 +0700 "Bisma Jayadi" <[EMAIL PROTECTED]> wrote: > Marco van de Voort wrote: > > > Some known missing functionality: > > 1 implements style delegation > > 2 vararray support is patchy. > > 3 customvariants are missing in the rtl > > 4 packages > > 5 dispinterfaces and dispid. > > 6 assembler routines have some constructs that are not supported. > > Well... from Marco's latest reply I think I know why FPC still unable to > compile > D7 dbExpress components. Almost all compilation errors are caused by what > Marco's said. :) Can you tell which one(s) are missing then ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphimodecompatibility? - IDispatch, implements
Marco van de Voort wrote: > Some known missing functionality: > 1 implements style delegation > 2 vararray support is patchy. > 3 customvariants are missing in the rtl > 4 packages > 5 dispinterfaces and dispid. > 6 assembler routines have some constructs that are not supported. Danny Milosavljevic wrote: >> Because I still failed to compile my D7 codes under FPC 2.0. >> It's an D7 codes utilizing dbExpress components. > Hmm, well, more info please :) - Well... from Marco's latest reply I think I know why FPC still unable to compile D7 dbExpress components. Almost all compilation errors are caused by what Marco's said. :) -Bee- has Bee.ography at: http://beeography.modblog.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cthreads OR adding a first unit
On Fri, 27 May 2005, Mattias Gaertner wrote: > > Problem: > Some units require the cthreads unit, but only under linux and it must be > added as first unit to the main source. > > Questions: > Will the cthreads unit will be added as default someday under linux ? No. > Or will it become obsolete by some other unit/feature? If someone implements native thread handling, then cthreads will be obsolete. > Or will it stay this way: If you need threads under linux, you need to add > cthreads as first unit? For the time being, yes. > Is it possible to compile a unit A, so that the need for cthreads is > inherited to every unit using A? Some kind of extended -Fa flag with > inheritage? Not that I know of; you can include cthreads in the gtk interface; normally this should then enable threads for all lazarus apps. The fact that it is not first in the uses clause is risky, but not too much. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cthreads OR adding a first unit
Problem: Some units require the cthreads unit, but only under linux and it must be added as first unit to the main source. Questions: Will the cthreads unit will be added as default someday under linux ? Or will it become obsolete by some other unit/feature? Or will it stay this way: If you need threads under linux, you need to add cthreads as first unit? Is it possible to compile a unit A, so that the need for cthreads is inherited to every unit using A? Some kind of extended -Fa flag with inheritage? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc: ISO8859-1 -> ISO-8859-1 (fwd)
> From: Vincent Snijders <[EMAIL PROTECTED]>
>
> Michael Van Canneyt wrote:
> >
> >
> > On Fri, 27 May 2005, Vincent Snijders wrote:
> >
> > > Michael Van Canneyt wrote:
> > >
> > > >
> > > >
> > > > On Fri, 27 May 2005, Vincent Snijders wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I ran fpdoc generated html files through a html validator and
> > > > > it didn't like the ISO8859-1 encoding. Attached patch changes
> > > > > references to ISO8859-1 encoding to ISO-8859-1.
> > > >
> > > >
> > > >
> > > > Thanks. Applied.
> > > >
> > > >
> > > > >
> > > > > I also got errors like:
> > > > > Error: element NOBR not defined in this HTML version
> > > > >
> > > > > I don't know if and how this can be fixed.
> > > >
> > > >
> > > >
> > > > It is an unofficial IE and Netscape extension to HTML 4.
> > > > It should not be used, but I don't see how that can be done.
> > > >
> > >
> > > What if we added to fpdoc.css
> > > span.code {
> > > white-space: nowrap
> > > }
> > >
> > > and in the html replaced
> > > const ARG_MAX > > class="sym">= 131072 > > class="sym">;
> > >
> > > by
> > > const ARG_MAX
> > > = 131072 > > class="sym">;
> > >
> > > It seems to work in firefox 1.0.4 and IE 6.0.
> >
> >
> > Great!
> >
> > Can you make a patch for this ?
> >
>
> Certainly. Attached is one patch for fpdoc and one for the fpcdocs repositry.
Thanks. I applied the patch, merged it to fix branch.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc: ISO8859-1 -> ISO-8859-1
Michael Van Canneyt wrote:
On Fri, 27 May 2005, Vincent Snijders wrote:
Michael Van Canneyt wrote:
On Fri, 27 May 2005, Vincent Snijders wrote:
Hi,
I ran fpdoc generated html files through a html validator and it
didn't like the ISO8859-1 encoding. Attached patch changes
references to ISO8859-1 encoding to ISO-8859-1.
Thanks. Applied.
I also got errors like:
Error: element NOBR not defined in this HTML version
I don't know if and how this can be fixed.
It is an unofficial IE and Netscape extension to HTML 4.
It should not be used, but I don't see how that can be done.
What if we added to fpdoc.css
span.code {
white-space: nowrap
}
and in the html replaced
const ARG_MAX =
131072;
by
const ARG_MAX
= 131072class="sym">;
It seems to work in firefox 1.0.4 and IE 6.0.
Great!
Can you make a patch for this ?
Certainly. Attached is one patch for fpdoc and one for the fpcdocs
repositry.
Vincent.
Index: fpdoc.cst
===
--- fpdoc.cst (revision 8)
+++ fpdoc.cst (working copy)
@@ -53,6 +53,11 @@
font-size: 12pt
}
+/* source fragments */
+span.code {
+ white-space: nowrap
+}
+
/* symbols in source fragments */
span.sym {
color: darkred
Index: utils/fpdoc/fpdoc.css
===
--- utils/fpdoc/fpdoc.css (revision 127)
+++ utils/fpdoc/fpdoc.css (working copy)
@@ -53,6 +53,11 @@
font-size: 12pt
}
+/* source fragments */
+span.code {
+ white-space: nowrap
+}
+
/* symbols in source fragments */
span.sym {
color: darkred
Index: utils/fpdoc/dw_html.pp
===
--- utils/fpdoc/dw_html.pp (revision 127)
+++ utils/fpdoc/dw_html.pp (working copy)
@@ -804,7 +804,8 @@
function THTMLWriter.CreateCode(Parent: TDOMNode): THTMLElement;
begin
- Result := CreateEl(CreateEl(Parent, 'tt'), 'nobr');
+ Result := CreateEl(CreateEl(Parent, 'tt'), 'span');
+ Result['class'] := 'code';
end;
function THTMLWriter.CreateWarning(Parent: TDOMNode): THTMLElement;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc: ISO8859-1 -> ISO-8859-1
On Fri, 27 May 2005, Vincent Snijders wrote:
Michael Van Canneyt wrote:
On Fri, 27 May 2005, Vincent Snijders wrote:
Hi,
I ran fpdoc generated html files through a html validator and it didn't
like the ISO8859-1 encoding. Attached patch changes references to
ISO8859-1 encoding to ISO-8859-1.
Thanks. Applied.
I also got errors like:
Error: element NOBR not defined in this HTML version
I don't know if and how this can be fixed.
It is an unofficial IE and Netscape extension to HTML 4.
It should not be used, but I don't see how that can be done.
What if we added to fpdoc.css
span.code {
white-space: nowrap
}
and in the html replaced
const ARG_MAX = class="num">131072;
by
const ARG_MAX class="sym">= 131072class="sym">;
It seems to work in firefox 1.0.4 and IE 6.0.
Great!
Can you make a patch for this ?
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc: ISO8859-1 -> ISO-8859-1
Michael Van Canneyt wrote:
On Fri, 27 May 2005, Vincent Snijders wrote:
Hi,
I ran fpdoc generated html files through a html validator and it
didn't like the ISO8859-1 encoding. Attached patch changes references
to ISO8859-1 encoding to ISO-8859-1.
Thanks. Applied.
I also got errors like:
Error: element NOBR not defined in this HTML version
I don't know if and how this can be fixed.
It is an unofficial IE and Netscape extension to HTML 4.
It should not be used, but I don't see how that can be done.
What if we added to fpdoc.css
span.code {
white-space: nowrap
}
and in the html replaced
const ARG_MAX =
131072;
by
const ARG_MAX
= 131072class="sym">;
It seems to work in firefox 1.0.4 and IE 6.0.
Vincent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc: ISO8859-1 -> ISO-8859-1
On Fri, 27 May 2005, Vincent Snijders wrote: Hi, I ran fpdoc generated html files through a html validator and it didn't like the ISO8859-1 encoding. Attached patch changes references to ISO8859-1 encoding to ISO-8859-1. Thanks. Applied. I also got errors like: Error: element NOBR not defined in this HTML version I don't know if and how this can be fixed. It is an unofficial IE and Netscape extension to HTML 4. It should not be used, but I don't see how that can be done. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphi modecompatibility?
> So, may I conclude that FPC is targetting D7 language compatibility? That's > sound fair enough to me, and -thanks God- I can live with that. :) Roughly yes. That is the goal of the 2.0.x branch, languagewise. > Is the D7 compatibility has been reached fully or partially or still under > development? How far the compatibility of FPC v.2.0 with D7? Is there any > docs explain about this issue? Because I still failed to compile my D7 > codes under FPC 2.0. _language_ compability. Some known missing functionality: 1 implements style delegation 2 vararray support is patchy. 3 customvariants are missing in the rtl 4 packages 5 dispinterfaces and dispid. 6 assembler routines have some constructs that are not supported. These are being eliminated at a fairly decent rate the last few months Libraries are done on a case by case basis (is this part already legacy in D6/D7, is it too OS specific etc). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphi modecompatibility? - IDispatch, implements
Hi, Am Freitag, den 27.05.2005, 15:36 +0700 schrieb Bisma Jayadi: > > Name one that really enables you to do something that you couldn't do > > otherwise. > > Actually... none. :) > > > If you want portability, simply don't use D2005 syntax. > > Hmmm... very nice advice. :) > > > Write it in D7 and compile it everywhere. > > > > To my knowledge there are no plans for post-D7 support. The whole point is > > compability with Delphi.NET, and there is not much interest in that anyway. > > So, may I conclude that FPC is targetting D7 language compatibility? That's > sound fair enough to me, and -thanks God- I can live with that. :) > > Is the D7 compatibility has been reached fully or partially or still under > development? How far the compatibility of FPC v.2.0 with D7? Is there any > docs at least the (com) "implements" keyword and the variant IDispatch compiler support is still missing, whereas someone wanted to tell me the behaviour of the latter, but mysteriously vanished. Someone else started to implement the "implements" keyword, I think. For IDispatch, its something like if there is a variant (containing a ??? IUnknown reference) used in an expression, and then a dot follows, then pass the actual method name of the method called via idispatch to the interface in the variant. It's like i: IUnknown; v: Variant; i := mooo; v := i; v.Bla; <--- magical auto-"cast" to IDispatch and passing 'Bla' to be called to "Invoke" HRESULT Invoke( DISPID dispIdMember, REFIID riid, LCID lcid, WORD wFlags, DISPPARAMS FAR* pDispParams, VARIANT FAR* pVarResult, EXCEPINFO FAR* pExcepInfo, unsigned int FAR* puArgErr ); Use GetIDsOfNames or the object's documentation to obtain the dispatch identifier. --- Pretty sure I'm missing something (like for example what the dispids and 'dispatch interfaces' are for and such), and it makes no sense if we dont have an user who uses IDispatch (since it then cant be really tested, plus, on linux - where I am -, there are close to no apps that support that IDispatch interface at all). Someone please fill in the gaps. (Plus, I hated IDispatch when I was using delphi. Very good for variant-based runtime-only errors, hard to track down.) > explain about this issue? Because I still failed to compile my D7 codes under > FPC 2.0. It's an D7 codes utilizing dbExpress components. Hmm, well, more info please :) > > -Bee- > > has Bee.ography at: > http://beeography.modblog.com cheers, Danny www.keyserver.net key id A334AEA6 signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to updatedelphimodecompatibility?
| Totally agree with you! Let the FPC developer team concentrate on the compiler | and language enhancement, and let the rest of us do the supported units. If FPC | can do all the Delphi can do, then... viola!! all codes on Torry will be | compilable on FPC. And the concept of "write once, compile everywhere" will be | very much closer to the object pascal language. Isn't that nice? :) | Well this is somewhat a matter of prioritization I guess. Yes it would be good to prioritize compatibility with Delphi 5 and 6 since lots of code out there for delphi 5 and 6 exists already. Most of the code on torry is for delphi 3 4 5 that' I've used, though. Do you actually use any code that's for .net .. and if so, has it been rewritten for .Net or is it something that is special and totally unique? I think smaller compatibility issues are important, but nothing as far as the "for..in" stuff. If For In was classes, or object oriented programming, or dynamic arrays (big things.. that help someone significantly) then I could see it as something to prioritize. The sad thing is, people do not fork out 2000 dollars for Delphi 9 or whatever.. they just use their old delphi 3-4-5-6 compilers. Maybe the big corporations who love buzzwords.. but even applications like TotalCommander are still compiled in Delphi-3-4 as far as Stud_Pe tells me. I haven't even come across .Net myself: out of about 600 applications I have here and maybe about 50 I use often, none of them use .Net. I'm always wondering what in the world .Net is.. I think TCP/IP is important today in our applications and .Net is trying to make TCP/IP into something called .Net. The sad thing is, delphi components that do TCP/IP are out there for Delphi 3 or so. Internet ready applications... We just need to build TCP/IP wrappers for FPC, and forget the .Net fad. If TCP/Wrappers were out there that were extremely easy to use, FPC would be .Net.. i.e. it would compile everywhere and connect your apps to the internet. That, and we need to push freepascal as a dream for CGI developers. A lot of people still use PHP, who are delphi developers. What's up with that? Rewriting code for PHP that you've already written 5 years ago in delphi in Dos. And they need to come see the PSP project. I suppose someone could port PSP to kylix but PHP is free and PSP wouldn't be free on kylix. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphimodecompatibility?
> I'm sorry to say but none of these things will make FPC a better compiler by > a > large > part. Since freepascal doesn't have very many contributed units compared to > something > like Torry.net, I think that's what people need to work on! I don't actually > think > that it is the compiler team who needs to work more. they already have small > bugs to > repair, I think developers need to make contributed units and do work. The > language is > strong but more functions and wrappers need to be written. If you think about > it, no > one would use Delphi just for the "for if" part about it, but rather they > would use > delphi because of all the stuff available for it... like on Torry.net. Totally agree with you! Let the FPC developer team concentrate on the compiler and language enhancement, and let the rest of us do the supported units. If FPC can do all the Delphi can do, then... viola!! all codes on Torry will be compilable on FPC. And the concept of "write once, compile everywhere" will be very much closer to the object pascal language. Isn't that nice? :) -Bee- has Bee.ography at: http://beeography.modblog.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphi modecompatibility?
| FPC has great amounts of compatibility with Borland Delphi. Unfortunately, | according to the FPC docs, it only supports Delphi compatibility until Delphi 4. | The object pascal enhancement on the next Delphi release is still not supported | by FPC. | | Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which | has tons of great object pascal enhancement, don't FPC developers think that now | is the time to follow up the language enhancements? For example: the for..in | syntax, reintroduce keyword, sub class (class field), etc. | | Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC | development won't go that direction yet. I'm just talking about the language | enhancement here, for more code portability. Say, I'll be able to compile my | Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the | 'real' concept of "write once, compile everywhere". :D | | Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :) | | -Bee- I'm sorry to say but none of these things will make FPC a better compiler by a large part. Since freepascal doesn't have very many contributed units compared to something like Torry.net, I think that's what people need to work on! I don't actually think that it is the compiler team who needs to work more. they already have small bugs to repair, I think developers need to make contributed units and do work. The language is strong but more functions and wrappers need to be written. If you think about it, no one would use Delphi just for the "for if" part about it, but rather they would use delphi because of all the stuff available for it... like on Torry.net. Lars ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphi modecompatibility?
> Name one that really enables you to do something that you couldn't do > otherwise. Actually... none. :) > If you want portability, simply don't use D2005 syntax. Hmmm... very nice advice. :) > Write it in D7 and compile it everywhere. > > To my knowledge there are no plans for post-D7 support. The whole point is > compability with Delphi.NET, and there is not much interest in that anyway. So, may I conclude that FPC is targetting D7 language compatibility? That's sound fair enough to me, and -thanks God- I can live with that. :) Is the D7 compatibility has been reached fully or partially or still under development? How far the compatibility of FPC v.2.0 with D7? Is there any docs explain about this issue? Because I still failed to compile my D7 codes under FPC 2.0. It's an D7 codes utilizing dbExpress components. -Bee- has Bee.ography at: http://beeography.modblog.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] don't you think it's time to update delphi mode compatibility?
> FPC has great amounts of compatibility with Borland Delphi. Unfortunately, > according to the FPC docs, it only supports Delphi compatibility until Delphi > 4. > The object pascal enhancement on the next Delphi release is still not > supported > by FPC. > > Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- > which has tons of great object pascal enhancement, Name one that really enables you to do something that you couldn't do otherwise. > don't FPC developers think that now is the time to follow up the language > enhancements? For example: the for..in syntax, reintroduce keyword, sub > class (class field), etc. IMHO No. Stability and usability on D7 level is more important, than the relatively uninteresting extensions. Things like COM support and packages are way more important. > Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that > FPC development won't go that direction yet. Good. > I'm just talking about the language enhancement here, for more code > portability. If you want portability, simply don't use D2005 syntax. > Say, I'll be able to compile my Delphi.Net code using FPC > running on Linux. Maybe I'm just dreaming about the 'real' concept of > "write once, compile everywhere". :D Write it in D7 and compile it everywhere. > Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :) To my knowledge there are no plans for post-D7 support. The whole point is compability with Delphi.NET, and there is not much interest in that anyway. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] don't you think it's time to update delphi mode compatibility?
FPC has great amounts of compatibility with Borland Delphi. Unfortunately, according to the FPC docs, it only supports Delphi compatibility until Delphi 4. The object pascal enhancement on the next Delphi release is still not supported by FPC. Since now Delphi has grown to Delphi 9 (2005) -the latest Delphi release- which has tons of great object pascal enhancement, don't FPC developers think that now is the time to follow up the language enhancements? For example: the for..in syntax, reintroduce keyword, sub class (class field), etc. Yup, perhaps I sounds pretty close to .Net syntaxes. Yup, I also knew that FPC development won't go that direction yet. I'm just talking about the language enhancement here, for more code portability. Say, I'll be able to compile my Delphi.Net code using FPC running on Linux. Maybe I'm just dreaming about the 'real' concept of "write once, compile everywhere". :D Maybe we can start it from FPC v.2.2. Or FPC v.3.0? What do you think? :) -Bee- has Bee.ography at: http://beeography.modblog.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
