18 Oct 2020

feedPlanet Openmoko

Michael "mickeyl" Lauer: SPM-ifying YapDatabase

Converting an existing Objective-C/Swift framework to Swift Package Manager I'm a big fan of the database library YapDatabase, which is a collection/key/value store for macOS, iOS, tvOS & watchOS. It comes with many high level features and is built atop sqlite. In the last 5 years, I have used this successfully for many of my projects. It is written in Objective-C and comes with a bunch of Swift files for more Swifty use. Since I recently announced to go all-in with Swift, I want to convert all my dependencies to the Swift Package Management system. I have never been a fan of CocoaPods or Carthage as I found them too invasive. As this point of time though, YapDatabase is not Swift Package Manager (SPM) compatible and all approaches to do this using the current source layout did fail. So I had a fresh look at it and decided to do it slightly differently: If you don't have to work with the constraints of an existing tree layout, the process is relatively straightforward. Read on to find out what I did. Prerequisites Use swift package init to create a package named YapDatabase. Edit Package.swift to make the package create two libraries with associated targets ObjCYapDatabase is going to hold the Objective-C part in Sources/ObjCYapDatabase, SwiftYapDatabase is going to hold the Swift parts in Sources/SwiftYapDatabase. I couldn't name the Objective-C library simply YapDatabase, since this would have required to rename the (then umbrella) header file YapDatabase.h, which I didn't want to. Swift vs. Objective-C At the moment, SPM is not capable of handling mixed language targets, i.e., you either have only Swift files or no Swift files at all in your target - therefore I split the repository accordingly and moved Swift files below Sources/SwiftYapDatabase. Source and Header file locations SPM is pretty rigid when it comes to the location of source and header files. This is the reason why I unfortunately could not deliver this work on top of the original source repository. Fortunately though, the source repository was very well structured. To layout the files in a way that makes SPM happy, I Created two header file directory, include for public headers, privateInclude for private headers. Moved all header files from Internal directories and those with private in their name to the privateInclude directory. Moved the remaining header files to the public include directory. Swift The aforementioned steps were enough to make SPM compile the ObjCYapDatabase. To make the Swift part compile, I had to Edit all Swift files to import ObjCYapDatabase instead of Foundation via sed -i -e s,Foundation,ObjCYapDatabase,g *.swift. This made the SwiftYapDatabase compile. What's Next There are some parts missing: I didn't include the example programs, the tests, and the Xcode project. I don't know Robbie Hanson's (creator of YapDatabase) plans. As it stands, this shuffling around was merely a proof-of-concept to find out whether such an approach is sufficient to SPM-ify YapDatabase or whether to there are more problems to consider. I will incorporate this in one of my projects to put it through a real world test. I have published the repository as mickeyl/SwiftYapDatabase and will report this work via the YapDatabase issue tracker. Let's see what happens next.

18 Oct 2020 12:00pm GMT

04 Oct 2020

feedPlanet Openmoko

Talpadk: An early unfair first comparison of the Radiona ULX3S and the Olimex iCE40HX8K-EVB

Why unfair?

ULX3S

Well when I obtained the iCE40HX8K-EVB it had already existed for quite some time the ULX3S I had just received the unit from the Crowd Supply campaign.
And Olimex therefore had lots of time to "perfect" the documentation Radiona on the other hand has not yet had the luxury of time yet.

Hardware

Well I'm not really going to… The FPGA on the ULX3S is quite powerful and the board itself has more features as well, lets just call them different classes of products.

Software

Well both FPGAs are supported by the open source command line friendly toolchains.
Xilinx years ago sort of cured me of any desire for using huge closed source applications for programmable logic.
Many thanks to the developers of yosys, icestorm, nextpnr, prjtrellis, writers of programmer software and GNU / libre-software in general.

Getting started documentation

I must admit that I'm not that impressed with the getting started experience.

The Radiona wiki links to what they call the ULX3S official site.
And at the time of writing this I find it somewhat lacking in getting started information.
Things I miss:

Eventually one does find the https://github.com/emard/ulx3s-examples, and gets around to compiling the toolchain for ECP5 (I previously only compiled it for ICE40)
However when trying to flash the bitstream (after changing the makefile to suit the 85F variant that I got)
The pre build binary of ujprog that comes with the example code fails with the message

ULX2S / ULX3S JTAG programmer v 3.0.92 (built Oct 3 2020 19:32:10)
Cannot find JTAG cable.

I have try to specify the port using -P and it does get a LED flashing but no blinking LEDs.
I also try to build ujprog from the sources, but I get the same massage including the version number.

Longer down the road I stumble across https://github.com/q3k/ulx3s-foss-blinky.git which from the get go targets my variant of FPGA (let doubt that I just compile the bitcode the wrong way)
It uses OpenOCD to do the flashing and best of all it WORKS 🙂

The OpenOCD flashing does seem to be a bit slow though… So I keep looking and finds a manual of sorts it has a list of programming options and even a description of how to power the board.
The list contains a different programmer openFPGALoader that seems to have more resent updates than ujprog, and the schematic does have a note about them changing the wiring of the programmer in a revision of the board.
Compiles the code, fingers crossed that they have updated it to match the production PCB…

Success 2: openFPGALoader -board=ulx3s bitstream.bit also works

Conclusiuon

Is the current documentation a bit rough around the edges? Probably yes.
Is the board amassing?
Probably also yes…
I mean the FPGA is large enough to hold an entire Amiga "implementation".
The quality of the hardware looks nice too.
And the board contains an integrated programmer and a selection of peripherals to keep me busy for a while.

Would I recommend the board… Well I haven't spend enough time with it just yet, but it does seem likely.

If you do get the 85F I would recommend the ulx3s-foss-blinky as a hello world.
And if you have a production PCB i would recommend checking out openFPGALoader for flashing the bit stream.

