Swift language support

Is Swift language support planned for FoundationDB?

5 Likes

If can’t wait until an official client be available you can develop your own. Swift is able to interop with C APIs. You will find client’s header file in

Windows
ProgramFiles/FoundationDB/include/foundationdb/fdb_c.h’
Linux,
fdb_c.h is installed into /usr/include/foundationdb/
libfdb_c.so is installed into /usr/lib/
macOS,
fdb_c.h is installed into /usr/local/include/foundationdb/
libfdb_c.dylib is installed into /usr/local/lib/

And this is the Swift Interop Documentation

What I’d really like to be able to do is to write and test FoundationDB code using:

  • the Xcode IDE
  • a Swift language API
  • prototype on Xcode Playgrounds
  • target macOS, iOS, tvOS and homePodOS (when available)

Right now, I am fiddling with getting FDB python running on Xcode… Next (as you suggest) figure out how to learn/write the FDB C interface using Swift, then try to get that working on Xcode Playgrounds…

I strongly suspect that Apple has already done all of this with FDB – just wish they would publish the API and docs how to do this…

Hey, Its open source – don’t expect perfection… just guidance and a starting point.

I’ve made some progress towards my goal of writing FDB apps in Swift on macOS Xcode.

The Class Scheduling sample code (tutorial) is up and running in both Python and Ruby thru Xcode.

It’s frustrating because it took a lot of esoteric surfing and experimenting to get these up on Xcode…

Further, I am unfamiliar with both Python and Ruby – so I had to spend time to get up a little speed on these.

Per your suggestion, the next logical step is tp bring up a C version of the app – then try to migrate that to Swift…

Unfortunately, there is no sample code for a C Class Scheduling app – only Python, Ruby, Java and Go.

These all seem a step backwards… Frustrating…

But, at least I have some apps running – so I can experiment with FDB.

It sure would help if Apple fleshed out their samples and docs!

One note on a why a C-version of the class scheduling tutorial doesn’t exist.

The C bindings are intended to be essentially just a bridge into our native client rather than a first-class binding in-and-of-themselves. If you’ll note, there isn’t an implementation of the Tuple or directory layers in C, and most of the “C” bindings are really written in flow/C++ with one file, fdb_c.cpp, that exposes a C-API. That being said, we’ve written some stuff, like a simple performance tester, that use our C bindings directly, but we generally wouldn’t encourage clients to use it as the basis of anything other than a higher-level binding.

Appreciate the response… Your explanation makes sense.

I have no desire to program in C (or Python, Ruby, Java or Go for that matter) – it was just a means to an end: Swift FDB on Xcode.

@fitomad suggested that the C APIs as a means to this end.

I may have been brute-forcing the from the bottom up – I am getting the impression that FDB’s C APIs (even if written in flow/c++) are the basis for all the higher-level language implementations???

Yep, all of our HLL bindings use the C APIs at heart–even the flow bindings! An application using the flow bindings would end up doing its application logic in flow, calling out to the C bindings through the flow bindings and then relying on the underlying flow fdbclient. The drawback is that you have to do things through an indirection layer when it seems like it would be easier to just call flow things directly. The benefit you get from this is that you can now independently update fdbclient without having to update your flow-based application. (You can even use a different version of flow itself within the bindings and within your application.) Our current suggestion is that future bindings should probably go through the C bindings as well.

I wrote up a topic on what I think the steps are to get a fully-fledged binding up and running here: Creating New Bindings I hope that helps!

Oh my…

Are you [FDB] guys going. To be at WWDC?

FWIW, I posted this to forum at

I have been playing around with FDB for the past few days…

I used their sample Class Scheduling app:

https://apple.github.io/foundationdb/class-scheduling.html

I got the app running on Xcode in both Python and Ruby. I’ve never used either language and both of them want to run on the command line (terminal window) instead of Xcode. It took a while to get them running and get me up to speed on the language, infrastructure, etc. – but that’s another story.

So, unfamiliar db, unfamiliar language, coerced IDE…

The results are impressive to me – and I even added a Blob sample to the Python version:

Here’s a sample of the out put of the Python app:

https://forums.appleinsider.com/uploads/editor/oa/dp3ke6mkqlin.png

The red area shows some samples of the Classes db a portion of the list (array) unformatted and formatted.

The blue area shows sizes and timings for the Class Scheduling app:
a total of 1,620 classes in a db of 32,742 bytes – about 20 bytes per class
scheduling 2,659 * students to 5 classes each (10 random attempts) **

  • 2,659 is the number of students in my youngest grandson’s high school

