Re: [fpc-pascal] FPC release for Solaris not available on SF
On Thu, 28 Jul 2011, Graeme Geldenhuys wrote: Hi, While I was trying out OpenSolaris and FPC, I did notice one small issue. The FPC 2.4.4 release for Solaris is not available for download from SourceForge, but it was from the freepascal.org domain. Was this simply a minor oversight? Probably, yes. Someone in the core team with access to Sourceforge should probably upload it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer how to test
On 29-7-2011 9:27, michael.vancann...@wisa.be wrote: On Thu, 28 Jul 2011, Ludo Brands wrote: Agreed, but you cannot every kind of data type, for that you will probably need the various databases... and hopefully a continuous integration server to run the tests... Sqldb converts databases types to the internal ftxxx datatypes. So, yes, you can everything without external databases. I admit I need to delve deeper into this, but to me it's strange we have datatypes like ftOracleBlob and ftParadoxOLE... These do seem to be database-specific (ok, maybe within fcl-db, but still). Earlier today I've written code to dumbly create a bufdataset with all these datatypes for and will see what happens when assigning data to it. If it blows, I'll comment it out... we'll see. Db.pas line 2020 gives you the mapping between ftxxx and corresponding Tfield descendant. This is a default mapping but AFAIK no db implementation is actually overriding this. Not in FPC, but in Delphi, IBX for instance overrides it. Maybe mseide does it too. Michael. Ok, just to be safe and document mappings in any event, I'll keep the complete list of mappings in the exporter. I'll only test with the types that work in a bufdataset... Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : [fpc-pascal] XML-XSD export: importer how to test
Am 29.07.2011 08:27, schrieb michael.vancann...@wisa.be: Maybe mseide does it too. Correct. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] XML-XSD export: importer how to test
On Thu, Jul 28, 2011 at 4:28 PM, Reinier Olislagers reinierolislag...@gmail.com wrote: 5. I briefly thought about including OpenOffice Calc (ODT) format exporting but that seems a bit overkill as there already is a CSV export format. Any thoughts on new formats - apart from Atom ;) ? That would be export from Dataset to ODS? Why not simply implement a importer from Dataset for FPSpreadsheet instead of creating a new library to handle ODS? -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC release for Solaris not available on SF
michael.vancann...@wisa.be wrote: On Thu, 28 Jul 2011, Graeme Geldenhuys wrote: Hi, While I was trying out OpenSolaris and FPC, I did notice one small issue. The FPC 2.4.4 release for Solaris is not available for download from SourceForge, but it was from the freepascal.org domain. Was this simply a minor oversight? Probably, yes. Someone in the core team with access to Sourceforge should probably upload it. Assuming that Graeme is referring to Intel-architecture Solaris here, is there anything I can usefully do to help make a 2.4.4 SPARC binary available? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] XML-XSD export: importer how to test
On Fri, 29 Jul 2011, Felipe Monteiro de Carvalho wrote: On Thu, Jul 28, 2011 at 4:28 PM, Reinier Olislagers reinierolislag...@gmail.com wrote: 5. I briefly thought about including OpenOffice Calc (ODT) format exporting but that seems a bit overkill as there already is a CSV export format. Any thoughts on new formats - apart from Atom ;) ? That would be export from Dataset to ODS? Why not simply implement a importer from Dataset for FPSpreadsheet instead of creating a new library to handle ODS? Because depending on a full-fledged spreadsheet technology for exporting data is overkill. The idea of the export routines is to be able to export data without too much dependencies. Which does not mean that the opposite direction (importing data from a dataset into a spreadsheet) is not useful in it's own right, far from it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
Hi Mark, On 29 July 2011 08:49, Mark Morgan Lloyd wrote: Well done and thanks for testing. If you have any thoughts please could you append them to the wiki page I'll take a quick read through that wiki page and see if there is anything I can add. The compiling and running of fpGUI based apps has a *much smaller* library requirement than doing the same with Lazarus based apps. As I mentioned, OpenSolaris came standard with everything I needed to compile and run fpGUI apps - the only exception was the one package, gnu-binutils, required by FPC for linking purposes. I guess we can chalk this one up as one of the benefits of using a light weight toolkit [referring to library dependencies, not necessarily features]. If I have some time today, I'll try and compile MSEide on OpenSolaris (seeing that fpGUI doesn't have its own IDE). It would be interesting to see how portable MSEgui is in this regard. I know MSEide has some minor limitation even on 64-bit Linux platforms [MSEgui officially only supports 32-bit platforms], but that was easy enough to work around. @Martin Schreiber Just curious. Have you tried to compile MSEide on platforms other than Linux or Windows? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC release for Solaris not available on SF
On 29 July 2011 09:29, Michael wrote: Someone in the core team with access to Sourceforge should probably upload it. OK, I'll post in the fpc-devel mailing list. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Memds deprecated?
Hi list, According to Joost van der Sluis - 2010-07-22 12:14 in http://bugs.freepascal.org/view.php?id=13967 TMemDataset is deprecated and TBufDataset should be used instead. If this is true, could TMemDataset be marked as deprecated in the code and documentation? Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
Am 29.07.2011 08:41, schrieb Graeme Geldenhuys: @Martin Schreiber Just curious. Have you tried to compile MSEide on platforms other than Linux or Windows? No. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] XML-XSD export: importer how to test
On Fri, Jul 29, 2011 at 10:44 AM, michael.vancann...@wisa.be wrote: Because depending on a full-fledged spreadsheet technology for exporting data is overkill. The idea of the export routines is to be able to export data without too much dependencies. That's not really possible for ODS. You will need to at least add a dependency to paszlib and possibly to a xml library too. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] XML-XSD export: importer how to test
On Fri, 29 Jul 2011, Felipe Monteiro de Carvalho wrote: On Fri, Jul 29, 2011 at 10:44 AM, michael.vancann...@wisa.be wrote: Because depending on a full-fledged spreadsheet technology for exporting data is overkill. The idea of the export routines is to be able to export data without too much dependencies. That's not really possible for ODS. You will need to at least add a dependency to paszlib and possibly to a xml library too. Well, the exports are already dependent on fcl-XML. So adding paszlib is not really a heavy burden... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memds deprecated?
On Fri, 29 Jul 2011, Reinier Olislagers wrote: Hi list, According to Joost van der Sluis - 2010-07-22 12:14 in http://bugs.freepascal.org/view.php?id=13967 TMemDataset is deprecated and TBufDataset should be used instead. If this is true, could TMemDataset be marked as deprecated in the code and documentation? No. The idea is that TMemDataset becomes a descendent of TBufDataset. It has some methods that make operation more simple. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memds deprecated?
On 29-7-2011 11:10, michael.vancann...@wisa.be wrote: On Fri, 29 Jul 2011, Reinier Olislagers wrote: Hi list, According to Joost van der Sluis - 2010-07-22 12:14 in http://bugs.freepascal.org/view.php?id=13967 TMemDataset is deprecated and TBufDataset should be used instead. If this is true, could TMemDataset be marked as deprecated in the code and documentation? No. The idea is that TMemDataset becomes a descendent of TBufDataset. It has some methods that make operation more simple. Michael. Ok, that's clear, thanks. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
Am 29.07.2011 07:42, schrieb Graeme Geldenhuys: At the moment I'm using it to help develop the TfpgTextEdit component. I've never written an editor with syntax highlighting before, it's a nice challenge. It is rather a nightmare if you ask me... Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] operator overloading and counting references / creating / destoying anonymous instances
Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd: I wonder if I could ask a silly question here, without displaying too much ignorance. I generally understand the significance of an interface in the Windows context, where COM (or whatever today's name for it) is integrated fairly deeply into the OS. But what of other OSes like Linux? Does the use of interfaces as a way of getting refcounted storage assume the presence of CORBA etc., and how much overhead is there at program startup- does it demand that an ORB be loaded into memory? While COM-interfaces in Delphi/FPC are designed to be Delphi compatible, they do not rely on COM. Basically a IInterface or IUnknown is simply an interface that contains calls for increasing/releasing a reference count. You as the implementor of the interface need to provide the implementation. So e.g. TInterfacedObject which implements IInterface implements a reference counting mechanism where the object is freed when the reference count reaches zero. In FPC/Delphi this reference count is normally controlled by the compiler by calling the methods of IUnknown, but in C/C++ these calls need to be done manually (AFAIK). CORBA-interfaces as implemented by FPC are just plain interfaces without any methods defined. Also the compiler does not generate code to influence the reference count as it does with COM-interfaces. Basically an interface in FPC/Delphi is something that allows you to use certain methods (those provided by the interface) without knowing what the implementing class does. The COM-interface just contain a bit more compiler magic, but that's it. So no, you don't need an ORB or something like that. Regards, Sven PS: There is also a third kind of interfaces called dispinterface that contain again more compiler magic and are indeed used with COM automation (or XPCOM on non-Windows). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
I have run across another even more severe problem: Although using reference counted interfaces makes everything work without memory leaks there is one problem that gives all the nice syntactic sugar a really bad taste: A := B I am not allowed to overload the assignment of equal types. This means in the above I would have created a reference to B instead of a copy. If I now do an operation on A that does *not* create a new instance of it I will also change the value that B is pointing to, so I am *forced* to make new instances even if I could in some cases easily avoid them. Otherwise the user of that unit would have many WTF-moments when debugging the unexpected strange behavior in his code and all the efforts of making it look and behave natural would effectively be nullified by such a problem. Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] operator overloading and counting references / creating / destoying anonymous instances
Sven Barth wrote: Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd: I wonder if I could ask a silly question here, without displaying too much ignorance. I generally understand the significance of an interface in the Windows context, where COM (or whatever today's name for it) is integrated fairly deeply into the OS. But what of other OSes like Linux? Does the use of interfaces as a way of getting refcounted storage assume the presence of CORBA etc., and how much overhead is there at program startup- does it demand that an ORB be loaded into memory? While COM-interfaces in Delphi/FPC are designed to be Delphi compatible, they do not rely on COM. Basically a IInterface or IUnknown is simply an interface that contains calls for increasing/releasing a reference count. You as the implementor of the interface need to provide the implementation. So e.g. TInterfacedObject which implements IInterface implements a reference counting mechanism where the object is freed when the reference count reaches zero. In FPC/Delphi this reference count is normally controlled by the compiler by calling the methods of IUnknown, but in C/C++ these calls need to be done manually (AFAIK). CORBA-interfaces as implemented by FPC are just plain interfaces without any methods defined. Also the compiler does not generate code to influence the reference count as it does with COM-interfaces. Basically an interface in FPC/Delphi is something that allows you to use certain methods (those provided by the interface) without knowing what the implementing class does. The COM-interface just contain a bit more compiler magic, but that's it. So no, you don't need an ORB or something like that. Regards, Sven PS: There is also a third kind of interfaces called dispinterface that contain again more compiler magic and are indeed used with COM automation (or XPCOM on non-Windows). So if I understand you correctly, use of interfaces does not imply use of OS or ORB facilities, but can permit it if required. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
On 29/07/11 06:39, Jürgen Hestermann wrote: Bernd schrieb: Occasionally I hear other people mentioning operator overloading as a must-have feature of any decent language but I wonder what real-world problems they are actually solving with it. I think operator overloading is a pain. As you said: What is the advantage? For me operators should be defined by the language only It improves readability, making it more logical. Say for instance you are working on Galois fields and you have to do arithmetic on the elements like this: g1 + g2 / g3 If you don't have operator overloading, you have to do it with functions, like this: gf_add(g1, gf_div(g2, g3)) This is not very readable, I'm sure you will agree. They have to be used carefully, however. clear. But now there is no way back. It's implemented. Pascal moves in C direction... Troll. C has no operator overloading. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC release for Solaris not available on SF
On 29 July 2011 10:34, Mark Morgan Lloyd wrote: Assuming that Graeme is referring to Intel-architecture Solaris here, is Yes, sorry for my incomplete message. I am referring to Solaris x86 platform release. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
On 29 July 2011 10:01, Martin Schreiber wrote:
@Martin Schreiber
Just curious. Have you tried to compile MSEide on platforms other than
Linux or Windows?
No.
I just tried under OpenSolaris. There was some compiler errors.
Basically some {IFDEF Linux} I had to change to {IFDEF unix} when
appropriate. It then managed to compile MSEide, but the linking failed
due to the usage of iconv. I then tried to manually install GNU
libiconv but that didn't work either. Lots of 'undefined symbol'
errors. I tried to remove code referencing iconv or cwstring units,
but that did not solve anything, just brought on more problems. That's
when I called it a day. Back to work I go. :)
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
On 29 July 2011 10:38, Martin Schreiber wrote: the TfpgTextEdit component. I've never written an editor with syntax highlighting before, it's a nice challenge. It is rather a nightmare if you ask me... Definitely. There are so many things one takes for granted in a programming editor. A lot more work than I expected. [then again, what isn't] Also, disabling the syntax highlighting gives my editor component decent performance. Add it back in, and my editor comes to a crawl! :-( I'm trying to use regex [another think I'm trying to learn] for the syntax highlighting, so I could maybe import gEdit or Midnight Commander's syntax definitions. But I still have lots of work ahead. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
Am 29.07.2011 12:00, schrieb Bernd: I have run across another even more severe problem: Although using reference counted interfaces makes everything work without memory leaks there is one problem that gives all the nice syntactic sugar a really bad taste: A := B I am not allowed to overload the assignment of equal types. This means in the above I would have created a reference to B instead of a copy. If I now do an operation on A that does *not* create a new instance of it I will also change the value that B is pointing to, so I am *forced* to make new instances even if I could in some cases easily avoid them. No. Just check the ref. count if you plan to do an operation on A: if it's 1, create a copy for A and operate on the copy. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
On Thu, Jul 28, 2011 at 11:06 AM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Hi, After reading a post about another FPC developers trying to get a development system up and running under Solaris 10, I got curious. I downloaded OpenSolaris 2010.03 (dev 134). Installation was painless inside VirtualBox. Downloaded FPC's 2.4.4 release for Solaris. Installation was the easiest ever using that extra install script! [Yes even easier than under Linux or Windows] :) I then went ahead and installed git and GNU binutils packages, so I can get some source code and so that FPC can link executables. Again nothing difficult there. I pulled source code for fpGUI from the repository, and fired off the build.sh script. One minor compiler error that I quickly fixed. Reran the build script. Oh yeah!!! 2nd compile and it worked perfectly! :-D I went ahead and compiled a few more apps: The UIDesigner (fpGUI's visual form designer), fpgIDE (an example project resembling and IDE) and a few other example projects. They all worked without a hitch! Here are some screenshots. http://opensoft.homeip.net:8080/~graemeg/fpgui_on_solaris-1.png http://opensoft.homeip.net:8080/~graemeg/fpgui_on_solaris-2.png or if your ISP or company blocks DynDns domains... http://sourceforge.net/project/screenshots.php?group_id=182330 That means fpGUI Toolkit now runs under the following platforms: - Linux - FreeBSD - DesktopBSD - OpenSolaris - Embedded Linux - Windows - Windows CE. - Mac OSX 10.6.x (via the built-in X11 support) Good job! Kudos to the Free Pascal Compiler team for doing a great job once again. FPC rocks! +1 Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
I just tried under OpenSolaris. There was some compiler
errors. Basically some {IFDEF Linux} I had to change to
{IFDEF unix} when appropriate. It then managed to compile
MSEide, but the linking failed due to the usage of iconv. I
then tried to manually install GNU libiconv but that didn't
work either. Lots of 'undefined symbol' errors. I tried to
remove code referencing iconv or cwstring units, but that did
not solve anything, just brought on more problems. That's
when I called it a day. Back to work I go. :)
--
Regards,
- Graeme -
Mselibc.pas contains linux system constants and structures which are quite
different for solaris (ioctrl, error, locale, pthread, ...). So even when it
links it won't run very far.
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
2011/7/29 Jürgen Hestermann juergen.hesterm...@gmx.de: Bernd schrieb: Occasionally I hear other people mentioning operator overloading as a must-have feature of any decent language but I wonder what real-world problems they are actually solving with it. I think operator overloading is a pain. As you said: What is the advantage? For me operators should be defined by the language only (Pascal) so that everybody who reads the code imediately knows what happens. Instead you now need additional information (that can be far away from the code lines you review). That makes code obscure and less clear. But now there is no way back. It's implemented. Pascal moves in C direction... I'm not condemning it per se. It has its uses. I can still overload at least the comparison operators for example, I didn't want to rant against operator overloading in general. I only think it is overrated and often more complicated than useful. If I have a type that can be created and deleted/overwritten on the stack on the fly (record, object) without needing a destructor to free additional resources then everything can be made to work as if it were a natural part of the language and there would be no performance penalty and everything would be fine. My question was only if there are really many different real-world examples that go beyond the complex numbers example and maybe some simple linear algebra types, that can fit their entire data into a record on the stack without needing any allocation/deallocation of heap or external resources. Making a nice looking lightweight wrapper around an external library would surely be very desirable but I can't see any way to overcome the problems and these seem fundamental problems to me. This seems to need some non-trivial optimizations that might even need help from the compiler itself to make it really effective. With interfaces and their reference counting it can be made to work but the cost of doing this seems so immense that I don't believe it is justifiable in many real world applications (at least not in my application). Maybe if there were a way to make the compiler generate code to hook into whenever a record is created/deleted/overwritten on the stack this would allow some creative hacks around some of these problems but with classes and interfaces alone I can't justify the immense overhead that is associated with it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] operator overloading and counting references / creating / destoying anonymous instances
Am 29.07.2011 12:11, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd: I wonder if I could ask a silly question here, without displaying too much ignorance. I generally understand the significance of an interface in the Windows context, where COM (or whatever today's name for it) is integrated fairly deeply into the OS. But what of other OSes like Linux? Does the use of interfaces as a way of getting refcounted storage assume the presence of CORBA etc., and how much overhead is there at program startup- does it demand that an ORB be loaded into memory? While COM-interfaces in Delphi/FPC are designed to be Delphi compatible, they do not rely on COM. Basically a IInterface or IUnknown is simply an interface that contains calls for increasing/releasing a reference count. You as the implementor of the interface need to provide the implementation. So e.g. TInterfacedObject which implements IInterface implements a reference counting mechanism where the object is freed when the reference count reaches zero. In FPC/Delphi this reference count is normally controlled by the compiler by calling the methods of IUnknown, but in C/C++ these calls need to be done manually (AFAIK). CORBA-interfaces as implemented by FPC are just plain interfaces without any methods defined. Also the compiler does not generate code to influence the reference count as it does with COM-interfaces. Basically an interface in FPC/Delphi is something that allows you to use certain methods (those provided by the interface) without knowing what the implementing class does. The COM-interface just contain a bit more compiler magic, but that's it. So no, you don't need an ORB or something like that. Regards, Sven PS: There is also a third kind of interfaces called dispinterface that contain again more compiler magic and are indeed used with COM automation (or XPCOM on non-Windows). So if I understand you correctly, use of interfaces does not imply use of OS or ORB facilities, but can permit it if required. Simply spoken: yes (although I don't know of a CORBA ORB usage myself(!)) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
On Friday 29 July 2011 13:43:58 Bernd wrote: With interfaces and their reference counting it can be made to work but the cost of doing this seems so immense that I don't believe it is justifiable in many real world applications (at least not in my application). The performance penalty was the same reason why I abandoned the use of interfaces in the qt4 binding, just look at the way I used it in the qt2 binding: Though it was pretty nifty, people may not be aware of the performance cost of such albeit nice abstractions. http://qtforfpc.cvs.sourceforge.net/viewvc/qtforfpc/qte/demo/qteobjects.pas?revision=1.2view=markup ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
In our previous episode, Graeme Geldenhuys said: highlighting before, it's a nice challenge. It is rather a nightmare if you ask me... Definitely. There are so many things one takes for granted in a programming editor. A lot more work than I expected. [then again, what isn't] Hehe, Martin Friebe talked a bit about the Laz. editor the last devel meeting (and the one before). Definitely a place where I don't want to go :-) Don't forget to avoid artificial limits on length and width :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC 2.5.1 (trunk rev 18036): Can't find unit fastcgi used by custfcgi
Hi, I got an error trying to compile FPC 2.5.1 (trunk at revision: 18036) on WinXP-SP3. Before update, I ran 'make distclean'. Console output: [snip] Start building package fcl-web for target i386-win32. Compiling src\base\custfcgi.pp The installer encountered the following error: External command W:/md/dev/freepascal/compiler/2.5.1/compiler/ppc386.exe -Twin3 2 -FUunits\i386-win32 -FuW:\md\dev\freepascal\compiler\2.5.1\rtl\units\i386-win3 2 -FuW:\md\dev\freepascal\compiler\2.5.1\packages\fcl-base\units\i386-win32 -FuW :\md\dev\freepascal\compiler\2.5.1\packages\fcl-db\units\i386-win32 -FuW:\md\dev \freepascal\compiler\2.5.1\packages\fcl-xml\units\i386-win32 -FuW:\md\dev\freepa scal\compiler\2.5.1\packages\fcl-json\units\i386-win32 -FuW:\md\dev\freepascal\c ompiler\2.5.1\packages\fcl-net\units\i386-win32 -FuW:\md\dev\freepascal\compiler \2.5.1\packages\fcl-process\units\i386-win32 -FuW:\md\dev\freepascal\compiler\2. 5.1\packages\fastcgi\units\i386-win32 -FuW:\md\dev\freepascal\compiler\2.5.1\pac kages\httpd22\units\i386-win32 -Ur -Xs -O2 -n -FuW:/md/dev/freepascal/compiler/2 .5.1/rtl/units/i386-win32 -FuW:/md/dev/freepascal/compiler/2.5.1/packages/hash/u nits/i386-win32 -FuW:/md/dev/freepascal/compiler/2.5.1/packages/paszlib/units/i3 86-win32 -FuW:/md/dev/freepascal/compiler/2.5.1/packages/fcl-process/units/i386- win32 -FuW:/md/dev/freepascal/compiler/2.5.1/packages/fpmkunit/units/i386-win32 -FE. -FUunits/i386-win32 -di386 -dRELEASE -XX -CX src/base\custfcgi.pp failed w ith exit code 1. Console output: Target OS: Win32 for i386 Compiling src\base\custfcgi.pp PPU Loading W:\md\dev\freepascal\compiler\2.5.1\packages\fastcgi\units\i386-win3 2\fastcgi.ppu PPU Invalid Version 128 Fatal: Can't find unit fastcgi used by custfcgi Fatal: Compilation aborted make[3]: *** [smart] Error 1 make[3]: Leaving directory `W:/md/dev/freepascal/compiler/2.5.1/packages/fcl-web ' make[2]: *** [fcl-web_smart] Error 2 make[2]: Leaving directory `W:/md/dev/freepascal/compiler/2.5.1/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `W:/md/dev/freepascal/compiler/2.5.1' make: *** [build-stamp.i386-win32] Error 2 W:\md\dev\freepascal\compiler\2.5.1 Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.5.1 (trunk rev 18036): Can't find unit fastcgi used by custfcgi
In our previous episode, Marcos Douglas said: I got an error trying to compile FPC 2.5.1 (trunk at revision: 18036) on WinXP-SP3. Before update, I ran 'make distclean'. Compiling src\base\custfcgi.pp PPU Loading W:\md\dev\freepascal\compiler\2.5.1\packages\fastcgi\units\i386-win3 2\fastcgi.ppu PPU Invalid Version 128 Fatal: Can't find unit fastcgi used by custfcgi Fatal: Compilation aborted I also had this, and this fixed it for me, and for Paul on IRC 1) manually delete the .ppu's in packages that have this problem ( I ran del /s *.ppu and *.o in packages/) 2) delete all old fpmake.exe (del /s fpmake.exe in packages/) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.5.1 (trunk rev 18036): Can't find unit fastcgi used by custfcgi
On Fri, Jul 29, 2011 at 4:31 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: I got an error trying to compile FPC 2.5.1 (trunk at revision: 18036) on WinXP-SP3. Before update, I ran 'make distclean'. Compiling src\base\custfcgi.pp PPU Loading W:\md\dev\freepascal\compiler\2.5.1\packages\fastcgi\units\i386-win3 2\fastcgi.ppu PPU Invalid Version 128 Fatal: Can't find unit fastcgi used by custfcgi Fatal: Compilation aborted I also had this, and this fixed it for me, and for Paul on IRC 1) manually delete the .ppu's in packages that have this problem ( I ran del /s *.ppu and *.o in packages/) 2) delete all old fpmake.exe (del /s fpmake.exe in packages/) Ok, thanks, worked! But why this? In /branches/fixes_2_4 do not happens this error. BTW, updates for fixes_2_4 was stopped? Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.5.1 (trunk rev 18036): Can't find unit fastcgi used by custfcgi
In our previous episode, Marcos Douglas said: 1) manually delete the .ppu's in packages that have this problem ( I ran del /s *.ppu ?and *.o in packages/) 2) delete all old fpmake.exe ?(del /s fpmake.exe in packages/) Ok, thanks, worked! But why this? In some packages in 2.5.1, fpmake is being used on an experimental basis, to root out problems by use in practice. In /branches/fixes_2_4 do not happens this error. These experimental changes were of course not merged back to the stable branch 2.4.0 At this moment it is not decided yet if these will go in 2.6.0 BTW, updates for fixes_2_4 was stopped? 2.4.x receives some updates from time to time. Mostly fixes in packages/ This is mostly done to have a fallback if something goes wrong with the start of the 2.6.x release series that is being planned for the fall. If that goes reasonably well, there probably will be no more 2.4.x releases. Merging is getting harder and harder in 2.4.x, so mostly only packages that are wholly merged can be merged. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Timezone information in a dataset datetime field?- updated
I notify that synapse have some tools for timezone in synautil unit like:
{:Return your timezone bias from UTC time in minutes.}
function TimeZoneBias: integer;
{:Return your timezone bias from UTC time in string representation like
+0200.}
function TimeZone: string;
I don't know that they are cross platform. So they are some ways to get time
offset but anyone know how to get city? OS like ubuntu or windows ask user
for time zone in installation process, so it could be possible to get this
value by calling some enviromnent variable?
Regards
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.5.1 (trunk rev 18036): Can't find unit fastcgi used by custfcgi
On Fri, Jul 29, 2011 at 5:18 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: 1) manually delete the .ppu's in packages that have this problem ( I ran del /s *.ppu ?and *.o in packages/) 2) delete all old fpmake.exe ?(del /s fpmake.exe in packages/) Ok, thanks, worked! But why this? In some packages in 2.5.1, fpmake is being used on an experimental basis, to root out problems by use in practice. In /branches/fixes_2_4 do not happens this error. These experimental changes were of course not merged back to the stable branch 2.4.0 At this moment it is not decided yet if these will go in 2.6.0 BTW, updates for fixes_2_4 was stopped? 2.4.x receives some updates from time to time. Mostly fixes in packages/ This is mostly done to have a fallback if something goes wrong with the start of the 2.6.x release series that is being planned for the fall. If that goes reasonably well, there probably will be no more 2.4.x releases. Merging is getting harder and harder in 2.4.x, so mostly only packages that are wholly merged can be merged. OK, thanks for the explanation. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: operator overloading and counting references / creating / destoying anonymous instances
On Fri, Jul 29, 2011 at 7:31 AM, Henry Vermaak henry.verm...@gmail.com wrote: On 29/07/11 06:39, Jürgen Hestermann wrote: Bernd schrieb: Occasionally I hear other people mentioning operator overloading as a must-have feature of any decent language but I wonder what real-world problems they are actually solving with it. I think operator overloading is a pain. As you said: What is the advantage? For me operators should be defined by the language only It improves readability, making it more logical. Say for instance you are working on Galois fields and you have to do arithmetic on the elements like this: g1 + g2 / g3 If you don't have operator overloading, you have to do it with functions, like this: gf_add(g1, gf_div(g2, g3)) This is not very readable, I'm sure you will agree. They have to be used carefully, however. That's the problem, you always have to be very careful. They are easy to overlook in the code. You can circumvent type-checking. One more thing for the IDE to support (if it doesn't, you're royally screwed). At least in *Pascal strings are native types, so one less problem (and a big one in C++) to worry. clear. But now there is no way back. It's implemented. Pascal moves in C direction... Troll. C has no operator overloading. Henry Of course he meant C++. -Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fpGUI runs happily under OpenSolaris 2010.03
Graeme Geldenhuys wrote: Hi, After reading a post about another FPC developers trying to get a development system up and running under Solaris 10, I got curious. I downloaded OpenSolaris 2010.03 (dev 134). Installation was painless inside VirtualBox. Downloaded FPC's 2.4.4 release for Solaris. Installation was the easiest ever using that extra install script! [Yes even easier than under Linux or Windows] :) I then went ahead and installed git and GNU binutils packages, so I can get some source code and so that FPC can link executables. Again nothing difficult there. I pulled source code for fpGUI from the repository, and fired off the build.sh script. One minor compiler error that I quickly fixed. Reran the build script. Oh yeah!!! 2nd compile and it worked perfectly! :-D I went ahead and compiled a few more apps: The UIDesigner (fpGUI's visual form designer), fpgIDE (an example project resembling and IDE) and a few other example projects. They all worked without a hitch! Here are some screenshots. http://opensoft.homeip.net:8080/~graemeg/fpgui_on_solaris-1.png http://opensoft.homeip.net:8080/~graemeg/fpgui_on_solaris-2.png or if your ISP or company blocks DynDns domains... http://sourceforge.net/project/screenshots.php?group_id=182330 That means fpGUI Toolkit now runs under the following platforms: - Linux - FreeBSD - DesktopBSD - OpenSolaris - Embedded Linux - Windows - Windows CE. - Mac OSX 10.6.x (via the built-in X11 support) Kudos to the Free Pascal Compiler team for doing a great job once again. FPC rocks! Well done and thanks for testing. If you have any thoughts please could you append them to the wiki page http://wiki.lazarus.freepascal.org/Lazarus_on_Solaris since this also deals with FPC as a prerequisite. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
