Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types
2015-03-17 23:35 GMT+01:00 Sven Barth pascaldra...@googlemail.com: I won't commit it as long as I haven't made sure that it doesn't rely on any implementation details. And that needs time... IMO the most important to fix is: http://bugs.freepascal.org/view.php?id=24848 http://bugs.freepascal.org/view.php?id=25607 Regards Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types
Am 18.03.2015 11:52 schrieb Maciej Izak hnb.c...@gmail.com: 2015-03-17 23:35 GMT+01:00 Sven Barth pascaldra...@googlemail.com: I won't commit it as long as I haven't made sure that it doesn't rely on any implementation details. And that needs time... IMO the most important to fix is: http://bugs.freepascal.org/view.php?id=24848 http://bugs.freepascal.org/view.php?id=25607 That's not what I meant... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Mode Delphi and functions as parameters.
I have recently compiled projects which were converted from Delphi and it seems to me that the passing a function as a parameter does not require the '@' symbol. I suspect syntax errors came because I wasn't compiling from the command line. e.g function AFunction() begin end; CallFunctionWithFunctionParameter (AFunction) instead of CallFunctionWithFunctionParameter (@AFunction) Is passing a function as parameter without the '@' symbol accepted in Delphi? -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] PtrInt - possible candidate to be marked as deprecated
Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
Hmmm, PtrInt is used in that very useful method TApplication.QueueAsync Call. Could cause a lot of problems in Lazarus apps if it was removed now - or at least without a lot of planning and warning. http://lazarus-ccr.sourceforge.net/docs/lcl/forms/tapplication.queueasynccall.html On 18/03/15 14:53, Graeme Geldenhuys wrote: Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On 2015-03-18 15:01, Mattias Gaertner wrote: TList stores arbitrary Pointers. To store an arbitrary integer you cast it with PtrInt. Is there an integer list? Generics? [warning: I know nothing about generics] Good point either way - thanks for the example. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On Wed, 18 Mar 2015, Nikolay Nikolov wrote: On 18.3.2015 г. 16:53, Graeme Geldenhuys wrote: Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html I don't think it should be removed. It's more of a if you use it, you must know what you're doing type of thing IMO. It's useful for e.g. obtaining the result of a pointer difference or storing a signed offset relative to a memory address. Indeed. I didn't add this sentences in the docs, and I will remove them, and replace them with with a warning as suggested. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On Wed, 18 Mar 2015 14:53:50 + Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html PtrInt is sometimes used in this case: TList stores arbitrary Pointers. To store an arbitrary integer you cast it with PtrInt. Is there an integer list? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On 18.3.2015 г. 16:53, Graeme Geldenhuys wrote: Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html I don't think it should be removed. It's more of a if you use it, you must know what you're doing type of thing IMO. It's useful for e.g. obtaining the result of a pointer difference or storing a signed offset relative to a memory address. Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Mode Delphi and functions as parameters.
On Wed, 18 Mar 2015, vfclists . wrote: I have recently compiled projects which were converted from Delphi and it seems to me that the passing a function as a parameter does not require the '@' symbol. I suspect syntax errors came because I wasn't compiling from the command line. e.g function AFunction() begin end; CallFunctionWithFunctionParameter (AFunction) instead of CallFunctionWithFunctionParameter (@AFunction) Is passing a function as parameter without the '@' symbol accepted in Delphi? If you use Delphi mode: yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On 2015-03-18 15:38, Tony Whyman wrote: problem is not whether or not the parameter should be PtrInt or PtrUint, it is currently PtrInt and changing it means a lot of work for any application that uses it. If the data you pass in is always positive pointer addresses (I would assume this being the norm), then the change will not break any existing code. But my assumptions have been wrong before. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
Mattias Gaertner wrote on Wed, 18 Mar 2015: On Wed, 18 Mar 2015 14:53:50 + Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: Based on what the documentation says introduction of ptrint type was a mistake, shouldn't the PtrInt type be marked as deprecated in FPC 3.0.0 and removed in a later release like 3.0.2 or 3.2.0? http://www.freepascal.org/docs-html/rtl/system/ptrint.html PtrInt is sometimes used in this case: TList stores arbitrary Pointers. To store an arbitrary integer you cast it with PtrInt. Or PtrUInt. The remark in the docs (which I didn't add, for the record) is specifically about the signed variant. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On Wed, 18 Mar 2015 15:29:14 + Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: On 2015-03-18 15:23, Tony Whyman wrote: PtrInt is used in that very useful method TApplication.QueueAsync Call. Though I never used the QueueAsync() call myself, but looking at the declaration, shouldn't that data type be PtrUInt anyway? As far as I understand Data points to data in memory, which will always be an positive (unsigned) value, not so? It is arbitrary Data. The passed method already contains an Object (data in memory). The Data is usually used as a state or index within the object. But it can also contain a pointer. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
QueueAsyncCall takes two arguments - a pointer to a method and data. The method declaration must be of the type: TDataEvent = procedure (Data: PtrInt) of object; My apps have loads of methods defined as above and would certainly fail to compile if the PtrInt type was replaced with Ptruint. At the minimum it would require a search and check through all source code to make sure that the signed type was not significant followed by a sed script to effect the change. Just for interest, I did a find and grep on the lazarus LCL directory (.pas, .pp and .inc) files and found 837 lines on which PtrInt was present. The lazarus components directory has 474 instances. On 18/03/15 16:00, Graeme Geldenhuys wrote: On 2015-03-18 15:38, Tony Whyman wrote: problem is not whether or not the parameter should be PtrInt or PtrUint, it is currently PtrInt and changing it means a lot of work for any application that uses it. If the data you pass in is always positive pointer addresses (I would assume this being the norm), then the change will not break any existing code. But my assumptions have been wrong before. ;-) Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
On 2015-03-18 15:23, Tony Whyman wrote: PtrInt is used in that very useful method TApplication.QueueAsync Call. Though I never used the QueueAsync() call myself, but looking at the declaration, shouldn't that data type be PtrUInt anyway? As far as I understand Data points to data in memory, which will always be an positive (unsigned) value, not so? Or does Mattias's example apply here too. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PtrInt - possible candidate to be marked as deprecated
It's one I tend to use a lot as it's a nice platform independent way scheduling processing in the next cycle round the message loop. The problem is not whether or not the parameter should be PtrInt or PtrUint, it is currently PtrInt and changing it means a lot of work for any application that uses it. If this were the only instance then maybe the work could be justified - but PtrInt is used in about a dozen other places in the Forms module alone and throughout the LCL and FCL. For example: TDataLink.DataEvent(Event: TDataEvent; Info: Ptrint) in the DB Module. I can understand the argument that says it was a bad idea in the first place - but all the work and instability to get rid of it Let sleeping PtrInt's lie to paraphrase an old saying. On 18/03/15 15:29, Graeme Geldenhuys wrote: On 2015-03-18 15:23, Tony Whyman wrote: PtrInt is used in that very useful method TApplication.QueueAsync Call. Though I never used the QueueAsync() call myself, but looking at the declaration, shouldn't that data type be PtrUInt anyway? As far as I understand Data points to data in memory, which will always be an positive (unsigned) value, not so? Or does Mattias's example apply here too. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPCUnit - parallel test suite execution
As per good unit test guidelines, tests should be independent of each other and not rely on results from earlier tests. The perfect candidate for parallelism. So what about the idea of running x amount of test suites in parallel? It should at least give our multi-core CPU's something to do and maybe complete 2000+ tests in a shorter period. ;-) Thoughts? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types
https://github.com/dathox/generics.collections Thanks. Git makes life easier. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Thoughts on Shell Approach to TCP Sockets
On 03/18/2015 06:57 PM, Coyo Stormcaller wrote: Despite documentation and manuals, I have not figured out how to use TCP sockets in Object Pascal, since there doesn't seem to be a primitive for it, or any easy way to instantiate sockets and manipulate incoming connections. There is source code for a simple serial and TCP/IP example here: http://ctrlterm.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Thoughts on Shell Approach to TCP Sockets
Despite documentation and manuals, I have not figured out how to use TCP sockets in Object Pascal, since there doesn't seem to be a primitive for it, or any easy way to instantiate sockets and manipulate incoming connections. So my approach to sockets is to do it externally. A Bash shell script invokes another script, such as Ruby for binding the socket. Upon recieving a socket connection, it invokes an Object Pascal command line program, passing it socket traffic as standard input. Another similar approach is to pre-parse serialized socket objects and then re-serialize them in a processed form, for the Object Pascal program to further process and manipulate from standard input. If I knew how to do more of this with pure Object Pascal, I'd do it that way. But as it is, I'm thinking breaking up the program into components in a bunch of different languages. The way it's designed right now, a Bash Shell script is invoked by /etc/init.d to manage the program, including re-binding to the socket, rehashing, etc. A cron job periodically re-calls the program so that time-related functions can be invoked. this lets me get away with not using a core while-true loop. all components execute as a script and then exit until the next time the main Bash Shell script is invoked. The /etc/init.d script is treated as an initializer, and is used to manage it, but really the main Bash Shell script in cron is what does the lion's share. A few of the persistent scripts are those that handle things like sockets and long-lived connections between components. At the moment, all objects are stored on file in flat-file format, and serialized as an IRC-like text-line object notation, but I want to eventually switch to using MsgPack, ProtoBuf and SQLite for serialization and object storage, and libpurple for the many protocols libpurple supports. The name of the application in question is named Tanis. Tanis is an automated personal assistant, or pseudo-AI. It does various things. At the moment, all it is is a protocol-agnostic bot that can retrieve weather, greet people with a random quote, and various IRC bot functions. It can also control chat management and such. I'm working on an email management console, and from there a Usenet interface. It's going smoothly enough, I suppose. However, I really like Object Pascal, and the more I can do with it, and Common Lisp for the learning portions, the better. I'd prefer for the sockets to be handled by Object Pascal, but I do not know how to do this. I'm not very good at using other peoples' code and libraries in general, so I tend to focus on either well-documented standard libraries that are easy to access and use, or using purely my own code. I'm fairly proficient with Bash Shell, and I like Regular Expressions, and am fairly conversant with Extended Regular Expressions, so I tend to focus on using Bash Shell scripts as much as seems reasonable, while invoking other program components from within Bash while the Bash Shell script executes. There are three different Bash Shell scripts. One is an infinite loop, which can be started and stopped with /etc/init.d commands Anyway, thank you for your time and patience. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit - parallel test suite execution
So what about the idea of running x amount of test suites in parallel? It should at least give our multi-core CPU's something to do and maybe complete 2000+ tests in a shorter period. ;-) Thoughts? I haven't got as many tests as that yet, but surely a parallel execution will make a good use of my multicore processor. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/FPCUnit-parallel-test-suite-execution-tp5721391p5721396.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit - parallel test suite execution
On Wed, Mar 18, 2015 at 2:04 PM, Graeme Geldenhuys mailingli...@geldenhuys.co.uk wrote: As per good unit test guidelines, tests should be independent of each other and not rely on results from earlier tests. The perfect candidate for parallelism. So what about the idea of running x amount of test suites in parallel? It should at least give our multi-core CPU's something to do and maybe complete 2000+ tests in a shorter period. ;-) Thoughts? Maybe a new class named TTestCaseAsync, ie, all test cases that inherit it will run in parallel. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Saving and reading TBlowfish crypted text
On 17 Mar 2015, at 22:32, Graeme Geldenhuys wrote: On 2015-03-17 18:49, Ewald wrote: The docs state that it is called automatically upon destruction: Correct, and I knew that. But I was explicitly looking at the code Antonio supplied. [...] This is my interpretation of what is going on with the code I have seen (I haven't actually tried to compiler and run that code). If I am wrong, feel free to correct me. No, you are quite correct. I should've looked more closely to the code supplied (the 2-letter variable names must have confused me I suppose). Sorry for the noise. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit - parallel test suite execution
On Wed, 18 Mar 2015, Graeme Geldenhuys wrote: As per good unit test guidelines, tests should be independent of each other and not rely on results from earlier tests. The perfect candidate for parallelism. So what about the idea of running x amount of test suites in parallel? It should at least give our multi-core CPU's something to do and maybe complete 2000+ tests in a shorter period. ;-) Thoughts? In theory, I am not against. But: Not all tests can be run in parallel. DB code is for instance not thread safe. Then: Given the nature of decorators, it will require extensive checking to make sure that tests that rely on the same decorator will be run in the same thread anyway. Just some random thoughts. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
