[fpc-pascal] Delphi compiler team left Embarcadero/Idera
Looks like the last one senior compiler guy has gone - Allen Bauer (like Eli Boling before). He is starting a new position at Google: http://blog.therealoracleatdelphi.com/2016/02/a-new-adventure.html Interesting info: [quote author="Ralf Stocker"] How safe is Delphis future? Who is the new Lead Compiler Engineer? Who is the new Chief Scientist? [/quote] [quote author="Allen Bauer"] There are no plans that I'm aware of to move someone into my old position... All those that I would consider qualified are either already gone or are currently looking elsewhere. [/quote] Source: https://plus.google.com/104660942073125276831/posts/AuEUb95pUZu Related initiative "Lets buy Delphi": https://plus.google.com/115032677792043930563/posts/Tc4s6jCLEos IMO Interesting and sad time for whole community. -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
Hey Michalis, thanks for your detailed answers I really appreciate it. > In Castle Game Engine the whole Pascal code is compiled into an .so > library (for Android+Arm, though we could also target Android+x86). It > is then packaged into an apk, with the activity class set to the > "NativeActivity" Java class. I see you made a builder tool I’ll have to check out. From the Android tutorials I’ve seen building Android packages seems be pretty forward. You can run/install apps from the terminal also I think based on your documents. That’d be nice to not be in Android Studio if I don’t have to be. It looks like the majority of the startup code is in castlewindow_android but I was expected to see an OpenGL context (surface view I think in Android). How do you render OpenGL then? >> >> 1) All the file I/O in the FPC RTL is not available so what possible work >> arounds are there for loading data from files? > The important thing is that your program data (what you put in apk) is > *not* stored on disk as normal files. You need to use AssetManager to > read it. With some helpers, you can just open an "asset file" as a > Pascal TStream, and then read from there. In CGE, you just use URL > like "assets:/some_subdirectory/blahblah.png", pass it to any > file-reading function and it will read the file > "some_subdirectory/blahblah.png" from your data. More info on > http://castle-engine.sourceforge.net/tutorial_network.php . Yeah I see there’s a CastleAndroidAssetManager unit which does this. So UNIX I/O “works” but you can’t read anything without the asset manager? That doesn’t really make sense but either way using the Asset manager in a stream like you did is just fine. I only need to read the contents of images and XML files anyways. I was using ReadXMLFile to read the XML file but I assume this is just a helper function that wraps something lower level I could use in conjunction with the asset manager. Is that correct? Can’t find your code for this. > >> >> 2) OpenGL functions are not available so how can I call into the Android >> library? Callback wrappers perhaps? > > You use OpenGL ES for rendering (version 2 or 3, for modern devices). > Pascal bindings are available already in FPC, see unit GLES20. Of > course engines like CGE give you more comfortable API for rendering, > on top of this. So internally Android just uses the same C libraries we were using in Pascal? I guess that makes sense but I was thinking EVERYTHING on the system was now Java but that’s not the case I guess. The lesson here is that Android is built on Linux so we’re sharing more than I think. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Variable Initialization Questions
2016-02-18 18:38 GMT-02:00 Jonas Maebe : > Mazola Winstrol wrote: > >> Just to clarify: if i have a record type with a pointer field, this >> field will always zeroed? >> > > No. As mentioned, all global variables are always zeroed. The type doesn't > matter. Local variables are never zeroed, except if they are managed types. > A pointer is not a managed type. > > > May i add a remark about the behavior of managed types in the documentation? http://www.freepascal.org/docs-html/current/ref/refse23.html#x55-730004.4 Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
2016-02-21 23:00 GMT+01:00 Sven Barth : > Am 21.02.2016 19:36 schrieb "Michalis Kamburelis" > : >> > >> > 1) All the file I/O in the FPC RTL is not available so what possible >> > work arounds are there for loading data from files? >> >> Actually, all the IO in FPC works perfectly. You can read / write >> files just like on any other Unix (although you need to declare >> appropriate permissions in the AndroidManifest.xml first --- >> READ_EXTERNAL_STORAGE , WRITE_EXTERNAL_STORAGE, otherwise access to >> "/sdcard/..." files will be restricted). For example, config files are >> just normal files on Android. You only use a special function to get >> the proper config file location, but this is done for you by CGE, you >> just use CastleFilesUtils.ApplicationConfig:) > > I think he means on FPC's JVM target. There file I/O using Write/Read is > indeed not implemented. > Oh, OK. My comments were indeed about the native target (Android+Arm communicating through JNI), not JVM. Well, at least I can confirm that I/O works cool there:) Regards, Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
Am 21.02.2016 19:36 schrieb "Michalis Kamburelis" : > > > > 1) All the file I/O in the FPC RTL is not available so what possible work arounds are there for loading data from files? > > Actually, all the IO in FPC works perfectly. You can read / write > files just like on any other Unix (although you need to declare > appropriate permissions in the AndroidManifest.xml first --- > READ_EXTERNAL_STORAGE , WRITE_EXTERNAL_STORAGE, otherwise access to > "/sdcard/..." files will be restricted). For example, config files are > just normal files on Android. You only use a special function to get > the proper config file location, but this is done for you by CGE, you > just use CastleFilesUtils.ApplicationConfig:) I think he means on FPC's JVM target. There file I/O using Write/Read is indeed not implemented. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
2016-02-21 4:36 GMT+01:00 Ryan Joseph : > I’m going to attempt to port a game to Android but I have some questions > about potential problems. Now at least I think building a library and loading > using the JNI would be best but using the JVM could be helpful also (the > entire project couldn’t be compiled though). Not sure which way is best or if > they can be mixed perhaps. In Castle Game Engine the whole Pascal code is compiled into an .so library (for Android+Arm, though we could also target Android+x86). It is then packaged into an apk, with the activity class set to the "NativeActivity" Java class. You can communicate with the Java code using JNI. In the base version, the NativeActivity (part of Android since Android 2.3) already does a lot for you, and you don't even need to touch the "Java side". For more complicated stuff, you need to write some Java code, and communicate with it using JNI. Of course if you use an engine like Castle Game Engine, you get a lot of help with this:) --- most things are already implemented for you, and for adding your own Java extensions we have CastleMessaginig unit and a "component" system for Android projects, https://github.com/castle-engine/castle-engine/wiki/Android-Project-Components-Integrated-with-Castle-Game-Engine . See http://castle-engine.sourceforge.net/engine.php and download the engine and try it:) You can use the stable release 5.2.0, or the (soon to be released as 5.3.0) version from GitHub on https://github.com/castle-engine/castle-engine . We have a lot of documentation, some Android/mobile specific stuff: - http://castle-engine.sourceforge.net/tutorial_mobile.php (tutorial showing how to write cross-platform game code using CGE --- for standalone, Android, iOS, web browser plugin...) - https://github.com/castle-engine/castle-engine/wiki/Android - how to install Android development environment - https://github.com/castle-engine/castle-engine/wiki/Android-Project-Components-Integrated-with-Castle-Game-Engine - extra Android components, e.g. for in-app purchases or analytics. > > 1) All the file I/O in the FPC RTL is not available so what possible work > arounds are there for loading data from files? Actually, all the IO in FPC works perfectly. You can read / write files just like on any other Unix (although you need to declare appropriate permissions in the AndroidManifest.xml first --- READ_EXTERNAL_STORAGE , WRITE_EXTERNAL_STORAGE, otherwise access to "/sdcard/..." files will be restricted). For example, config files are just normal files on Android. You only use a special function to get the proper config file location, but this is done for you by CGE, you just use CastleFilesUtils.ApplicationConfig:) The important thing is that your program data (what you put in apk) is *not* stored on disk as normal files. You need to use AssetManager to read it. With some helpers, you can just open an "asset file" as a Pascal TStream, and then read from there. In CGE, you just use URL like "assets:/some_subdirectory/blahblah.png", pass it to any file-reading function and it will read the file "some_subdirectory/blahblah.png" from your data. More info on http://castle-engine.sourceforge.net/tutorial_network.php . > > 2) OpenGL functions are not available so how can I call into the Android > library? Callback wrappers perhaps? You use OpenGL ES for rendering (version 2 or 3, for modern devices). Pascal bindings are available already in FPC, see unit GLES20. Of course engines like CGE give you more comfortable API for rendering, on top of this. > > 3) I use ReadXMLFile from XMLRead but that uses file loading internally so is > there anyway to load XML on Android? As said above --- you can still use these functions to read / write regular files on Android. To read XML in your apk data, you need to get a TStream from AssetManager, and read / write XML using this stream. This works perfectly:) We use XML files in CGE a lot, and we have helpers like URLReadXML that reads TXMLDocument from an URL, and URL can be "file:/..." or "assets:/..." (or even http or others, see the mentioned tutorial about networking:) Regards, Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Wiki upgraded
On Sat, Feb 20, 2016 at 5:50 PM, Jonas Maebe wrote: > The wiki has been upgraded to MediaWiki 1.23 Great! thank you! Is it possible to enable Subpages ? ( https://www.mediawiki.org/wiki/Help:Subpages) Purpose - hierarchical organization of the knowledge base. For example, all the pages of the book ( http://wiki.lazarus.freepascal.org/Object_Pascal_Tutorial) would be better to implement as sub pages, rather than within the global wiki name scope. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
Good idea, thanks. > On Feb 21, 2016, at 9:08 PM, leledumbo wrote: > > Learn how Castle Game Engine and ZenGL managed to do it. They don't use JVM, > but the ARM target of the compiler. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android porting ideas
> Any ideas? Learn how Castle Game Engine and ZenGL managed to do it. They don't use JVM, but the ARM target of the compiler. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Android-porting-ideas-tp5724239p5724243.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] Wiki upgraded
Martin wrote: all images missing http://wiki.lazarus.freepascal.org/New_IDE_features_since Should be fixed, thanks. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Primitive Record Wrappers
Am 21.02.2016 03:02 schrieb "Mazola Winstrol" : > > 2016-02-20 3:24 GMT-02:00 Michalis Kamburelis : >> >> The major problem there is that it's difficult to force it to be >> always initialized with zeroes. Currently, a non-global variable of >> unmanaged type can always be filled with memory garbage, as explained >> in other thread. The trick in >> http://blogs.embarcadero.com/abauer/2008/09/18/38869 to use interfaces >> feels ugly, it's an over-use of the "interface" specifics in Object >> Pascal. >> > > A less "ugly" code could be to store the pointer value in an array of bytes (TBytes). As the TBytes type is a managed type, it will always be initialized. The managed type isn't needed for the data (that should be stored as a plain field to let the compiler take care of finalization), but instead it's needed to store whether the field contains a valid value (not Null) or not (null). For this potentially any managed type (array, string, interface) can be used, but it might indeed be that the manual interface approach is the fastest, because there one can avoid unnecessary locking (it's done by the implementations of AddRef and Release) which is not the case with arrays and strings as the reference counting routines always do locking. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