** scheduling consists of 10 random attempts of the following operations until 5 classes are scheduled for each student:

  • signing up for a random class if seats are available
  • trying a different random class until one found with seats available
  • dropping classes
  • switching classes
  • Scheduling resulted in 26,590 transactions executed in 5,318 threads. It took 13.1 seconds to schedule all the students – 2,028 transactions per second.

The yellow area shows the size and timing of FDB handling blobs:

  • blob size of 1,375,164
  • write the blob in .026 seconds
  • read the blob in .042 seconds

I ran this several times with similar results. There were about 1,000 processes running at the time – apps like Xcode, iTunes, Terminal, Safari, Mail, Bbedit… even a Time Machine backup.

https://forums.appleinsider.com/uploads/editor/no/phtjvwo2954o.png

Mmm… Just found this at: https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md

First, we have a couple of guys with a few bona fides:

then, we have this:

Here’s a link to a Swift playground that demonstrates Swift executing Python code: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042029.html

It appears that you may be able to prototype FDB [Python, Ruby, etc.] apps in Swift Playgrounds…

Then implement those FDB apps in say Swift/Python interoperability apps…

…at least, until a FDB/Swift SDK comes availabile/

1 Like

…Guess one has to start with the basics…

Using Chris Lattner’s Swift + Python Interoperability Tutorial – here’s a very primitive example of running FDB in a Swift Playground:

The syntax* looks a little kludgey – but it works!

  • FWIW, Chris includes a proposal for syntactical sugar to make it more Swifty.

Well, here goes:

1 Like

More progress getting FDB to run in a Swift Playground (calling Python thru Chris Lattner’s Swift + Python Interoperability Tutorial).

It appears that most FDB calls to Python can be made with syntax like:

FDBConstruct.call(member: “FDB Command”, args: “arg1”, “arg2”…)

for example, the set k/v shown below as:

tr.call(member: “set”, args:“myKey111”,“poop deck party time again”)

var tr = dbSwift.call(member: “create_transaction” )
print("\n1 tr: (tr)")
tr.call(member: “set”, args:“myKey111”,“poop deck party time again”)
tr.call(member: “get”, args:“myKey111”)
tr.call(member: “commit”).call(member:“wait”)

Haven’t figured out, in Swift, how to define Python Functions or the @fdb.transactional decoration – but I don’t think I need to – you can call fdb constructs within a Swift func and the:

tr.call(member: “commit”).call(member:“wait”)

shown seems to do the job for transactions!

Here’s the latest:

As I mentioned before Chris has suggested some syntactical sugar that would make the Swift Python calls Swiftier.

Hi,

I have started a new project to create a swift binding using the C API. I’m following the same approach of java foundationdb binding. I have publish today the swift modulemap libfdb_c in https://github.com/nunomaia/CFoundationdb

Using this module map it is possible to use libfdb_c in a swift project. You can find of using the modulemap.

Capture

Great!

I will have a look at it…

I did a little Java programming years ago.

I used the Java Class Scheduling Sample Code to figure out how to get some of the FDB things working in my Swift/Python example.

I have no experience with C or using C from Swift…

Your approach seems to be the best solution in the long run.

After trying for a couple of hours, I couldn’t figure out how to get your binding working.

If you can put together sample code of a small working example it would really help

sure, tomorrow I will publish it into github

Thanks in advance!

After a lot of surfing and trying, I have used the Swift package manager to get pretty close… still having trouble with:

  • Where fdb components are installed on macOS
  • Where to call them from
  • Paths

Once, that is working from the cli, I want to generate an Xcode project.

My ultimate goal is to be able to prototype fdb in macOS playgrounds * and generate apps with Xcode projects.

  • from what I’ve read, you can’t currently use package manager files in Xcode playgrounds.

I have pushed into https://github.com/nunomaia/foundationdbSwift the initial project, I only had the the intention to make it public a few weeks from now because it not working yet.

Feel free to push changes to accelerate the development of swift client.

Thanks! I’ve been eagerly awaiting this:

I’m still confused or missing something…

I get this:

and:

I’m not familiar with using packages like this – I tried redownloading CFoundationdb, creating a local repository and tagging it appropriately – but no luck. Sorry, I’m really a noob on how to construct all the bits and pieces.

from command line execute

swift package resolve

to download CFoundationdb

Ahh… I read about that somewhere…

Fantastic! the build succeeded – I should be able to figure it out from here.

Thanks again for all your patience and help!