Re: [fpc-pascal]XChat plugins using FPC
On Wed, Jul 23, 2003 at 08:50:35AM +0200, Michael Van Canneyt wrote: > > > On Wed, 23 Jul 2003, James Mills wrote: > > > On Wed, Jul 23, 2003 at 03:28:55AM +0200, Marco van de Voort wrote: > > > > I can successully compile and test the plugin source listed at > > > > http://xchat.org/docs/plugin20.html written in C. > > > > > > > > However I don't like C much and am wondering if it's possible to do the > > > > same thing in pascal... ? I know it has to be possible, but I need > > > > someone to start me off in the right direction... > > > > > > Probably yes, but you'll need to convert headers of xchat-plugin.h. The > > > "h2pas" util can be handy for this. (or at least it can save a lot of time) > > > > Okay I've converted the headers (step 1) :P > > > > $ h2pas -S -D -p -l xchat xchat-plugin.h > > at line 6 error : syntax error > > Illegal character in line 6 > > "#define XCHAT_IFACE_VERSION((XCHAT_IFACE_MAJOR * 1) + \" > > at line 7 error : syntax error > > Illegal character in line 7 > > "(XCHAT_IFACE_MINOR * 100) + \" > > > > > > > > What do I do with these errors though ? > > run the file through the gcc preprocessor: > > gcc -E xchat-plugin.h -o xchat-plugin.hp > h2pas -S -D -p -l xchat xchat-plugin.hp > > Note that this destroys all '#define' constants, so you'll have to > run h2pas a second time to get all constants. > > Michael. > > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal I've sucessfully now done all this and now have the headers converted... I have a problem though when trying to compiling a test plugin: $ fpc test Free Pascal Compiler version 1.0.6 [2002/08/10] for i386 Copyright (c) 1993-2002 by Florian Klaempfl Target OS: Linux for i386 Compiling test.pas Compiling xchatplugin.pas xchatplugin.pas(49,24) Error: Identifier not found XCHAT_PLUGIN xchatplugin.pas(49,36) Error: Error in type definition xchatplugin.pas(50,22) Error: Identifier not found XCHAT_LIST xchatplugin.pas(50,32) Error: Error in type definition xchatplugin.pas(51,22) Error: Identifier not found XCHAT_HOOK xchatplugin.pas(51,32) Error: Error in type definition xchatplugin.pas(55,25) Error: Identifier not found XCHAT_CONTEXT xchatplugin.pas(55,38) Error: Error in type definition xchatplugin.pas(61,24) Error: Duplicate identifier _XCHAT_PLUGIN xchatplugin.pas(61,24) Error: Duplicate identifier _XCHAT_PLUGIN xchatplugin.pas(62,60) Error: Identifier not found PXCHAT_PLUGIN xchatplugin.pas(62,96) Error: Type identifier expected xchatplugin.pas(62,96) Fatal: Syntax error, ) expected but FUNCTION found What's going on here ? cheers James -- - - James Mills Zero Defect Software Engineers Group - ZDSEG ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]XChat plugins using FPC
On Thu, 24 Jul 2003, James Mills wrote: > On Wed, Jul 23, 2003 at 08:50:35AM +0200, Michael Van Canneyt wrote: > > > > > > On Wed, 23 Jul 2003, James Mills wrote: > > > > > On Wed, Jul 23, 2003 at 03:28:55AM +0200, Marco van de Voort wrote: > > > > > I can successully compile and test the plugin source listed at > > > > > http://xchat.org/docs/plugin20.html written in C. > > > > > > > > > > However I don't like C much and am wondering if it's possible to do the > > > > > same thing in pascal... ? I know it has to be possible, but I need > > > > > someone to start me off in the right direction... > > > > > > > > Probably yes, but you'll need to convert headers of xchat-plugin.h. The > > > > "h2pas" util can be handy for this. (or at least it can save a lot of time) > > > > > > Okay I've converted the headers (step 1) :P > > > > > > $ h2pas -S -D -p -l xchat xchat-plugin.h > > > at line 6 error : syntax error > > > Illegal character in line 6 > > > "#define XCHAT_IFACE_VERSION((XCHAT_IFACE_MAJOR * 1) + \" > > > at line 7 error : syntax error > > > Illegal character in line 7 > > > "(XCHAT_IFACE_MINOR * 100) + \" > > > > > > > > > > > > What do I do with these errors though ? > > > > run the file through the gcc preprocessor: > > > > gcc -E xchat-plugin.h -o xchat-plugin.hp > > h2pas -S -D -p -l xchat xchat-plugin.hp > > > > Note that this destroys all '#define' constants, so you'll have to > > run h2pas a second time to get all constants. > > > > Michael. > > > > > > ___ > > fpc-pascal maillist - [EMAIL PROTECTED] > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > I've sucessfully now done all this and now have the headers converted... > I have a problem though when trying to compiling a test plugin: > > $ fpc test > Free Pascal Compiler version 1.0.6 [2002/08/10] for i386 > Copyright (c) 1993-2002 by Florian Klaempfl > Target OS: Linux for i386 > Compiling test.pas > Compiling xchatplugin.pas > xchatplugin.pas(49,24) Error: Identifier not found XCHAT_PLUGIN > xchatplugin.pas(49,36) Error: Error in type definition > xchatplugin.pas(50,22) Error: Identifier not found XCHAT_LIST > xchatplugin.pas(50,32) Error: Error in type definition > xchatplugin.pas(51,22) Error: Identifier not found XCHAT_HOOK > xchatplugin.pas(51,32) Error: Error in type definition > xchatplugin.pas(55,25) Error: Identifier not found XCHAT_CONTEXT > xchatplugin.pas(55,38) Error: Error in type definition > xchatplugin.pas(61,24) Error: Duplicate identifier _XCHAT_PLUGIN > xchatplugin.pas(61,24) Error: Duplicate identifier _XCHAT_PLUGIN > xchatplugin.pas(62,60) Error: Identifier not found PXCHAT_PLUGIN > xchatplugin.pas(62,96) Error: Type identifier expected > xchatplugin.pas(62,96) Fatal: Syntax error, ) expected but FUNCTION found > > > What's going on here ? The unit is not correct. There are things that h2pas doesn't 'know' about. C is case sensitive. Pascal is not. so duplicate identifiers can exist. the C construct "xchat_plugin *" is translated to 'Pxchat_plugin', but that may or may not be defined already. In general, a generated file may still need some manual editing before it is compilable. This is perfectly normal. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]XChat plugins using FPC
> I've sucessfully now done all this and now have the headers converted... > I have a problem though when trying to compiling a test plugin: Hard to say without source. Please post the sources (headers, demo program, and maybe some readme that explains some stuff like needed xchat library version etc) somewhere. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> I would prefer a language that is tightly integrated with an OS... so tightly > that OS calls and language calls fit together in one smooth flow. I should not > have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to get > things to work. OS calls should be so seamless as to appear to be part of the > language, not part of yet another complex bag of tricks that has to be studied > and understood. In most cases, casting an ansistring as pchar will work. The only caveat is when Windows wants to alter the variable you pass' contenets. e.g. MessageBox( pchar(MyMessage), 'test', MB_OK); but not: GetUserName( pchar(Username), 255 ); //error!!! instead: var Username: array[0..255] or char; begin GetUserName( Username, 255 ); //This works!! end; This, however, is how Delphi does it, so you may find that your mileage varies. For example, the second GetUserName example my require an '@Username' param. > I'm not saying you should mask API calls to make them look like Pascal syntax. > Just the opposite, I'm thinking it might be better to bend Pascal to work > better with the OS... Make it natively work with null terminated strings in > windows, give it the same numerical structures as BEOS, support LINUX file > handling in Pascal's normal file handlers, etc. Most OS have similar concepts; they just accomplish things in different ways (e.g. Linux devices are all file descriptors, but BeOS devices are almost all file descriptors, and Windows Devices are not.) Wrapping up the differences is the smart way of making sure your skills are transferable. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
Lukas Gebauer wrote: For little example: On Delphi workd exists structure TSystemTime. Thjis is defined in Windows.pas, and all related time functions on delphi using this structure. For example, lot of functions inside sysutils.pas. it allows get system time by Win32 API call and then you can handle returned value by lot of functions in Sysutils.pas. This is great... Now Look to FPC: windows.pas have one TSystemTime record... and sysutils using another TSystemTime structure. Two different structures with same name! Now I must get system time by API call, I must CONVERT IT to another structure... and then I can continue. That's indeed a problem but there is no solution which works in all cases if you want multiplatform developemt. At least 1.1 allows type aliasing which causes problems in 1.0.x. But there are also some "strategic reasons" why 1.0.x isn't very much compatible with Delphi: the goal for 1.0.x was a 32 bit compiler understanding the subset defined by Turbo Pascal of object pascal. It was planned to achieve Delphi compatiblity as far as possible but if there was a choice between stability of the compiler and delphi compatibility we prefered stability, that's why 1.0.x doesn't have e.g. interfaces or multi threading support. For 2.0, i.e. the 1.1 development branch which will become 2.0, the goal is to compile as much as possible delphi code without changes. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
[ Charset ISO-8859-1 unsupported, converting... ] > > I would prefer a language that is tightly integrated with an OS... so > tightly > > that OS calls and language calls fit together in one smooth flow. I should > not > > have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to > get > > things to work. OS calls should be so seamless as to appear to be part of > the > > language, not part of yet another complex bag of tricks that has to be > studied > > and understood. > > In most cases, casting an ansistring as pchar will work. The only caveat is > when Windows wants to alter the variable you pass' contenets. > > e.g. >MessageBox( pchar(MyMessage), 'test', MB_OK); > > but not: > > GetUserName( pchar(Username), 255 ); //error!!! > > instead: > > var > Username: array[0..255] or char; > > begin > GetUserName( Username, 255 ); //This works!! > end; What about var username:AnsiString; begin SetLength(Username,255); GetUserName( pchar(Username), 255 ); Setlength(username,strlen(pchar(username)); end Or does that mess up reference counts? ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> (and this is for huge platform differents, for example: Linux compute > checksum of ICMPv6, but under Windows must compute by your > hands...etc. Sorry, but create special library for platform > independent ICMPv6 checksum computing is not right way.. it only > create tons of other units... ;-() 100% platform independance is indeed often counter-productive. However that isn't a good reason to don't do anything platform independant at all:-) > > > When I porting Synapse into FPC, then i find lot of incompatibilities > > > between Win32FPC and LinuxFPC. For example, look to Kylix > > > sysutils.pas... in FPC is not here lot of stuffs! > > Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x) > > branch delphi compability is roughly D2-D4 level! (though michael added > > quite some later stuff from time to time from later 1.0.x versions) > > I know, some stuffs from newer versions is added by my requests. > ;-))) > But when I porting Synapse to FPC, I found lot of incompatibilities > with my D3 (and with all higher versiopns of Delphi too!)... > > For little example: On Delphi workd exists structure TSystemTime. > Thjis is defined in Windows.pas, and all related time functions on > delphi using this structure. For example, lot of functions inside > sysutils.pas. it allows get system time by Win32 API call and then > you can handle returned value by lot of functions in Sysutils.pas. > This is great... This sucks big time. I'm stuck with half a windows api on non windows platforms. > Now Look to FPC: windows.pas have one TSystemTime record... and > sysutils using another TSystemTime structure. Two different > structures with same name! Now I must get system time by API call, I > must CONVERT IT to another structure... and then I can continue. Yes. The solution is not to mix platform dependant and independant programming, and only use platform dependant calls if strictly necessary. IOW, use a solution in sysutils that is platform agnostic to get the time. > All this and similar problems is reported by me to Michael. He really > very help me with porting of Synapse by adding lot of stuffs, what is > missing and I need it. But I don't think the platform dependant issues like this should be "fixed", but Michael probably agrees with that. > > Also keep in mind that FPC is aiming for much more platforms than Delphi > > ever will. That's a strength of FPC, but no strength comes without > > compromises. > > I know, it is not easy. > > here is tw ways, and both is needed: > > 1. easy to create multipltforms programs. You need lot of platform > independent units. The solution I choose. However it takes time. > 2. but someone not need multiplatform compatibility, they need use > existing code from delphi. For delphi exists very lot of code, Delphi > is biggest pascal community on world, I think. Yes. But most of the people using FPC use the multiplatform compability, except some educational users. It's FPC's main strength. Most of the Delphi code is copyrighted VCL dependant anyway, so can't be used without modifications. > I say, multiplatform compatibility is important, but compatibility > with delphi is important too! Maximum compatbility with Delphi is > very strategic. That's why we strive for both. But the multiplatform issue has priority if those two interests collide. At least in most cases. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]How to use Linux libraries?
Hello! Because I always wrote pascal programs which required no external code, I never had to deal with this and have absolutely no knowledge about how to do such things. Please, be so kind and help me understanding how I can use external Linux libraries. What I basically want to do is: Reading images into memory. Because there are so many different jpg/tif formats, I gave up writing all this code by myself and I would like to use one of the already existing libraries instead. The program shall simply read in a image file and store it in memory for further processing, then write it out to a file again. WITHOUT ANY GUI. Please, if somebody of you already has some code which shows me how to do that, how to embed a library, how to call the library functions, etc., leave me some code. It is much easier to understand than reading some highly academic descriptions. mfg Ing. Rainer Hantsch ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]How to use Linux libraries?
> never had to deal with this and have absolutely no knowledge about how to do
> such things.
> Please, be so kind and help me understanding how I can use external Linux
> libraries.
>
> What I basically want to do is: Reading images into memory.
>
> Because there are so many different jpg/tif formats, I gave up writing all
> this code by myself and I would like to use one of the already existing
> libraries instead.
A Pascal translation of the jpg library is already included with FPC.
For libraries in general, you have to translate the C header file. This can
be done to a certain account by the tool h2pas packaged with FPC, but
requires manual intervention afterwards.
Then add
{$linklib } to your header file unit, and make sure the
.a file can be found by the compiler (-Fl) options.
There should be quite some info about this in the manual.
> Please, if somebody of you already has some code which shows me how to do
> that, how to embed a library, how to call the library functions, etc., leave
> me some code. It is much easier to understand than reading some highly
Also don't forget that there are a lot of examples already in the FPC
sources. Half of the packages/ hierarchy interfaces to some C library.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> What about > > var username:AnsiString; > > begin > SetLength(Username,255); > GetUserName( pchar(Username), 255 ); > Setlength(username,strlen(pchar(username)); > end > > Or does that mess up reference counts? FPC may let you do that, but Delphi will have an error about not passing const params iirc. That or the result is garbage back from Windows. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]The state of FPC (was: Synapse for FPC)
Started a new thread because this is all getting off topic from Synapse.
> Opinions differ. But the IDE and parts of the compiler itself are TP.
Are there any plans to change this in future development? I, for one, like
the idea of comiling the compiler in Delphi, but TP features are no longer
supported. They are classes as legacy, and have many bugs in D3 let alone
D5+.
> If we had a lot of hard working people, we could make a nice new set of
> platform dependant units, and more and more TP units would become legacy.
>
> Do you volunteer?
To create a more rational unit set? Possibly, but last time I looked at the
way in which FPC creates units, the scheme was awfull. You used a generic
frame and {$i xxx.inc} for the platform. This is unmaintainable imho. One
thing I like from the Borland Source is that I can easily read it. If I was
to think about doing this I'd insist that the inc files went and that the
units are assembled by concatenating a PROCESSOR_PLAFFORM_UNITNAME.INF and
PROCESSOR_PLATFORM_UNITNAME.IMP together into a unit with a tool (sed?)
using a script. This way the units are kept seperated as you currenlty have
them, until realease, but at release you end up with a final unit that is
similar in layout to Borlands.
It's something I'd like to do, but I have a few things that I need to finish
first. Certainly when the PPC port is stable, I want to port it to BeOS ppc.
This may be a juncture to thing about contributing more time.
> We do in general. But 1.0.x is frozen, and we have to make adjustments for
> the fact that we have a strict visual<-> non visual separation, and a lot
> more platforms (and processors in the near future).
I think that, so long as you break all code into chunks that exist as
Interface and Implementation (as mentioned above) then install routie could
construct TP, Delphi or Wang doodle units structures. The unit construction
script (a makefile maybe? ) would simple have a rule for each unit, and be
driven by the 'platform' you select and the 'target processor' and
'programming environment'. Please stop me if anyone hates this idea. This is
what I envisioned the future structure to be though.
> No it isn't. It is roughly a superset of Delphi and TP, so also a superset
> over Borlands scheme.
It's more a subset of Delphi and the majority of TP merged to create a
Superset over Borland's shemes. This is therefore your own design, be it
unintentional or not. Let's not argue this point anymore.
> > LOL!!! I've been using Delphi since v1. This is a complete exageration.
> > Between D2 and D5 the unit changes are minor.
>
> So ansistrings, widestrings, dynamic arrays etc changes are minor?
Unless you use widestrings, nope, no difference. Unless you use dynamic
arrays, nope no diffewrence. Remember, we spoke of D3 -> D5, and D7 -> D5,
*not* D7 -> D3.
> How many differences are there inside the core units (like sysutils)
> compared to e.g. D3? What are the deviances of FPC except adding a few
extra
> units, and putting some platform dependant stuff in extra units?
Not for mainstream, regular features.
> Try to compile something from Jedi. They still support D5, but I sometimes
> wonder how long. FPC is still getting more compatible to newer Delphi's
> fast, I don't really see the problem.
The main problem with Jedi is the fast car syndrome. "My car is fast, I must
use it at full speed."
> > You should aim for D5. Most large corperations are still using D5. We
will
> > not move to D7, we are waiting for D8 for the dotNET implementation.
Even
> > then, we will likely leave some of our legacy systems in D5.
>
> This is not common IMHO. While in my surroundings there are indeed a lot
of
> people/companies that don't upgrade, I don't see a firm separation
somewhere
> between D5 and D6+.
Most people are waiting for D8 now if they are still using D5 because D6 and
D7 have been such turkeys. Two guys in a shed don't constitute enough
developers anymore, so hopefully Borland have improved this situation ;-)
> I don't understand all this. Sure, FPC is lagging behind in features, but
> "Borland got it right in many places that FPC didn't". Where does this
come
> from?
One of the main feature that FPC does in a way I find poor is oveloading of
proc's. Not sure if you support the Borland method now, but still annoying.
Also annoying how you are stricted with regards to assignment of pointers. I
remember that an additional cast used to be needed when setting up a
tagWNDCLASSEX for example. The lpfnWndProc field needed to be cast and
dereferenced, unlike Delphi. This made it necessary to use an ifdef for no
good reason! Maybe this is fixed now, but it was amazingly annoying. It
cropped up in other areas too.
> The only way to improve the situation is more collaborators, and/or a much
> higher users that e.g. occasionally does some work for FPC (update a
certain
> unit, make an interface etc). The situation nowadays is already much
better
> than it used to though say a few ye
Re: [fpc-pascal]Synapse for FPC
> 100% platform independance is indeed often counter-productive. However that > isn't a good reason to don't do anything platform independant at all:-) But I create tool for programmers and I hide all platform differencies in my tool. By my tool other programmers must not resolve any platform depending thinks in their socket programming. What is bad on this? :-O > > Now Look to FPC: windows.pas have one TSystemTime record... and > > sysutils using another TSystemTime structure. Two different > > structures with same name! Now I must get system time by API call, I > > must CONVERT IT to another structure... and then I can continue. > Yes. The solution is not to mix platform dependant and independant > programming, and only use platform dependant calls if strictly necessary. Fine.. but borland using sysutils unit as platform independent. In this unit is lot of functions what hiding differencies between Linux and Win32. By this Borlands programmers using this and similar units as platform independent wrappers. I not need to mix platform dependant and independent code, because I am using independent code! All platform depended thinks is hidden inside this units...I can very easy to create programs what running fine on Delphi and kylix. Now I try to port this my code to FPC. What is this? lot of functions in Syutils is missing! Well, lot of this functions is in another units.. and some of this functions have different names... I have platform independent code, but I must do lot of IFDEFS for FPC! This IFDEFS is not for platform independency, this is for incompatibility with Borland! ;-( Mostly all FPC based IFDEFS in Synapse is for result similar incompatibility problems. > > 2. but someone not need multiplatform compatibility, they need use > > existing code from delphi. For delphi exists very lot of code, Delphi > > is biggest pascal community on world, I think. > Yes. But most of the people using FPC use the multiplatform compability, > except some educational users. It's FPC's main strength. Most of the Delphi > code is copyrighted VCL dependant anyway, so can't be used without > modifications. Maybe most of the current people. ;-) How large is FPC community? How large is Dephi community? How many third-party code is available for Delphi? How many is available for FPC? How many programs is created and used by FCP... how many is created by Delphi? How many costs FPC? Nothing! But Delphi is very expensive. When you can be better compatible with Delphi, then you get access to lot of code (by third-party without Borland copyrights!). When you can get FPC as replacement of delphi, then you can get lot of new programmers, lot of new code, lot of new programs... > That's why we strive for both. But the multiplatform issue has priority > if those two interests collide. At least in most cases. All problems have their results! It must not to be 100 compatible, but you must have simple tools for good and quick Delphi porting. For example, in FPC sysutils is missing some Delphi stuffs. Well, you can create new unit with all missing Delphi stuffs. Porting programmer only add this new unit to their program. It is easy... -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > begin > > SetLength(Username,255); > > GetUserName( pchar(Username), 255 ); > > Setlength(username,strlen(pchar(username)); > > end > FPC may let you do that, but Delphi will have an error about not passing > const params iirc. That or the result is garbage back from Windows. ??? I am using this constructs under Delphi without problems... :-O -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003, Matt Emson wrote:
> Started a new thread because this is all getting off topic from Synapse.
>
> > Opinions differ. But the IDE and parts of the compiler itself are TP.
>
> Are there any plans to change this in future development? I, for one, like
> the idea of comiling the compiler in Delphi, but TP features are no longer
> supported. They are classes as legacy, and have many bugs in D3 let alone
> D5+.
>
> > If we had a lot of hard working people, we could make a nice new set of
> > platform dependant units, and more and more TP units would become legacy.
> >
> > Do you volunteer?
>
> To create a more rational unit set? Possibly, but last time I looked at the
> way in which FPC creates units, the scheme was awfull. You used a generic
> frame and {$i xxx.inc} for the platform. This is unmaintainable imho.
On the contrary. We switched to this exactly because the opposite cannot
be maintained. 8 years of cross-platform experience.
> One
> thing I like from the Borland Source is that I can easily read it. If I was
> to think about doing this I'd insist that the inc files went and that the
> units are assembled by concatenating a PROCESSOR_PLAFFORM_UNITNAME.INF and
> PROCESSOR_PLATFORM_UNITNAME.IMP together into a unit with a tool (sed?)
> using a script. This way the units are kept seperated as you currenlty have
> them, until realease, but at release you end up with a final unit that is
> similar in layout to Borlands.
You can simply make a preprocessor which does that if you find it fun to do.
But this doesn't change the unit structure, and gives no advantage in
maintainability at all. At most the end user finds it easier to read the
sources.
>
> It's something I'd like to do, but I have a few things that I need to finish
> first. Certainly when the PPC port is stable, I want to port it to BeOS ppc.
> This may be a juncture to thing about contributing more time.
>
> > We do in general. But 1.0.x is frozen, and we have to make adjustments for
> > the fact that we have a strict visual<-> non visual separation, and a lot
> > more platforms (and processors in the near future).
>
> I think that, so long as you break all code into chunks that exist as
> Interface and Implementation (as mentioned above) then install routie could
> construct TP, Delphi or Wang doodle units structures. The unit construction
> script (a makefile maybe? ) would simple have a rule for each unit, and be
> driven by the 'platform' you select and the 'target processor' and
> 'programming environment'. Please stop me if anyone hates this idea. This is
> what I envisioned the future structure to be though.
I think you'll have a hard time convincing the core members.
You haven't convinced me. The system as it is works well, it took us
some time to get it like that, so we're not likely to change it, just
because someone doesn't like split-up files.
When I was at borland for an interview, the first thing I asked was
support in the IDE for include files. They scratched their head, and
said they would think about it.
This is the main reason why Delphi sources are generally without include
files: because the IDE doesn't support them. Personally, I find it more
logical e.g. to have one include file per class, this is simply not
possible in Delphi.
> > I don't understand all this. Sure, FPC is lagging behind in features, but
> > "Borland got it right in many places that FPC didn't". Where does this
> come
> > from?
>
> One of the main feature that FPC does in a way I find poor is oveloading of
> proc's. Not sure if you support the Borland method now, but still annoying.
This is largely a matter of taste. In -Sd it is mandatory to use
Borland's way, so if you restrict yourself to that mode, you should
be fine.
See: We accomodate most tastes :-)
Michael.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > FPC may let you do that, but Delphi will have an error about not passing > > const params iirc. That or the result is garbage back from Windows. > > ??? I am using this constructs under Delphi without problems... :-O I don't remember ever getting it to work, but then I come from a D1 background (way back when) so maybe I assumed it doesn't work. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> On the contrary. We switched to this exactly because the opposite cannot > be maintained. 8 years of cross-platform experience. See below > You can simply make a preprocessor which does that if you find it fun to do. > But this doesn't change the unit structure, and gives no advantage in > maintainability at all. At most the end user finds it easier to read the > sources. Your final line is the reason I mention it in the first place. The include file system may be lovely for yourselves, but it is a mess imho. I have to look at 3 files before I find the piece of the source I want to look at, and even then I have to switch between the Interface and Implementation includes *This* is not acceptable or compatible with the way I work. This is what puts me off using FPC 90% of the time. This and the inconsistencies of the Unit structure. I think the end user would benefit from the 'preprocessed' units at release time, and the developers would keep whatever grand scheme they desire at development time. Please understand, I do not mean you should change your way of working, just that the end user should not have to see your messy include file ridden source. Does that make sense? > I think you'll have a hard time convincing the core members. > You haven't convinced me. The system as it is works well, it took us > some time to get it like that, so we're not likely to change it, just > because someone doesn't like split-up files. See above. > When I was at borland for an interview, the first thing I asked was > support in the IDE for include files. They scratched their head, and > said they would think about it. I'm pretty sure that the Unit files that are distributed by Borland are constructed by a script from a larger source repository. I doubt they work directly on the source files as we end users see them. > This is the main reason why Delphi sources are generally without include > files: because the IDE doesn't support them. Personally, I find it more > logical e.g. to have one include file per class, this is simply not > possible in Delphi. The IDE doesn't support them because they make the browsing of code complex and irritating. The way CBuilder handles Headers and C files is annoying enough imho. Thankflly Borland do not subject us to the torture FPC does. Remeber, just because it's easy to maintain for you, doesn't mean it's a good thing for the end user. That's a fact I'm afraid. > This is largely a matter of taste. In -Sd it is mandatory to use > Borland's way, so if you restrict yourself to that mode, you should > be fine. > > See: We accomodate most tastes :-) Nice to see FPC has come along since I last attempted to use raw Windows API in it ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003, Matt Emson wrote: > > On the contrary. We switched to this exactly because the opposite cannot > > be maintained. 8 years of cross-platform experience. > > See below > > > You can simply make a preprocessor which does that if you find it fun to > do. > > But this doesn't change the unit structure, and gives no advantage in > > maintainability at all. At most the end user finds it easier to read the > > sources. > > Your final line is the reason I mention it in the first place. The include > file system may be lovely for yourselves, but it is a mess imho. I have to > look at 3 files before I find the piece of the source I want to look at, and > even then I have to switch between the Interface and Implementation > includes *This* is not acceptable or compatible with the way I work. > This is what puts me off using FPC 90% of the time. This and the > inconsistencies of the Unit structure. > > I think the end user would benefit from the 'preprocessed' units at release > time, and the developers would keep whatever grand scheme they desire at > development time. > > Please understand, I do not mean you should change your way of working, just > that the end user should not have to see your messy include file ridden > source. Does that make sense? It does, with the proviso that 'messy' is a very personal appreciation of our file structure. I find it logical and not confusing at all. Keep in mind that it must be cross-platform. Your remarks are focusing on the point of view of a single platform user. For multi-platform development, wading though include files is easier than wading through zillions of IFDEF statements: At least from the name of the include file (displayed by your editor) you know in what part you are working. Not so when working with IFDEFs. > > > I think you'll have a hard time convincing the core members. > > You haven't convinced me. The system as it is works well, it took us > > some time to get it like that, so we're not likely to change it, just > > because someone doesn't like split-up files. > > See above. > > > When I was at borland for an interview, the first thing I asked was > > support in the IDE for include files. They scratched their head, and > > said they would think about it. > > I'm pretty sure that the Unit files that are distributed by Borland are > constructed by a script from a larger source repository. I doubt they work > directly on the source files as we end users see them. I think they do, because the IDE does NOT support include files, so you simply cannot work with include files and enjoy the blessings of the IDE. I was told that for productivity reasons they do all development in the IDE itself, so... > > > This is the main reason why Delphi sources are generally without include > > files: because the IDE doesn't support them. Personally, I find it more > > logical e.g. to have one include file per class, this is simply not > > possible in Delphi. > > The IDE doesn't support them because they make the browsing of code complex > and irritating. The way CBuilder handles Headers and C files is annoying > enough imho. Thankflly Borland do not subject us to the torture FPC does. > > Remeber, just because it's easy to maintain for you, doesn't mean it's a > good thing for the end user. That's a fact I'm afraid. Once more, this is a matter of taste. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > 100% platform independance is indeed often counter-productive. However > > that isn't a good reason to don't do anything platform independant at > > all:-) > > But I create tool for programmers and I hide all platform > differencies in my tool. By my tool other programmers must not > resolve any platform depending thinks in their socket programming. > What is bad on this? :-O That isn't. I was more hinting at the TSystemTime example. Sysutils is platform independant, and Windows is dependant. > > > Now Look to FPC: windows.pas have one TSystemTime record... and > > > sysutils using another TSystemTime structure. Two different > > > structures with same name! Now I must get system time by API call, I > > > must CONVERT IT to another structure... and then I can continue. > > Yes. The solution is not to mix platform dependant and independant > > programming, and only use platform dependant calls if strictly necessary. > > Fine.. but borland using sysutils unit as platform independent. In > this unit is lot of functions what hiding differencies between Linux > and Win32. By this Borlands programmers using this and similar units > as platform independent wrappers. I not need to mix platform > dependant and independent code, because I am using independent code! Therefore, don't mix it with a windows unit call! I see a getlocaltime function in sysutils for obtaining the time, using sysutils.TSystemTime record. > Now I try to port this my code to FPC. What is this? lot of functions > in Syutils is missing! You must make a difference between functions that are missing or slightly incompatible on purpose (e.g. because there are multiplatform considerations), and that are simply missing. The first categorie won't be fixed out of principle, though sometimes new discoveries/opinions can often change the behaviour. The second categorie will be remedied in time, and patches that fix them are usually accepted with gratitude. Open Source must come from both sides. > Well, lot of this functions is in another units.. and some of this > functions have different names.. It is hard to say. I'll look at synapse some more, but the important reason is _why_ they are in other units. Portability, or are you just searching equivalent functions in TP functions, while there is no reason to not add them to sysutils too? >.I have platform independent code, but I must do lot of IFDEFS for FPC! > This IFDEFS is not for platform independency, this is for incompatibility > with Borland! ;-( In time it should get less, but some will stay. > > Yes. But most of the people using FPC use the multiplatform compability, > > except some educational users. It's FPC's main strength. Most of the Delphi > > code is copyrighted VCL dependant anyway, so can't be used without > > modifications. > > Maybe most of the current people. ;-) How large is FPC community? How > large is Dephi community? We have to regard _our_ community. So we are only interested in the part of the Delphi community that is possibly interested in FPC. And interested in FPC because of its features and possibilities, not just a way to circumvent Borlands fee. Users that donate code back, and report fixes (like yourself) are much more important to us than people that only want to avoid Borlands money. > How many third-party code is available for > Delphi? What is the advantage to use FPC at all if it is not portable? (there are some other technical reasons like linking to gcc etc, but I mean _important_ ones here) So yes, compability issues that can be adressed, have to be addressed, but this is open source, and users are partially responsible for that too. Only active users are responsible users that contribute to FPC. The rest are just people avoiding fee's. > How many is available for FPC? How many programs is created and used by > FCP... how many is created by Delphi? Does it matter at all? > How many costs FPC? Nothing! But Delphi is very expensive. When you > can be better compatible with Delphi, then you get access to lot of > code (by third-party without Borland copyrights!). How much free code exactly is not-visual do you think? > When you can get FPC as replacement of delphi, then you can get lot of new > programmers, lot of new code, lot of new programs... True, but it is much less than you'd expect. > > That's why we strive for both. But the multiplatform issue has priority > > if those two interests collide. At least in most cases. > > All problems have their results! It must not to be 100 compatible, > but you must have simple tools for good and quick Delphi porting. For > example, in FPC sysutils is missing some Delphi stuffs. Well, you can > create new unit with all missing Delphi stuffs. Porting programmer > only add this new unit to their program. It is easy... You're welcome to submit it :-) ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo
Re: [fpc-pascal]Synapse for FPC
> > ??? I am using this constructs under Delphi without problems... :-O > I don't remember ever getting it to work, but then I come from a D1 > background (way back when) so maybe I assumed it doesn't work. On D1 not exists ansistrings and not exists setlength for strings. on D1 is impossible do this construct. From D2 I am using this construct for API calls without any problems. ;-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> It does, with the proviso that 'messy' is a very personal appreciation > of our file structure. I find it logical and not confusing at all. > > Keep in mind that it must be cross-platform. > Your remarks are focusing on the point of view of a single platform user. Exactly. For the average joe user, it's single platform work that matters. You are focusing as a FPC developer, not an end user. That is why you can't see how unwieldy and intimidating the FPC unit structure can be if you don't undestand it, or if you come from a Borland background. > For multi-platform development, wading though include files is easier > than wading through zillions of IFDEF statements: At least from the > name of the include file (displayed by your editor) you know in what > part you are working. Not so when working with IFDEFs. What I was proposing was that the FPC developers can keep their own scheme, but the end users should be presented with readable, single file units. This would make everything more accessable to the end user. > I think they do, because the IDE does NOT support include files, so you simply > cannot work with include files and enjoy the blessings of the IDE. > I was told that for productivity reasons they do all development > in the IDE itself, so... That will be why there are a lot of machine generated directives for C Builder then. They do that all by hand I guess. They at least use a master set of VCL units from which the distro is created. > > Remeber, just because it's easy to maintain for you, doesn't mean it's a > > good thing for the end user. That's a fact I'm afraid. > > Once more, this is a matter of taste. No, it's not. This is a matter of fact. It's also a matter of fact that many developers focus on their own back yard, and don't bnecessarily see the bigger picture. The end user is often ignored or worse still told they are wrong. Kind of like now really ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003, Matt Emson wrote: > > It does, with the proviso that 'messy' is a very personal appreciation > > of our file structure. I find it logical and not confusing at all. > > > > Keep in mind that it must be cross-platform. > > Your remarks are focusing on the point of view of a single platform user. > > Exactly. For the average joe user, it's single platform work that matters. NOT if they want to use FPC, which we _explicitly_ target as a _multiplatform_ development tool. Note that I don't deny that there is still work on the Delphi compatibility front. You're welcome to make contributions in this area. > You are focusing as a FPC developer, not an end user. > That is why you can't > see how unwieldy and intimidating the FPC unit structure can be if you don't > undestand it, or if you come from a Borland background. The average user will not want to dig in our sources in the first place. He/she wants to install the compiler, compile programs and not look at our sources. In fact, many don't even install the sources. Most developers in my company have never even seen the Delphi units, and they should not. Likewise for FPC. All other developers, which want a little more control and background, must endure a small learning curve. A small price to pay for cross-platform development IMHO. > > > For multi-platform development, wading though include files is easier > > than wading through zillions of IFDEF statements: At least from the > > name of the include file (displayed by your editor) you know in what > > part you are working. Not so when working with IFDEFs. > > What I was proposing was that the FPC developers can keep their own scheme, > but the end users should be presented with readable, single file units. This > would make everything more accessable to the end user. This I can live with, but I would provide this only as a service to the end user, and definitely not as the 'source' distribution. > > I think they do, because the IDE does NOT support include files, so you > simply > > cannot work with include files and enjoy the blessings of the IDE. > > I was told that for productivity reasons they do all development > > in the IDE itself, so... > > That will be why there are a lot of machine generated directives for C > Builder then. They do that all by hand I guess. They at least use a master > set of VCL units from which the distro is created. > > > > Remeber, just because it's easy to maintain for you, doesn't mean it's a > > > good thing for the end user. That's a fact I'm afraid. > > > > Once more, this is a matter of taste. > > No, it's not. This is a matter of fact. It's also a matter of fact that many > developers focus on their own back yard, and don't bnecessarily see the > bigger picture. The end user is often ignored or worse still told they are > wrong. Kind of like now really ;-) I meant that some people prefer include files to ifdefs. In that sense, it is a matter of taste. If one presumes as a fact that everybody prefers single-file sources with IFDEFS in it, then your statement about 'a matter of fact' is 100% correct, and I will not dispute it. But this presumption is IMHO not correct. It's all I wanted to say. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> That isn't. I was more hinting at the TSystemTime example. Sysutils is > platform independant, and Windows is dependant. Ok, enhance this my example: What is different between TSystemTme structure in sysutils and in windows? Windows structure have only one additional field 'DayOfWeak'! Why platform independent implementation in FPC sysutils not have this field? Simply add this field to FPC sysutils and then you have two compatible structures. What is platform depended on 'DayOfWeek'? Why is not here this field? Core of this problems is not platform independency. Or not? > I see a getlocaltime function in sysutils for obtaining the time, using > sysutils.TSystemTime record. Yes, but look to implementation. How much code is needed only for convert between two very similar data structures, because 'platform independent' not have one field? ;-O And this is only one of time functions... for example, I neet to get GetSystemTime. I must do same conversion as in your sysutils... uf! > > Well, lot of this functions is in another units.. and some of this > > functions have different names.. > It is hard to say. I'll look at synapse some more, but the important reason > is _why_ they are in other units. Portability, or are you just searching > equivalent functions in TP functions, while there is no reason to not add > them to sysutils too? For example, dynlibs. Same functions is in Borland sysutils. (for both, delphi and Kylix). But in FPC it is in separate unit, and one function have different name. (I mean UnloadLibrary instead FreeLibrary) Why is impossible put into your sysutils same functons as in Borland and this new functions will internally call dynlibs unit? If some platform not support dynlibs, then simply not add this functions into sysutils on this platform. > We have to regard _our_ community. So we are only interested in the part > of the Delphi community that is possibly interested in FPC. I can turn this. ;-) FPC is interesting for Delphi community only when FPC is interesting for Delphi. ;-))) > And interested in FPC because of its features and possibilities, not just a > way to circumvent Borlands fee. Users that donate code back, and report fixes > (like yourself) are much more important to us than people that only want to > avoid Borlands money. You are right. but people in delphi community have lot of their code. This people not like rewrite all only because FPC is great. It do rewriting only when then know: "it is small work and FPC add me more features." > What is the advantage to use FPC at all if it is not portable? (there are > some other technical reasons like linking to gcc etc, but I mean _important_ > ones here) How you know 'it is not portable'? And I think, some non-portable code can be interesting for FPC. Exists lot of technologies what is not portable and exists only on one platform. You ignore this technologies only because it is not portable? :-O > > How many is available for FPC? How many programs is created and used by > > FCP... how many is created by Delphi? > Does it matter at all? Sorry, what is freepascal? This is developer tool. Developer tools is for developing programs. When not exists lot of programs developed by this developer tool, then it is not developer tool, but this is developer toy. ;-) > > How many costs FPC? Nothing! But Delphi is very expensive. When you > > can be better compatible with Delphi, then you get access to lot of > > code (by third-party without Borland copyrights!). > How much free code exactly is not-visual do you think? I not count this. I cannot count of this. look to www.torry.net, for example. You can found lot of code what will be interesting for FPC, here is lot of code what is not platform dependant too. But convert it for FPC not interesting their developers, because it is not easy... ;-( > > All problems have their results! It must not to be 100 compatible, > > but you must have simple tools for good and quick Delphi porting. For > > example, in FPC sysutils is missing some Delphi stuffs. Well, you can > > create new unit with all missing Delphi stuffs. Porting programmer > > only add this new unit to their program. It is easy... > You're welcome to submit it :-) I plan do this very similar for Synapse's purposes. ;-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> I meant that some people prefer include files to ifdefs. In that sense, > it is a matter of taste. > > If one presumes as a fact that everybody prefers single-file sources with > IFDEFS in it, then your statement about 'a matter of fact' is 100% > correct, and I will not dispute it. One my notice: FPC style of coding is good for handle multiplatform sources, but for me (mean program developer) is this sources very badly readable. ;-( example: I need some some functions. What I need for use this function? i must know unit where this function is. (for adding it into uses) On Borland, i do simple text seach on Borland sources and directly I can see what unit I must use. But on FPC I gen only some include unit. I must do search again.. again... for getting unit name what I need. ;-( -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > You can simply make a preprocessor which does that if you find it fun to
> do.
> > But this doesn't change the unit structure, and gives no advantage in
> > maintainability at all. At most the end user finds it easier to read the
> > sources.
>
> Your final line is the reason I mention it in the first place. The include
> file system may be lovely for yourselves, but it is a mess imho. I have to
> look at 3 files before I find the piece of the source I want to look at, and
> even then I have to switch between the Interface and Implementation
> includes
It's a matter of taste, but don't forget otherwise you have to scroll/search
through the same amount of info. I really dislike units that are longer than
1000-2000 lines.
In time Lazarus could be adapted to make things a bit easier (e.g. opening
all includefiles too when opening an unit, and clicking a {$I ..} line
switches to it or so.
I do have to acknowledge that when I started on core, it took some time
to get used to it though. However there is no other clean solution.
Don't forget that for e.g. 2.0 there will be about 20 processor-OS
combinations.
Ifdeffing them all is simply not possible, and most system independant units
have a system independant part (header, but also utility routines etc) a
dependant part, and sometimes even a processor dependant part (but that
usually is much smaller)
> I think the end user would benefit from the 'preprocessed' units at release
> time, and the developers would keep whatever grand scheme they desire at
> development time.
How do you merge back user fixes then? Do you want to distribute each unit
for each platform-OS version? Would become a huge source zip then.
> Please understand, I do not mean you should change your way of working, just
> that the end user should not have to see your messy include file ridden
> source. Does that make sense?
"Messy" is your label, I don't consider it messy. It is close to the iron,
sure, but show me a large multi platform project that isn't.
Though there is some merit maybe in your arguing. While I don't feel like
distributing the mangled version, maybe the util that does that (for a
single unit or unit set) could.
People that prefer it, or want to for debug purposes, can generate a fully
OS-platform dependant unit (without much ifdef or includefiles).
The systematic directory layout used in most places should make finding the
includefiles automatically easy. So only defines that are not strictly
about platforms are a problem, but those will be relatively small.
So that is maybe a good point. So all we need is an interested volunteer I
think.
> > When I was at borland for an interview, the first thing I asked was
> > support in the IDE for include files. They scratched their head, and
> > said they would think about it.
>
> I'm pretty sure that the Unit files that are distributed by Borland are
> constructed by a script from a larger source repository. I doubt they work
> directly on the source files as we end users see them.
They probably have a full time helpdesk staff to deal with it, between users
and developpers. Under FPC, core does everything. Usersupport, documentation
development (there are 10 categories below this alone), bugrepport
analysise, release engineering, advocacy, website analysis, faq creation etc.
Putting more stress on the core team (this is yet another nail on the
coffin) would grind development to an halt. Why do you think that sysutils
unit is lagging behind?
The only systematic solution would be more people. And not in the future
(people have been saying that for years), but NOW.
Extra people don't have to be really hardcore developpers:
- People that get a kick out of helpdesk work can always apply ;-)
(answering questions, bugreport analysis)
- Intermediate users that compile a lot of Delphi code, and make a very
precise analysis of what is wrong, and how to fix it.
- we still need a webmaster
- documentation. (Michael does this nowadays), both making it and
proofreading.
- making headerconversions.
- making demoes
- be Lazarus liasions officer.
- somebody to look into the win32 net-installer thing.
And the list goes on.
> > This is largely a matter of taste. In -Sd it is mandatory to use
> > Borland's way, so if you restrict yourself to that mode, you should
> > be fine.
> >
> > See: We accomodate most tastes :-)
>
> Nice to see FPC has come along since I last attempted to use raw Windows API
> in it ;-)
Talking about raw api, maybe we should import Marcel van Brakels win32 API
into FPC 1.1.x (the same that Jedi advocates on its site). It is a bit biggish
though, first we need the net-installer then ;-)
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Thu, 24 Jul 2003, Lukas Gebauer wrote: > > That isn't. I was more hinting at the TSystemTime example. Sysutils is > > platform independant, and Windows is dependant. > > Ok, enhance this my example: What is different between TSystemTme > structure in sysutils and in windows? Windows structure have only one > additional field 'DayOfWeak'! > > Why platform independent implementation in FPC sysutils not have this > field? Simply add this field to FPC sysutils and then you have two > compatible structures. What is platform depended on 'DayOfWeek'? Why > is not here this field? > > Core of this problems is not platform independency. Or not? In this particular example, the field was simply forgotton, and we'll add it. This is not a problem. > For example, dynlibs. Same functions is in Borland sysutils. (for > both, delphi and Kylix). But in FPC it is in separate unit, and one > function have different name. (I mean UnloadLibrary instead > FreeLibrary) Simple: Our unit was implemented first, and the Borland unit appeared later ! > > Why is impossible put into your sysutils same functons as in Borland > and this new functions will internally call dynlibs unit? If some > platform not support dynlibs, then simply not add this functions into > sysutils on this platform. 1. We will add them in the main branch, just as you say, they will call the implementation in dynlibs, and will be Borland compatible. 2. They will raise an exception if not implemented on a specific platform. Otherwise users will still need IFDEFS anyway. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > I think they do, because the IDE does NOT support include files, so you > simply > > cannot work with include files and enjoy the blessings of the IDE. > > I was told that for productivity reasons they do all development > > in the IDE itself, so... > > That will be why there are a lot of machine generated directives for C > Builder then. They do that all by hand I guess. They at least use a master > set of VCL units from which the distro is created. They use the pascal sources I think. What are all those $HPEMIT and $EXTERNALSYM are for otherwise? (or are they for something packages $related?) > > Once more, this is a matter of taste. > > No, it's not. This is a matter of fact. It's also a matter of fact that many > developers focus on their own back yard, and don't bnecessarily see the > bigger picture. The end user is often ignored or worse still told they are > wrong. Kind of like now really ;-) It is taste. I'd bet that a lot of users would dislike the very long utils that are the result of that. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003, Lukas Gebauer wrote: > > I meant that some people prefer include files to ifdefs. In that sense, > > it is a matter of taste. > > > > If one presumes as a fact that everybody prefers single-file sources with > > IFDEFS in it, then your statement about 'a matter of fact' is 100% > > correct, and I will not dispute it. > > One my notice: > > FPC style of coding is good for handle multiplatform sources, but for > me (mean program developer) is this sources very badly readable. ;-( Excuse me, but you are NOT the mean program developer. The mean program developer does not write a TCP/IP suite. > > example: > > I need some some functions. What I need for use this function? i must > know unit where this function is. (for adding it into uses) 4 clicks using the documentation: Index, function name, jump to declaration. Unit is visible in navigation tree. I have tools set up to make the docs searchable on our website, but I need some free time to fix it. The ways of using Delphi and FPC are simply different... Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
Having read this thread with interest, I feel compelled to say something. Very simply put, I have no care how good a piece of code is by any other judgement. If it cannot be ported, it has already failed the most crucial test for code. Okay, maybe that is a bit harsh, there are obviously exceptions (nobody expects you to write a platform independant network device driver) and if you stick too religiously to this, then you deny developers the opurtunity to ever make use of platform specific features. However, if what you are depending on is in fact a platform specific bug, easter egg, undocumented feature, kludge or limitation then frankly your code has lost all interest. Doom was a great game, but all the greater because it scale from the single user dos world to the multi-user linux world without exploding. We are entering a world where the amount of platforms are increasing, maybe right now most software companies haven't noticed yet, but how long can they ignore the incessent growth of other platforms and be economically viable ? I first started using FPC in the very early days because it offered a TP compatible compiler on Linux, and those of you who knew me from then will remember the dos kludges of my code at the time. I stuck with FPC (including trying in my own ways to contribute) because it was multiplatform. It takes time to learn how to code platform independantly to the greatest degree. But it is a skill that I think will become a vital job requirement for all developers in less than 5 years. You can either stuff yourself up with java - or use a decent cross-platform compiler, and just code a little smarter (seems like a nobrainer to me). Having said all this, I think Lukas has written a really good piece of code in synapse, and I am glad about the fpc port. But Lukas, fpc is not intended to be a free replacement for borland, or a linux clone of tp or delphi. It is so much more than that, and if you code for it or in it, it is a deffinite advantage to never forget that. A.J. On Thu, 2003-07-24 at 09:38, Michael Van Canneyt wrote: > On Thu, 24 Jul 2003, Lukas Gebauer wrote: > > > > That isn't. I was more hinting at the TSystemTime example. Sysutils is > > > platform independant, and Windows is dependant. > > > > Ok, enhance this my example: What is different between TSystemTme > > structure in sysutils and in windows? Windows structure have only one > > additional field 'DayOfWeak'! > > > > Why platform independent implementation in FPC sysutils not have this > > field? Simply add this field to FPC sysutils and then you have two > > compatible structures. What is platform depended on 'DayOfWeek'? Why > > is not here this field? > > > > Core of this problems is not platform independency. Or not? > > In this particular example, the field was simply forgotton, and we'll > add it. This is not a problem. > > > For example, dynlibs. Same functions is in Borland sysutils. (for > > both, delphi and Kylix). But in FPC it is in separate unit, and one > > function have different name. (I mean UnloadLibrary instead > > FreeLibrary) > > Simple: > Our unit was implemented first, and the Borland unit appeared later ! > > > > > Why is impossible put into your sysutils same functons as in Borland > > and this new functions will internally call dynlibs unit? If some > > platform not support dynlibs, then simply not add this functions into > > sysutils on this platform. > > 1. We will add them in the main branch, just as you say, they will call >the implementation in dynlibs, and will be Borland compatible. > > 2. They will raise an exception if not implemented on a specific >platform. Otherwise users will still need IFDEFS anyway. > > Michael. > > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Do not try to think outside the box. That's impossible. Instead only try to realise the truthThere is no box. A.J. Venter Tech Guru DireqLearn. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> I need some some functions. What I need for use this function? i must > know unit where this function is. (for adding it into uses) > > On Borland, i do simple text seach on Borland sources and directly I > can see what unit I must use. > > But on FPC I gen only some include unit. I must do search again.. > again... for getting unit name what I need. ;-( This is what I was saying to Michael. The FPC team may thing the unit structure with include files is good, but I for one look at the source code *before* I look at the docs, because 80 - 90% of the time I find this more productive. FPC makes this very hard. Lukas - I think grep is your best friend with FPC. You need to find the function 'GetXXX' but don't know where it it - I usually grep for it (using Cygwin on Windows.) If you're not familiure with grep, some thing like: grep -r [Gg][Ee][Tt][Xx][Xx][Xx] c:\fpc\units > output.txt will generate you a list of all places it exists, recursively. The regular expression syntax I use is one of brute force rather than anything else and [Gg]etXXX would probably work too, so long as the case is consistent. You can probably do case insensetive searches too, I've never really looked into it myself. A good tutorial is at: http://pegasus.rutgers.edu/~elflord/unix/grep.html I'm not going to comment any more on this issue except to say that it *is* an issue. Michael - if none of your developers look at the Delphi source code, I shudder to think at the standard of programming they produce. I've never met a professional programmer who doesn't at least look at headers/interface sections of code to understand how a routine works. Not doing so is completely alien to the way I work normally, and I am not alone in this either. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> Ifdeffing them all is simply not possible, and most system independant units > have a system independant part (header, but also utility routines etc) a > dependant part, and sometimes even a processor dependant part (but that > usually is much smaller) What I suggested used no IFDEFS, none at all. Each platform end user release, has a set of platform specific units created by a preprocessor. This would be specifically for x86/Dos, x86/Windows, x86/Solaris, x86/BSD, x86/Linux, ppc/MacOSClassic, ppc/Linux etc. Surely this removes your problem with the idea. Single minded units that only contain a single platforms code. You give these to the end users, and you use these for unit testing etc in pre-release. However, the FPC developers continue to use the include file style units internally. Your source code should document your work, and making the document hard to read makes the work harder to use. IMHO of course. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]How to use Linux libraries?
On Thu, 24 Jul 2003, Marco van de Voort wrote: | A Pascal translation of the jpg library is already included with FPC. I am afraid that this is implemented in Delphi Style? I am one of those old guys who still program in OOP style, so this will possibly become somehow difficult ... Is there something where you can point me to? Reading a lot of sources is relatively heavy. If you say that jpeg is already impleented - where exactly? mfg Ing. Rainer Hantsch -- .-. | \\|// Ing. Rainer HANTSCH - Hardware + Software | | (o o) Forget Windoze! -- We focus on L-I-N-U-X... | |--oOOo-(_)-oOOo--| | Ing. Rainer HANTSCH | mail: [EMAIL PROTECTED] | | Khunngasse 21/20| www: http://www.hantsch.co.at | | A-1030 Vienna | tel: +43-1-79885380fax: +43-1-798853818 | | ** A u s t r i a ** | handy: +43-664-9194382 UID-Nr: ATU 11134002 | '-' ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
In reply to your message of July 24, 2003 > In most cases, casting an ansistring as pchar will work. The only caveat is > when Windows wants to alter the variable you pass' contenets. > e.g. >MessageBox( pchar(MyMessage), 'test', MB_OK); > but not: > GetUserName( pchar(Username), 255 ); //error!!! > instead: > var > Username: array[0..255] or char; > begin > GetUserName( Username, 255 ); //This works!! > end; > This, however, is how Delphi does it, so you may find that your mileage > varies. For example, the second GetUserName example my require an > '@Username' param. I tried that and still had problems. What I ended up doing is writing a really tiny string unit (CString) of my own that translates back and forth between string formats. It completely elimated the issue for me... I ended up with syntax like this: var Buffer : CString; begin MessageBox(CSTR(MyMessage,@Buffer), 'test',MD_OK); CSTR is a procedure that places the Null Terminated string in MyMessage into Buffer and passes the pointer to Windows. To get a string into pascal from windows, where I can mess with it I wrote an opposite translator PSTR which reads the buffer and converts it to a pascal string variable. var Buffer : CString; USer : String Begin GetUserName(PSTR(@Buffer),255); UserName := PSTR(@Buffer); This works. And so far it's 100% reliable... Typecasting and the Strings unit often produced strange results that ended up putting garbage into edit boxes and left me with unusable strings. For example, If the username was "Fred Smith", by your suggested method Length(Username) would return an error and SizeOf(username) would be 256. My way --running everything through a translator-- Length returns 10 and SizeOf returns 11 (because of the length byte). FWIW... CString is a tiny unit, less than 2k! If anyone wants a copy they can drop me an e-mail and I'll send it out by attachment... (I've submitted it to a website but it's not online yet.) I'm not angry, I like FP just fine, but, really, why should I have to write this unit? > Most OS have similar concepts; they just accomplish things in different ways > (e.g. Linux devices are all file descriptors, but BeOS devices are almost > all file descriptors, and Windows Devices are not.) Wrapping up the > differences is the smart way of making sure your skills are transferable. It is exactly this difference that spawned my comments. Unless there is a way to make the wrappers transparent to the programmer, you really have little choice but to bend the language a little. If you think about a project of some size (eg: a new web browser) it would be a lot smarter, and a lot more compatible, to run the sources through a conversion routine when going cross-platform than to include 1000 instances of some translator routine which would give you fits on the new platform. What I'm saying is that the native syntax of the language should be maintained as closely as possible between platforms, but the mechanics of each function and procedure should be altered to suit the platform. EG: when on windows FPC should work natively with null terminated strings, when on DOS it should work with pascal strings. But this difference should be invisible to the programmer... But then... I'm having the time of my life over here. Getting back into Pascal, learning a little C, writing my first windows programs (3 on the go right now), meeting a bunch of new people online... hey... I'm not complaining . - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]How to use Linux libraries?
On Thu, 24 Jul 2003, Rainer Hantsch wrote: > On Thu, 24 Jul 2003, Marco van de Voort wrote: > | A Pascal translation of the jpg library is already included with FPC. > > I am afraid that this is implemented in Delphi Style? > > I am one of those old guys who still program in OOP style, so this will > possibly become somehow difficult ... > > Is there something where you can point me to? Reading a lot of sources is > relatively heavy. If you say that jpeg is already impleented - where exactly? The pasjpeg unit. It is old style. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> Michael - if none of your developers look at the Delphi source code, I > shudder to think at the standard of programming they produce. I've never met > a professional programmer who doesn't at least look at headers/interface > sections of code to understand how a routine works. Not doing so is > completely alien to the way I work normally, and I am not alone in this > either. How do you propose to look without violating copyrights? We have to reverse engineer free Delphi apps to see what they call, and how they call it. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > Ifdeffing them all is simply not possible, and most system independant
> units
> > have a system independant part (header, but also utility routines etc) a
> > dependant part, and sometimes even a processor dependant part (but that
> > usually is much smaller)
>
> What I suggested used no IFDEFS, none at all. Each platform end user
> release, has a set of platform specific units created by a preprocessor.
> This would be specifically for x86/Dos, x86/Windows, x86/Solaris, x86/BSD,
> x86/Linux, ppc/MacOSClassic, ppc/Linux etc.
Then I have to fix one bug 20 times, since generic code is not shared.
Somewhere, platform dependant and independant code come together in
a unit.
> Surely this removes your problem with the idea. Single minded units that
> only contain a single platforms code. You give these to the end users, and
> you use these for unit testing etc in pre-release. However, the FPC
> developers continue to use the include file style units internally.
I don't see the problem with that, but I also don't see the harm in
a generator for people that want otherwise.
> Your source code should document your work, and making the document hard to
> read makes the work harder to use. IMHO of course.
Oh, please. We are not in school anymore. This is a production product,
spanning a host of version-compability and operating systems with a total
source size over 50 MB.
And more important, {$ifdef linux} etc is also selfdescribing source, so
documentation. The source clearly displays the differences between the
platforms.
If you want to start such converter tool btw, you might want to look at the
fpdoc documentation subproject, IIRC it already contains a parser.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
Matt Emson wrote: Michael - if none of your developers look at the Delphi source code, I shudder to think at the standard of programming they produce. I've never met a professional programmer who doesn't at least look at headers/interface sections of code to understand how a routine works. Not doing so is completely alien to the way I work normally, and I am not alone in this either. You may not be alone but you are in a very small minority. I have been coding in Delphi since 1.0 and can never think of any reason why I had to look at the Delphi code to do my own coding. They only time I had to dig into it was when I wanted to determine how Delphi did something that I wanted to match in the LCL. With your practice how do you use third party tools? In most cases they do not include any source to look at. How would you use 'C' libraries or ActiveX or code in Visual Basic. It is an interesting thing to do to look at the original source but to use it for your coding practice seems very strange to me. As MVC already stated in most cases FPC users don't even install the source so what would they have to look at in the first place. As was also stated you are using the mind set of a single platform development tool. FPC is not a single platform development tool and can not be viewed in that fashion. This can be talked about back and forth for a long time but I think it is safe to say that this isn't *AN ISSUE* this is *YOUR ISSUE*. You are free to use a different tool that is more to your liking. -- Programming my first best destiny! Michael A. Hess Miracle Concepts, Inc. [EMAIL PROTECTED] http://www.miraclec.com Phone: 570-388-2211 Fax: 570-388-6101 ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On donderdag, jul 24, 2003, at 16:19 Europe/Brussels, Marco van de Voort wrote: What I suggested used no IFDEFS, none at all. Each platform end user release, has a set of platform specific units created by a preprocessor. This would be specifically for x86/Dos, x86/Windows, x86/Solaris, x86/BSD, x86/Linux, ppc/MacOSClassic, ppc/Linux etc. Then I have to fix one bug 20 times, since generic code is not shared. That is not true. He suggests that we keep the source exactly as it is now in CVS, but to distribute it as explained above. Jonas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]How to use Linux libraries?
> | A Pascal translation of the jpg library is already included with FPC. > > I am afraid that this is implemented in Delphi Style? I don't expect so. It is a straight C translation, which is not OOP by nature. The idea was to build classes on top of that. > I am one of those old guys who still program in OOP style, so this will > possibly become somehow difficult ... > Is there something where you can point me to? Reading a lot of sources is > relatively heavy. If you say that jpeg is already impleented - where > exactly? I'm sorry, it is not in FPC, at least I can't find it, I was probably confused with a sister package (paszlib ) which was absorbed into FPC. Howrever the site is still up: http://www.nomssi.de/pasjpeg/pasjpeg.html ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003, Matt Emson wrote: > Michael - if none of your developers look at the Delphi source code, I > shudder to think at the standard of programming they produce. I am not the judge of my collegae, so allow me not to comment on this. But believe me if I say that they haven't looked at the sources, this is simply a fact. > I've never met > a professional programmer who doesn't at least look at headers/interface > sections of code to understand how a routine works. Then you're a lucky man. Stick around on the mailing lists, and help people who don't do this. There are still lots of them. > Not doing so is > completely alien to the way I work normally, and I am not alone in this > either. It is also alien to the way I personally work. I don't think there is a single VCL source file I haven't gone through at least once for my work, but I am not an average programmer. At least, I like to think that this is so. Opinions on this may wildly differ ;-) Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > Michael - if none of your developers look at the Delphi source code, I > > shudder to think at the standard of programming they produce. I've never met > > a professional programmer who doesn't at least look at headers/interface > > sections of code to understand how a routine works. Not doing so is > > completely alien to the way I work normally, and I am not alone in this > > either. Your developer was refering to the people you work with that you mentioned do not look at Delphi source. Not FPC people. > How do you propose to look without violating copyrights? We have to > reverse engineer free Delphi apps to see what they call, and how they > call it. Free CLX contains a large chunk of the RTL, and is already supporting Linux and Windows. I see sysutils, sysinit, system, types, variants, math, inifiles, syncobjs, typinfo, classes, contnrs, and a whole host of Linux specific units such as LibC. All the code is under GPL according to sf.net project page, and so all should be usable in some way shape or form by FPC developer without fear of reverse engineering. Look at Syllable (also of SF iirc.) This project has branched a complete operating system that was GPL, so Borland wouldn't have a leg to stand on imho. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> You may not be alone but you are in a very small minority. I have been > coding in Delphi since 1.0 and can never think of any reason why I had > to look at the Delphi code to do my own coding. They only time I had to > dig into it was when I wanted to determine how Delphi did something that > I wanted to match in the LCL. Having been a consultant for many years, this is the *only* way to work imho. I walk onto a site that I have never been to before and I must understand their source code immediately. I think that taking your approach, I would never get anything done. It's laughable to be honest. Your mindset is one of a deskbound office worker, not someone who has to pick up the pieces when the lead developer leaves (for example) and no one else understands his code. This is what the real problem is. I'm trying not to make this personal, but some of you FPC guys should look at the real world sometimes. > With your practice how do you use third party tools? In most cases they > do not include any source to look at. You buy the version with source. I've never come across a vendor that will not sell you the source for a price. This covers your back when said vendor (e.g. Turbo Power) go out of business and don't opensource *all* of their products (if at all.) What would you do, start again from scratch??!??! > How would you use 'C' libraries or > ActiveX or code in Visual Basic. It is an interesting thing to do to > look at the original source but to use it for your coding practice seems > very strange to me. I use the Pascal import Unit and curse M$ for creating a standard that so many vendors abuse. As for VB; sir you insult me to assume I even consider using a toy to get real work done :-P > As MVC already stated in most cases FPC users don't even install the > source so what would they have to look at in the first place. More fool them. > As was also stated you are using the mind set of a single platform > development tool. FPC is not a single platform development tool and can > not be viewed in that fashion. But all the source is seperated isn't it ? It doesn't all reside in a single dir? Last time I looked you had a Units/Win32, Units/Linux etc. Maybe this has been extended by now?! How on earth is concatenating the include files into a platform specific unit and putting it in the platforms source dir going to ruin cross platform development? You are finding excuses for the sake of it. No offence, but it sounds a lot like "father knows best" to me. > This can be talked about back and forth for a long time but I think it > is safe to say that this isn't *AN ISSUE* this is *YOUR ISSUE*. You are > free to use a different tool that is more to your liking. I do. Every day, man ;-) I'd use FPC if it was friendlier. I'd really like to; I'd like to contribute too, but I always get such negative feedback from the developers. No offence again. Why don;t you make it more democratic and put up a poll. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> If you want to start such converter tool btw, you might want to look at the > fpdoc documentation subproject, IIRC it already contains a parser. I think I already have a Pascal parser. I'd have to look in my personal code lib. I'll add it to my todo list and see what happens. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > > Michael - if none of your developers look at the Delphi source code, I > > > shudder to think at the standard of programming they produce. I've never > met > > > a professional programmer who doesn't at least look at headers/interface > > > sections of code to understand how a routine works. Not doing so is > > > completely alien to the way I work normally, and I am not alone in this > > > either. > > Your developer was refering to the people you work with that you mentioned > do not look at Delphi source. Not FPC people. Ok. But that is quite common btw, specially for people that use RADs. (type-ahead and function syntax in those floating over texts). I also did that when I used JBuilder. > > How do you propose to look without violating copyrights? We have to > > reverse engineer free Delphi apps to see what they call, and how they > > call it. > > Free CLX contains a large chunk of the RTL, and is already supporting Linux > and Windows. I see sysutils, sysinit, system, types, variants, math, > inifiles, syncobjs, typinfo, classes, contnrs, and a whole host of Linux > specific units such as LibC. > All the code is under GPL according to sf.net project page, and so all > should be usable in some way shape or form by FPC developer without fear > of reverse engineering. Yes, maybe to peek at, but not to use (when I last looked it was only the QT part, and only a bit bad), since that would contaminate FPC's license, and disallow commercial use of FPC generated binaries. I did use parts to test 1.1.x compability about half an year ago, when widestrings started to work a bit (as least their parsing), but in general it is confusing due to a lot subtle internal differences. However 1.1.x keeps getting better, and maybe it can be ported sometime, as compiler test or so. > Look at Syllable (also of SF iirc.) This project has branched a complete > operating system that was GPL, so Borland wouldn't have a leg to stand on > imho. If it remains GPL, that is not a problem, but we don't want the libraries GPL (the compiler and other end-user programs are though, but not the runtime libraries, since that would hamper users to distribute generated binaries without those apps themselves getting GPL'ed) ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > Michael - if none of your developers look at the Delphi source code, I > > shudder to think at the standard of programming they produce. > > I am not the judge of my collegae, so allow me not to comment on this. > But believe me if I say that they haven't looked at the sources, this is > simply a fact. Each to their own ;-) Believe me, I used to train Delphi for Borland. (My old company was the PSO for Borland when I joined them for approx 1 year, then Borland decided to do it themselves.) I also consulted for Borland at a couple of sites too. I'm not saying this makes any difference, just that I have quite a bit of experience of teaching Object Pascal to a wide range of abilities. > Then you're a lucky man. Stick around on the mailing lists, and help > people who don't do this. There are still lots of them. I do. I have. I will continue to ;-) It's not always easy to find the time and unfortunately my examples are often Delphi specific because I prototype in Delphi. Maybe writing that FPC plugin for the Delphi IDE would be a good place to start ;-) > It is also alien to the way I personally work. I don't think there is a single > VCL source file I haven't gone through at least once for my work, but I am not > an average programmer. > > At least, I like to think that this is so. Opinions on this may wildly differ ;-) You have my respect ;-) Don't read me complaining about file structures to be any kind of insult to your abilities. All FPC developers seem capable if not expert programmers ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > FPC style of coding is good for handle multiplatform sources, but for > > me (mean program developer) is this sources very badly readable. ;-( > > Excuse me, but you are NOT the mean program developer. The mean program > developer does not write a TCP/IP suite. I not mean ''main'.. I mean 'program developer'. I not programming only TCP/IP... I am programming final application too. It is my job. ;-) > > I need some some functions. What I need for use this function? i must > > know unit where this function is. (for adding it into uses) > 4 clicks using the documentation: > Index, function name, jump to declaration. Unit is visible in navigation tree. > > I have tools set up to make the docs searchable on our website, but I need > some free time to fix it. > > The ways of using Delphi and FPC are simply different... You not understand me. ;-) For me is readable written sources much better then documentation. Yes, documentation may be good, but sometimes I need information what is not in documentation. Where I can found reply? In sources! For me is readable sources very important, because it can give me reply for all my questions. Ilove opensource, because I can get answers from sources. And FPC sources is not good readable for me. This is just my opinion. ;-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> Lukas - I think grep is your best friend with FPC. You need to find the > function 'GetXXX' but don't know where it it - I usually grep for it (using > Cygwin on Windows.) If you're not familiure with grep, some thing like: I am using much easier way for this... I am using TotalCommander and their filesearch. I can directly browse fouded files, i can continue find within search result... and all by a few hit to keys. ;-) However searchingg through sources in delphi is much mure simple. ;-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
In reply to your message of July 24, 2003 > Exactly. For the average joe user, it's single platform work that matters. > You are focusing as a FPC developer, not an end user. That is why you can't > see how unwieldy and intimidating the FPC unit structure can be if you don't > undestand it, or if you come from a Borland background. Speaking as an FPC "end user" who's only a few weeks into using it on a part time basis, I have to agree. I've tried looking things up in the source code folders and it's a real chore. I was used to seeing the Interface parts of units as contiguous files where you can actually see each procedure (etc.) listed out ... the FP include files are a nightmare to wade through. I finally ended up doing some very time consuming in-file string searches trying to find a simple variable declaration. And after not finding what I wanted, I ended up writing to a complete stranger asking questions... (Good thing for me he turned out to be a nice person ) > What I was proposing was that the FPC developers can keep their own scheme, > but the end users should be presented with readable, single file units. This > would make everything more accessable to the end user. Yep.. at least for the Interface parts... FWIW, my dominant experience is in customer support and about half the calls my crew used to take were related to unclear or incomplete documentation. People would say "The help file says '...' What does that mean?" or it would turn out the information they needed just wasn't there at all. The days when we used to say "RTFM" in jest are pretty much gone. People do read these things (i.e. they do read FPC docs and source code). Now the problem is they either don't understand what it says or can't find the information they went looking for. They can't read at our level of technical skill, so we have to write at theirs. IMHO... It is very likely FPc's user base is being harmed by it's own file structure. Re-arrange the unit collection, hide the file used by the file used by the file that is used by the unit and give us clear Interface documentation for every unit and it's likely FPC will end up doubling it's user base in very short order. The first step is to simplify and rationalize the file structure... Start from your base PPC directory, branch to targets, then to units,bin,lib, then to sources and docs for each second level branch. I rearranged my copy of FP like this: h:\frepas\win32\bin h:\frepas\win32\bin\source h:\frepas\win32\units h:\frepas\win32\units h:\frepas\win32\units\fcl h:\frepas\win32\units\fcl\source ... h:\frepas\go32\bin h:\frepas\go32\bin\source ... and it's a LOT easier to find stuff in there now. Mind you, I doubt I could compile it from that without a LOT of fuss and trouble but it's also unlikely I would ever need to re-compile it. At least I can now find information when I need it. Where you must include depenencies in a distribution the file structure should reflect that, as in: \ppc\%target%\units\fcl \ppc\%target%\units\fcl\uses Where only the main ow and ppw files for FCL are in the fcl folder. The rest, the ones used by the main units, should be in the "uses" directory where we don't need to worry about them. A concise Interface declaration should also be present for each file we can directly list in our Uses clause. I'm used to seeing something like "sdos.tpu" accompanied by "sdos.txt" listing the interface declaration and, where necessary, any special instructions the unit requires. It might also be a lot clearer for the end user (i.e. me) if you moved the DOC directory over to: \ppc\%target%\units\fcl\doc Same with the sources: \ppc\%target%\units\fcl\source At least then we could easily associate the information with the files it's describing. Also... do you realize that *noplace* in your documentation do you tell us which files to list in our USES clauses for each unit? Thing is, FPC is a great little compiler... I didn't choose FPC because it's free. I have 2 different versions of Delpi and a copy of C++ within arm's reach... I don't need to use free compilers. I chose it because it's the best for what I want to do. Reason 1... I have a small DOS program that loads up, renames about 10,000 files I have in a clip art collection and then exits. I just re-wrote it for windows In D7 it's about 380k, in FP it's under 40k. Reason 2... To give a copy of a Delphi program to a friend I may also have to give out one or more DLLs. FP creates standalone EXEs. Reason 3... Doing a simple test of a "count to a zillion" program Delphi takes much longer than FP. Reason 4... I am not using "Object Oriented Programming". I'm an old school, brute force, programmer. Delphi gives me no choice. FP le
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > As was also stated you are using the mind set of a single platform > > development tool. FPC is not a single platform development tool and can > > not be viewed in that fashion. > > But all the source is seperated isn't it ? It doesn't all reside in a single > dir? No. It never has, at least not since 1997 when I joined. Unless you of course try to assemble it from the various files to form one source. > Last time I looked you had a Units/Win32, Units/Linux etc. Maybe this > has been extended by now?! How on earth is concatenating the include files > into a platform specific unit and putting it in the platforms source dir > going to ruin cross platform development? It isn't, if it is only the source that goes to the endusers, generated from a master source. (and keeping the file with includes for development) Those directory hierarchies only contain the parts that are dependant on that platform. Generic include files are in inc/, processor dependant parts in / OS AND processor dependant parts in / Files shared by the full Unix (clone) OSes are in unix/ (*BSD and Linux mainly) Most of the other platforms like QNX, BeOS share directory posix/ which implements a bit more restricted base library, you are probably more familiar with the exact BeOS situation than myself) Some Delphi parts (extensions to the system unit and sysutils generic include files) are in objpas/ > You are finding excuses for the > sake of it. No offence, but it sounds a lot like "father knows best" to me. Hmm, seems to be as "Consultant knows best" actually :-) But I'm sure you are a fine consultant. The current situation is an agreement between at least 10 people, all of them "fine" programmers, quite some professionally even, and at least 10-20 I urge you to be very careful btw, unless you really have real experience in full (as in lots of OSes and architectures independant) portable programming. Things aren't as easy as they seem. Also do an estimate about how much work something as FPC is, and then make it tenfold. > > This can be talked about back and forth for a long time but I think it > > is safe to say that this isn't *AN ISSUE* this is *YOUR ISSUE*. You are > > free to use a different tool that is more to your liking. > > I do. Every day, man ;-) I'd use FPC if it was friendlier. I'd really like > to; I'd like to contribute too, but I always get such negative feedback > from the developers. No offence again. It is a group process. > Why don;t you make it more democratic and put up a poll. Two possible answers. 1) Democracy doesn't work in companies or open source projects. In companies it is who pays the bills, in open source projects it is in who wants to do the work. Period. 2) It already is as democratic as it gets. Only the voters are the contributors not the users, and rougly pro ratio of their work. And the majority of the contributors (not users) decides, the rest (users and minority contributors) are left with the right to fork. That sounds harsh, but it is the only way really. Outsiders otherwise dream up elaborate plans, often with great grandeur and idealism, (the so called Silver Bullet), the more realistic main contributors bail out or realise that they are too few to even make a dent in the design on a parttime basis, and ultimately nobody does anything except discussing and arguing on the maillist, and a few concept source bits. Open Source reality is simply different from the business world. That this concept works is also proven by the relative rarety of forking, despite it being easy to do legally. I made that mistake too before I joined core. Dig for messages from me in the period 96-97 to see :-) Only if you actually have done quite some work, you get a feel for why things are the way they are, and that you can't tell core people to fix your problems first. Ask them politely at best. I also had a lot of plans, and a lot would become better because I saw things clearly. Ultimately, only some minor readjustments remained. Reality came crashing in. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
Matt Emson wrote: Free CLX contains a large chunk of the RTL, and is already supporting Linux and Windows. ... and it's full of terrible ifdef linux/win32 ... Can you imagine the mess if you handle 10 or more targets this way :) ? Almost ten years ago I started OS/2 and linux support this way and I decided really fast to use include files instead :) And from the view of maintainability it was a good decision. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
On Thu, 24 Jul 2003 15:17:50 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > > You can simply make a preprocessor which does that if you find it fun
> > > to
> > do.
> > > But this doesn't change the unit structure, and gives no advantage in
> > > maintainability at all. At most the end user finds it easier to read
> > > the sources.
> >
> > Your final line is the reason I mention it in the first place. The
> > include file system may be lovely for yourselves, but it is a mess imho.
> > I have to look at 3 files before I find the piece of the source I want
> > to look at, and even then I have to switch between the Interface and
> > Implementation includes
Yes, this is really pain under Delphi.
> It's a matter of taste, but don't forget otherwise you have to
> scroll/search through the same amount of info. I really dislike units that
> are longer than 1000-2000 lines.
>
> In time Lazarus could be adapted to make things a bit easier (e.g. opening
> all includefiles too when opening an unit,
Lazarus opens the include files internally. I don't think that many users
wants to open the 20 include files when opening classes.pp. They are opened
automatically when you do for example a method jump or a find declaration or
doubleclick on a codeexplorer item.
I think, an overview of the include files would be nice. I think, the code
explorer is a good place for this. Any ideas, how this information should be
merged into the code explorer?
> and clicking a {$I ..} line switches to it or so.
"Find declaration" and "open filename at cursor" does this.
> [...]
>
> > I think the end user would benefit from the 'preprocessed' units at
> > release time, and the developers would keep whatever grand scheme they
> > desire at development time.
>
> How do you merge back user fixes then? Do you want to distribute each unit
> for each platform-OS version? Would become a huge source zip then.
.. and think about bugreports and other communications referring to files
and line numbers. This can become a tower of babel.
> [...]
> Putting more stress on the core team (this is yet another nail on the
> coffin) would grind development to an halt. Why do you think that sysutils
> unit is lagging behind?
>
> The only systematic solution would be more people. And not in the future
> (people have been saying that for years), but NOW.
>
> Extra people don't have to be really hardcore developpers:
> - People that get a kick out of helpdesk work can always apply ;-)
> (answering questions, bugreport analysis)
> - Intermediate users that compile a lot of Delphi code, and make a very
> precise analysis of what is wrong, and how to fix it.
> - we still need a webmaster
> - documentation. (Michael does this nowadays), both making it and
> proofreading.
> - making headerconversions.
> - making demoes
> - be Lazarus liasions officer.
:)
> - somebody to look into the win32 net-installer thing.
>
> And the list goes on.
> [...]
Mattias
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]The state of FPC (was: Synapse for FPC)
> > It's a matter of taste, but don't forget otherwise you have to
> > scroll/search through the same amount of info. I really dislike units that
> > are longer than 1000-2000 lines.
> >
> > In time Lazarus could be adapted to make things a bit easier (e.g. opening
> > all includefiles too when opening an unit,
>
> Lazarus opens the include files internally. I don't think that many users
> wants to open the 20 include files when opening classes.pp. They are opened
> automatically when you do for example a method jump or a find declaration or
> doubleclick on a codeexplorer item.
I think that is ok.
> I think, an overview of the include files would be nice. I think, the code
> explorer is a good place for this. Any ideas, how this information should be
> merged into the code explorer?
I think this will be a bit hard, because not only purely the sequence
matters, but also the exact place inside of the source.
OTOH, for simply moving up and down from unit into include files it could be
ok. But I'm not really that used to such visual gadgets (I prefer kbd
shortcuts), so maybe I'm not the best judge of this.
> > and clicking a {$I ..} line switches to it or so.
>
> "Find declaration" and "open filename at cursor" does this.
I'd keyboard shortcut the last one, but for the rest ok:-)
> > [...]
> >
> > > I think the end user would benefit from the 'preprocessed' units at
> > > release time, and the developers would keep whatever grand scheme they
> > > desire at development time.
> >
> > How do you merge back user fixes then? Do you want to distribute each unit
> > for each platform-OS version? Would become a huge source zip then.
>
> .. and think about bugreports and other communications referring to files
> and line numbers. This can become a tower of babel.
Yes. The only option anyway is to provide a tool to generate such files for
own personal reference. But the human resource of the core team simply
are not up to adding anything which isn't really absolutely essential.
And no patches will be accepted about such units, and ambigious bugreports
set to "unreproducable" or so.
> >
> > The only systematic solution would be more people. And not in the future
> > (people have been saying that for years), but NOW.
> >
> > Extra people don't have to be really hardcore developpers:
> > - People that get a kick out of helpdesk work can always apply ;-)
> > (answering questions, bugreport analysis)
> > - Intermediate users that compile a lot of Delphi code, and make a very
> > precise analysis of what is wrong, and how to fix it.
> > - we still need a webmaster
> > - documentation. (Michael does this nowadays), both making it and
> > proofreading.
> > - making headerconversions.
> > - making demoes
> > - be Lazarus liasions officer.
> :)
It is actually quite serious.
> > - somebody to look into the win32 net-installer thing.
- release engineering
- other tools building (think about an idl2pas or so)
- helpfile and related tools.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]MMSYSTEM problem...
I've just discovered that the MMSYSTEM unit for Win32 is missing at least one of the function call prototypes... MCIWndCreate(...) is just plain not there. Anyone know where I can get a fixed copy? - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]What do you like about FPC?
I don't have time right now to read all the messages that flew today but I read enough to decide to send this note. IMHO, FPC is like a dream come true. I love the fact that I can compile the same code on Windows and Linux (and others). I love the ways the compiler is (mostly) backwards-compatible with turbo pascal but also decidedly more powerful. For what I do, the documentation is very good. I have never needed to resort to checking out the source ... although I have asked some questions here. I never used Delphi much. I can imagine Delphi-o-philes not being satisfied with FPC. Delphi is so much more than a compiler. I wouldn't bet against FPC reaching that level of bloat... I mean functionality... but it will take some time. -Alan Mead __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]What do you like about FPC?
Seconded. Mark Emerson Alan Mead wrote: > > I don't have time right now to read all the messages that flew today > but I read enough to decide to send this note. > > IMHO, FPC is like a dream come true. I love the fact that I can > compile the same code on Windows and Linux (and others). I love the > ways the compiler is (mostly) backwards-compatible with turbo pascal > but also decidedly more powerful. For what I do, the documentation > is very good. I have never needed to resort to checking out the > source ... although I have asked some questions here. > > I never used Delphi much. I can imagine Delphi-o-philes not being > satisfied with FPC. Delphi is so much more than a compiler. I > wouldn't bet against FPC reaching that level of bloat... I mean > functionality... but it will take some time. > > -Alan Mead > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]What do you like about FPC?
In reply to your message of July 24, 2003 > Seconded. Thirded ?? I like the compiler just fine. I was simply suggesting some improvements for the documentation. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]A suggestion.
While I absolutely adore FreePascal I miss one feature from my old borland days, but that would require a little work. I miss being able to put the cursor on a function/procedure/reserved word name and hitting F1 to see the help section for it. It was wonderful for looking up the structure of a function you had not used in a while. In fact, very often when stuck on how to do something, I would type in a likely-sounding name and upon hitting F1 get the info I needed (the beauty of Pascal is that pretty much everything has a likely sounding name). We already have documentation for every standard pascal function, and for most of the FPC specific additions (like fpc-crt or the linux unit functions) what I think we need to do is decide on a standard format (prefferably one you can convert to) with a reader that will grep the function descriptions based on a parameter, and show the section(s) which match. For example: fphelp writeln Should show you all you need to know about writeln. It will then take a fairly small patch to the FP-IDE to make it pass whatever word is under the cursor to the program. Ideally fphelp would simply print the results to standard out, that way a simple assignstream in the ide could capture the result and display it in a window, and people like me could use it with equal success in any other editor/ide that can be configured enough. Nedit and VIM(which I use) will both be able work just fine. This way we match the feature, and expand on it by not limiting it to those who *still* like the old (and very limited) dos style editing commands. Since there is nothing really complex about such a tool, if the underlying document format does not require platform specific libraries to read, it will also port beautifully to any of the FPC supported operating systems and architectures. What do everybody else think of such an approach to it ? I would love to write it as a contribution, but frankly the code here is not the issue, it is the choice of the underlying format. It must be searchable, fast, easy to convert to and not limited to any specific platform. Something like xml perhaps ? I wait to hear from all. -- Do not try to think outside the box. That's impossible. Instead only try to realise the truthThere is no box. A.J. Venter Tech Guru DireqLearn. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > Core of this problems is not platform independency. Or not? > In this particular example, the field was simply forgotton, and we'll > add it. This is not a problem. Great! ;-) If I replay my discussion int very short form, then it is look as: X> Synapse is not good, because it using lot of IFDEFS I> Lot of IFDEFS is using for resolve incompatibility between Delphi and FPC X> This incompatibilities is because FPC supporting much more platfrms. I> Lot of this incomptibilities is not dependng on platforms. I only try to explain, why I have lot of IFDEFS... I must create lot of IFDEFS only because FPC is not very copatible with Delphi, and this incompatibilities is not depending on multiplatform nature of FPC. Porting is not easy work. In this example, I use TSystemTime structure, and FPC compiler get me error: "No! What you are using? I need TSystemTime!" It must confuse lot of Delphi programmers. ;-/ One my mind... when FPC reporting error with expected data type, can they report me where this data type is declared? -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]MMSYSTEM problem...
L D Blake wrote:
I've just discovered that the MMSYSTEM unit for Win32 is missing at least one
of the function call prototypes... MCIWndCreate(...) is just plain not there.
Anyone know where I can get a fixed copy?
There is no such "fixed copy" of MMSystem unit. MMSystem unit is a
translation of mmsystem.h C header and functions MCIWnd* are in vfw.h
(BTW, this is true for Delphi as well). So you need a different unit. As
far as I know there is no such unit in FPC packeges.
Here are the complete instructions on how you can obtain the unit that
you want:
Searching with google I found this archive
http://www.torry.net/vcl/mmedia/video/vfw.zip
(linked from page http://www.torry.net/video.htm). It contains unit
Vfw.pas and this is what you need. BUT this unit is for Delphi 2/3/4 and
you have to modify it (a little) to compile this with FPC.
1) Remove two units from "uses" clause changing
Messages,
CommDlg,
to
{$ifndef FPC}
Messages,
CommDlg,
{$endif}
Those two units are not needed under FPC (their stuff is in Windows
unit) and both of them are even not available under FPC 1.0.x. (I don't
think CommDlg is available even in 1.1).
2) You need to add
type POPENFILENAMEA = POPENFILENAME;
and take declarations of two functions (GetOpenFileNamePreviewW and
GetSaveFileNamePreviewW) in interface (and their export-clauses in
implementation) in similiar {$ifndef FPC} ... {$endif} brackets.
(it's not the most elegant way to do that, you should check is UNICODE
symbol defined etc.; but doing as I said you will also get what you most
probably want)
And that's all - you have a unit Vfw.pas that can be compiled with FPC
1.0.10. Warning - I only compiled this unit under FPC 1.0.10, I did not
tested it (basically, I know nothing about functions in this unit, I was
simply able to adjust Delphi unit to FPC) ! So I don't guarentee it
works as it should. But probably it does, it's just a simple export
unit. And it containd MCIWnd* functions that you wanted.
Hope this helps,
--
Michalis Kamburelis
[EMAIL PROTECTED]
http://www.camelot.homedns.org/~michalis/ (in Polish)
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
