Re: [fpc-pascal] cocoa programming without objective-pascal mode
On Mon, Nov 3, 2014 at 11:00 AM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: Just don't bother yourself with cocoa api don't go too specific. I don't, hence this thread. :) If want to use a TObject, I want the exact same properties, exact same behavior, exact same declaration of TObject on everywhere else. At least, 90% of them, with 10% is special particularly to where TObject platform is defined. I don't care if beneath it acts as NSObject on OSX, or WinObject on Windows, or QTObject on QT, or whatever. On Mon, Nov 3, 2014 at 1:45 PM, Sven Barth pascaldra...@googlemail.com wrote: That's because FireMonkey abstracts all those APIs for you. The LCL by Lazarus has the same target: no matter whether you are on Win32/64, GTK, Qt, Carbon, Cocoa, whatever you get the same set of APIs (the API provided by the LCL) and you don't (normally; bugs not withstanding) need to care about platform differences. FireMonkey isn't native UI. It's custom drawn UI controls (based on OpenGL?). That's why I left Delphi. I don't like non-native UI, except for games. Even if you'd directly access Cocoa using Object Pascal means you would not be compatible with Object Pascal codes on other platforms. The same is true for Delphi by the way. They interface with Cocoa code using COM interfaces which are not used on the Windows platform (for this purpose). Two different API sets! Why would that be? A pascal TStringList can be a NSStringArray on Cocoa, or regular list of strings on Windows. I don't care as long as my pascal TStringList behaves consistently on any platforms. What I do care is if I can use TStringList on Windows, but I'm forced to use NSStringList on OSX for the same purpose and function. I don't want that. That's why I don't like objective-pascal dialect. *btw, the class names are just pseudo class, you should get the point* :) Also using Objective Pascal does in no way mean that you can not use Object Pascal. You can mix them as you want and you can use Objective Pascal classes in Object Pascal code and vice versa (otherwise this feature would be rather useless). Oh, really? I didn't know that. So, I could use objective-pascal mode on Windows too? Including its protocol and messaging mechanism? So please use Objective Pascal. It will save you from quite some trouble to implement the APIs manually (afterall there is a reason why we implemented Objective Pascal). Of course there is a reason for objective pascal existence. But should I use it? I don't know. Unless you can give me guarantee that objective-pascal dialect can be used on Windows and Linux as well. But if it does, why do we bother to have objective pascal at the first place? :D FYI, just as food for thought... I'm now considering to use RemObject's Oxygene (another pascal variant) as it behaves almost like the way I want. I could use the same consistent syntax on any platforms. Although I have to know special cases where API on particular OS is very much different from other OSes. But it's pretty rare cases. If you want to know the concept of the language, please refer to this site: http://www.elementswiki.com/en/Oxygene_Language But honestly, I'd love to use FreePascal. :) Regards, -- -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cocoa programming without objective-pascal mode
On 03/11/14 09:02, Bee wrote: If want to use a TObject, I want the exact same properties, exact same behavior, exact same declaration of TObject on everywhere else. Then you are in luck, because that is exactly how it is today. (*) I don't care if beneath it acts as NSObject on OSX, or WinObject on Windows, or QTObject on QT, or whatever. It will never act like any of those, beneath or otherwise. As other people have said, use Lazarus if you want to abstract away the APIs of GUI frameworks. If you want to directly program using Cocoa, Qt, KDE, Win32, NativeNT or Metro, then you won't ever be able to directly pass a TStringList to an API call in FPC on any platform. Or... use RemObject's Oxygene It doesn't do everything you summed up in your mail either, but it's possible that it does offer transparent bridging in the specific case of Objective-C classes (or at least for supported Cocoa classes) and e.g. COM objects. I doubt you'll be able to directly pass Oxygene classes to Qt API calls though. Jonas (*) except on the JVM platform, where it is not technically possible to declare your own class hierarchy. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
My results : _Ptr:=GetMem(1)18 mus, 824 ns / GetMem _Ptr:=GetMem(1) + FillChar(_Ptr^,1,0)); 81 ms / GetMem + FillChar var ArInt:array of int32; . SetLength(ArInt, 1 shr 2); 81 ms / SetLength All timings are variable within [time, time+8%] on repeated runs as is generally the case for system timings. SetLength 0's (Internally calls FillChar) the array ArInt so to do a identical comparison you need to add the FillChar to the GetMem if it is your intention to 0 the array before using it. You have to compare things that do the same thing in the end. Tested on XP Pro Win32 Sp3 Intel Core 2CPU 6400 #@ 2.13GHz 2.05 GHr., 1.00 Gb RAM ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cocoa programming without objective-pascal mode
Am 03.11.2014 09:02 schrieb Bee bee.ogra...@gmail.com: On Mon, Nov 3, 2014 at 1:45 PM, Sven Barth pascaldra...@googlemail.com wrote: That's because FireMonkey abstracts all those APIs for you. The LCL by Lazarus has the same target: no matter whether you are on Win32/64, GTK, Qt, Carbon, Cocoa, whatever you get the same set of APIs (the API provided by the LCL) and you don't (normally; bugs not withstanding) need to care about platform differences. FireMonkey isn't native UI. It's custom drawn UI controls (based on OpenGL?). That's why I left Delphi. I don't like non-native UI, except for games. The non-native UI aspect isn't what's the point here. It uses nevertheless the native API (WinAPI on Windows, Cocoa on Mac OS X, etc.) and presents you with an abstract API that allows you to use the same code (more or less) on all supported platforms. It's the same for the LCL, but here with native controls (mostly). Even if you'd directly access Cocoa using Object Pascal means you would not be compatible with Object Pascal codes on other platforms. The same is true for Delphi by the way. They interface with Cocoa code using COM interfaces which are not used on the Windows platform (for this purpose). Two different API sets! Why would that be? A pascal TStringList can be a NSStringArray on Cocoa, or regular list of strings on Windows. I don't care as long as my pascal TStringList behaves consistently on any platforms. What I do care is if I can use TStringList on Windows, but I'm forced to use NSStringList on OSX for the same purpose and function. I don't want that. That's why I don't like objective-pascal dialect. *btw, the class names are just pseudo class, you should get the point* :) No, a TStringList can't be a NSStringArray, because they have different functionality. The same is true for whatever other platform specific class or functionality you pick. And somewhere there must be tee abstraction if one wants to share code. In case of Objective Pascal you need to have Object Pascal code that uses the Objective Pascal classes. Also using Objective Pascal does in no way mean that you can not use Object Pascal. You can mix them as you want and you can use Objective Pascal classes in Object Pascal code and vice versa (otherwise this feature would be rather useless). Oh, really? I didn't know that. So, I could use objective-pascal mode on Windows too? Including its protocol and messaging mechanism? In theory it would be possible, because there exists a criss platform port of the Objective C runtime, but that is currently not supported, because noone had the need for it yet. But that's not what I meant. The point is: on Mac OS X the classes provided by Objective Pascal are the system API, on Windows it's the WinAPI. They are different API and it's not the compiler's job to abstract this, but of the runtime library (for low-level functionality) or the GUI library (in our case LCL or fpGui). If you access the Objective C API manually you are basically interfacing a C API which you wrap using Object Pascal objects. So why not instead have these Object Pascal classes wrap the Objective Pascal classes? Because then you don't have to worry to correctly interface with the Objective C runtime, because the compiler does the job for you. Otherwise you need to do all this manually which is error prone. So please use Objective Pascal. It will save you from quite some trouble to implement the APIs manually (afterall there is a reason why we implemented Objective Pascal). Of course there is a reason for objective pascal existence. But should I use it? I don't know. Unless you can give me guarantee that objective-pascal dialect can be used on Windows and Linux as well. But if it does, why do we bother to have objective pascal at the first place? :D I'm not giving you a guarantee, because that's not the purpose of the Objective Pascal dialect. It's purpose is to efficiently interface with Mac OS X's API like Delphi Interfaces were originally to efficiently interface with COM classes on Windows. FYI, just as food for thought... I'm now considering to use RemObject's Oxygene (another pascal variant) as it behaves almost like the way I want. I could use the same consistent syntax on any platforms. Although I have to know special cases where API on particular OS is very much different from other OSes. But it's pretty rare cases. If you want to know the concept of the language, please refer to this site: http://www.elementswiki.com/en/Oxygene_Language You may have the same language, but you nevertheless need to write different code, because .Net, Objective C and Java all have different restrictions and the base types are named differently. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
Am 03.11.2014 08:32 schrieb Nico Erfurth n...@erfurth.eu: On 02.11.14 15:05, Xiangrong Fang wrote: Sorry, the results in previous mail was mis-labeled. The result is: Using SetLength: Alloc: 9.40781697E-0001 Clear: 2.13420202E-0001 Using GetMemory: Alloc: 2.8100E-0005 Clear: 7.74975504E-0001 SetLength will already clear the array before returning it, so the time for SetLength is approximate time(GetMem) + time(Clear). Ah, right. I forgot that :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cocoa programming without objective-pascal mode
Alright, guys. Thank you for all the informations and discussion. I got many things to learn from all of your responses. They're all valuable to me. I haven't yet decided which way I will choose, whether to stay with FPC, move to Oxygene, or completely migrate to Swift. I'm still on testing phase right now before jump into Apple platform next year. Wish me luck! :) -- -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
Xiangrong Fang wrote: Hi All, I am programming a Bloom Filter and need a high-performance way to On what platform are you doing this ? Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] cocoa programming without objective-pascal mode
On 02/11/14 18:38, Felipe Monteiro de Carvalho wrote: The Cocoa interface is advancing fast. I am even running out of known bugs, so other people testing would be appreciated. I have some interest in this. Is http://wiki.lazarus.freepascal.org/Cocoa_Interface reasonably up to date as to how to use it (assuming trunk lazarus + fpc)? http://wiki.lazarus.freepascal.org/Roadmap#Status_of_features_on_each_widgetset suggests lots of stuff not implemented - should more of this be yellow/green? Colin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
2014-11-03 23:40 GMT+08:00 Adriaan van Os f...@microbizz.nl: Xiangrong Fang wrote: Hi All, I am programming a Bloom Filter and need a high-performance way to On what platform are you doing this ? I am programming on Linux, but it will be used on both Windows and Linux, Windows is the primary target. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
Hi, Hi All, I am programming a Bloom Filter and need a high-performance way to On what platform are you doing this ? I am programming on Linux, but it will be used on both Windows and Linux, Windows is the primary target. Well, the first thing you should ask yourself is Do I REALLY need such a large bloom filter. Everything larger than the last level cache will seriously harm your performance as you are going to trigger a lot of cache and TLB misses. In general you should target for typical L1-Cache sizes (16-32KByte) or if REALLY necessary L2-Cache-sizes (256KByte-32MByte). Everything above that will make the performance go down rapidly, especially in hashing-application the CPU can't prefetch data properly as the access-patterns are erratic. Nico ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Effective memory allocation
2014-11-04 6:35 GMT+08:00 Nico Erfurth n...@erfurth.eu: Well, the first thing you should ask yourself is Do I REALLY need such a large bloom filter. Everything larger than the last level cache will seriously harm your performance as you are going to trigger a lot of cache and TLB misses. In general you should target for typical L1-Cache sizes (16-32KByte) or if REALLY necessary L2-Cache-sizes (256KByte-32MByte). Everything above that will make the performance go down rapidly, especially in hashing-application the CPU can't prefetch data properly as the access-patterns are erratic. I didn't think of things like cache and TLB misses. Because I try to use BloomFilter and HASH to avoid repeated calculation and/or lookups which are time consuming. So, I don't think it will harm performance, unless bloom filter lookup is slower than the calculation, am I right? Thanks! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