04 Oct 2020 9:23am GMT

03 Oct 2020

feedPlanet Openmoko

Michael "mickeyl" Lauer: Programming Languages

While I never got much into natural languages (beyond my native tounge, a halfway solid english, and some bits and pieces of french), I have always been fascinated by (some) programming languages - I even wrote books about some of them. I (literally) grew up with BASIC and 6502/6510 ASSEMBLER - on the VC20 and the C64. Later on, learned to hate C and love 680x0 ASSEMBLER - on the AMIGA. During the 90s, I enjoyed PASCAL and MODULA II, and then found a preliminary home in Python. The 2000s were largely affected by C++ (which I always found much more interesting than JAVA) until I got acquainted with Objective-C - which later rised to the 2nd place in my top list - shared with Vala, which I still have a sweet spot for, since it liberated me from having to use C. As I grew older (and suddenly realized that my lifetime is actually limited, imagine my surprise…), I learned to embrace higher abstractions and being able to formulate algorithms clear and concise. While Python allowed me to do that, its reliance on runtime errors as opposed to compile-time always bugged me. During the 2010s, I settled on using Python on the server, and Objective-C on the client - still dreaming about a language I could use for both. Fast-forward to 2020. I have been a vocal critic of Apple's new language, Swift, since its debut - for reasons which I'm not going to repeat. Three months have passed since I started learning Swift and I think it's time for a first preliminary report. TLDR: I like it - a lot more than I have ever thought - and will from now on try to use it pretty much everywhere. Before moving on with some details, let me also confess that I'm pretty glad having waited for so long. Judging from the outside, the road to Swift 5 was a very rocky ride. Were I to begin with an earlier version, I might have given up or wasted many hours following a language that was such a moving target - changing every year in more ways than I would have been willing to participate. Syntax, Semantics, and Idioms Swift is very expressive and rich in syntax, semantics, and idioms - and it has a tough learning curve. As someone who has written Objective-C for almost a decade now, let me tell you that whoever told you that Swift is more accessible than Objective-C is a downright lier. Objective-C is a very simple language, as it adds one (yes, just one) construct (and some decorators) on top of another simple language - C. Once I was beyond my reluctance to look into it, I finally see the beauty. Swift has almost everything I have ever wanted in a programming language. Among many other features, it has type safety, generics, multiple inheritance (in the disguise of protocols with default implementation), closures, type inference, namespaces (ok, not first class, but think enums without cases), rich enums, … On top of that it has a REPL (Read-Eval-Print-Loop), which can't be praised enough - it is the #1 missing feature in most compiled languages - and syntax for building DSLs (Domain Specific Languages). And: It is Open Source - which is the #1 feature that has always irritated me with Objective-C. Interoperability I hate repeating myself. I love generic solutions. Over the last decade, I created a number of reusable frameworks that powered all the apps I wrote. It has accumulated quite a bit of stuff, as you can see here (generated using David A Wheeler's SLOCCount): SLOC Directory SLOC-by-Language (Sorted) 2110719 LTSupportCore objc=2063905,ansic=31423,java=5914,cs=3822,cpp=2772, python=2397,sh=486 106939 LTSupportDB objc=106108,sh=831 35669 LTSupportTracking objc=17443,ansic=12219,cpp=4922,java=902,sh=128, python=55 30331 LTSupportUI objc=30053,sh=278 27116 LTSupportDRM objc=27116 9499 LTSupportBluetooth objc=9365,python=134 6143 LTSupportAutomotive objc=6143 5141 LTSupportAudio objc=5141 4510 LTSupportVideo objc=4510 3324 LTSupportCommonControls objc=3324 679 LTSupportDBUI objc=679 340 LTSupportMidi objc=340 271 LTSupportDiagnostics objc=271 One of the things contributing to scare me before switching to Swift was that I may had to rewrite all that again. But it ain't necessarily so. Calling Objective-C from Swift Being probably the company that has the largest Objective-C codebase in the world, Apple worked hard on interoperability. Calling Objective-C from Swift is a breeze - they'll even convert method names for you. Not much to complain here. Almost every Objective-C construct is visible to Swift. Calling Swift from Objective-C Calling Swift from Objective-C is a tad bit harder. Apart from having to including (generated) extra headers, the whole plane of types with value semantics is more or less invisible to Objective-C. There are ways to bridge (AnyObject), but it's cumbersome and sometimes very for generic code (__SwiftValue__). Beyond Apple In a surprising move, Apple released Swift as an open source project. And although the struggle of combining a product oriented software release cycle with a community oriented evolution process is sometimes obvious (you can follow the tension if you read some of the evolution threads on the Swift forums), they manage it quite well. What catched my attention in particular was the invention of Server-side Swift and the Swift Package Manager, since these two projects have the power to replace my use of Python forever. Foreign Platforms My new set of swift-frameworks will be open source and also support UNIX-like platforms (to a certain degree, since Apple still has their crown jewels like UIKit and AppKit closed), hence finally I can use my reusable solutions both on the client and the server. Unfortunately Google backed somewhat out of using Swift. For quite some time it looked like they would embrace it as another first-class language for their forthcoming Android successor. This would have been the icing on the cake, but let's see - Kotlin is pretty similar Swift, but not it. Conclusion I'm now familiar enough with Swift that I made the decision to go all-in, helping to improve the server-side ecosystem as I go. Speaking about which - I still miss a bunch of features, in particular first-class coroutines for asynchronous algorithms, a proper database abstraction, and a cross-platform logging solution. But what I enjoy the most is to be a part of a vibrant (language) community again. People are way more excited when it comes to Swift as they ever were with Objective-C. And this is great!

03 Oct 2020 12:00pm GMT