The Cloud is everywhere these days. And lots of companies offer Cloud products or services. Why should you use them?
Comments closedXojo Programming Blog Posts
Starting with Xojo 2018r1, your Xojo apps require the libunwind8 library to be installed on your Raspberry Pi. Here’s how to update your Pi.
Comments closedXojo 2018 Release 1 has a new feature for Xojo Cloud users: Xojo Cloud Server Stats.
Comments closedHere are some tips that will help ensure your Windows apps look and feel their best, with Xojo 2018 Release 1 now that Windows apps now have a more stable and flicker-free UI than ever before.
1 CommentYou can call into Linux APIs to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use using Linux documentation.
Comments closedYou can call into Cocoa Touch APIs to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use in Apple’s documentation: Apple Developer Documentation. Most of the time you will reference the Foundation and UIKit libraries, but there are many other libraries as well. Xojo Declares use the Objective-C names so be sure to refer to those in the documentation rather than the Swift naming.
Comments closedA topic that comes up every once in a while on the forums is how to share code among several projects with more than one developer. Quite often what users try to do is to export classes and modules to a shared folder and have everyone include those in their projects. There can be issues with this technique, especially when using shared services like DropBox.
Because of the latency involved, external items shared in a shared folder on a server or a file sharing service are never truly in-sync with one another. While this technique works with a single developer across two or three projects, it gets more and more complicated as you add more projects and even more-so if you try to add more developers.
One of the largest issues with this type of system is that everything must be kept in sync all the time. Making one little change to a shared file or method which works fine in the current project could completely break a project that you haven’t worked on in a year. When you do get around to working on it again, there’s three possibilities:
- The project compiles and everything works just like it did before.
- The project doesn’t compile.
- The project compiles and doesn’t work like it did before.
With careful planning, you’ll probably hit #1 75% of the time, but the other two are wrought with problems. If the project compiles but doesn’t work correctly, you may not find out until you’ve given it to your users, with the worst case being unrecoverable data corruption. If it doesn’t compile, then what? The shared code is now required to be different in two different projects and you may have no history as to what was changed.
Thankfully the folks at who are maintaining Subversion at the Apache Software Foundation made it super easy to create shared code repositories using a feature called Externals. (For those of you that are using Git, I suggest looking into Submodules. Of the two techniques I’ve encountered, Submodules seem to require the least individual overhead.)
Comments closed
The linker is not technically part of the compiler, but it is needed to make a completed app. The purpose of the linker is to combine (link) all the various bits and pieces of machine code created by the compiler along with the necessary information to create a runnable app for the OS.
This is the ninth and final post in our Compiler series. Previous posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
- Compilers 106 – Optimizer
- Compilers 107 – Optimizer Loop Unrolling
- Compilers 108 – Code Generation
Code generation is one of the last steps of the compiler. This is where the compiler emits actual machine code for the IR that was previously created.
This is the eighth post in our Compiler series. Other posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
- Compilers 106 – Optimizer
- Compilers 107 – Optimizer Loop Unrolling
Object Oriented Programming (OOP) puts in our hands the ability to create apps in a flexible and powerful way. Xojo embraces that philosophy in the Xojo language itself, allowing us to implement code in a flexible way for reuse, extension and maintainability that reduces the development cycles. One of these language tools is, in fact, common in other low level programming languages: Casting or type conversion. If you are interested in this (and you should be), continue reading and discover what it is, why you should be interested in it and how can you use it in your next Xojo app!
Comments closed