I’m trying to hook Pharo into the real-time order book feed from the Bittrex cryptocurrency exchange, which comes via the signalr protocol on top of a websocket connection.
Signalr is a Microsoft ASP.NET library designed to establish “persistent connections”. To use Signalr outside the Microsoft garden needs some protocol hacking from watching other implementations in action. I used python-bittrex-websocket and Pawel Kadluczka’s Informal Description of the Signalr Protocol was also a great help.
Note: As a general philosophy, I’m ignoring Signalr’s fallback to non-websocket protocols.
In my pursuit to connect Pharo to the realtime order book feed of the Bittrex cryptocurrency exchange there are two main challenges:
- It uses Microsoft’s signalr protocol.
Here I deal with passing Pharo through a Cloudflare guard. So lets get started…
Following on from Part 1 where we built PDFium from source into a shared library, we will replicate in Pharo the C example presented at the end of Part 1. Lets review the declaration prototypes of the function used, which we’ll need to implement in Pharo.
FPDF_DOCUMENT FPDF_LoadDocument(FPDF_STRING file_path, FPDF_BYTESTRING password)
unsigned long FPDF_GetLastError()
int FPDF_GetPageCount(FPDF_DOCUMENT document)
int FPDF_GetPageSizeByIndex(FPDF_DOCUMENT document, int page_index,
double* width, double* height)
void FPDF_CloseDocument(FPDF_DOCUMENT document)
So first we’ll define the basic scaffolding for our UFFI library interface to the Part 1 created shared library libpdfium.so.
For a while now I’ve been wanting to render PDFs inside Pharo. A few external libraries existed but none had suitable licenses. Recently I bumped into PDFium – the Foxit renderer open sourced by Google out of Chrome for use by Chromium. With its BSD license this seemed a good candidate, as well as being derived from a successful existing commercial product and part of a significant Google backed project. So it leverages a lot of funded engineering and expectations of quality are high. Its written in C++ but has a public C interface.
So here I am recording my exploration of building PDFium from source. Later in Part 2 I’ll interface to it using Pharo’s UFFI to render PDF pages to bitmaps displayed within Pharo.
Two popular choices for controlling maker projects have been are the Arduino and Raspberry Pi. The Pi is a micro-“computer” that runs Linux to operate as a low powered desktop computer. The Arduino is a much lower powered micro-“controller” that comes with analog IO the Pi lacks but is missing display and wireless interfaces. But! Now we have a new cool-kid on the block – the “ESP32” packaged in Sparkfun ESP32 Thing and the WeMos D32 PRO.
Fitting squarely between the Pi and Arduino, the ESP32 is a micro-controller like the Arduino nearing the speed of the Pi ZeroW. Its got even more analog IO where the Pi has none, and built-in WiFi and Bluetooth interfaces the Arduino lacks. This makes the ESP32 a great candidate platform for many applications including machine control and equipment condition monitoring. A built-in battery charger is a nice bonus.
I’ve tabled a spec comparison… Continue reading
Now we make use of the client data to track the indent level. The recursive call to clang_visitChildren() seems a bit of an anti-pattern to use with a visitor – presumably a new visitor is created each call. However that’s how it was done in a few tutorials I found and it does provide local storage for each nextLevel variable for the purpose of this demonstration. Continue reading
Okay, so we’ve got most of the parts ready. In the last part we managed to load the AST. Now lets do something useful with it. Traversing the tree is done uses a visitor pattern that supplies cursors to a callback function that define locations in the tree. To the original C code from part 3 we add: the callback function, which I’ve called acceptCursorCallback(); and the callout function clang_visitChildren(), which traverses the tree and invokes the callback function for each node it visits. Continue reading
In the last part we learnt how to get the version string of the library. That was good to prove it basically works, and also to develop our first C type “CXString“. Now we want to Pharo to process some C code. Baby steps with `libclang`: Walking an abstract syntax tree provided a good introductory tutorial to using libclang but was a bit C++ oriented, which is not so suitable for Pharo’s FFI. A pure C interface is easier, so I adapted that tutorial with help from sabottenda’s libclang-sample ASTVisitor. Continue reading
This is my first exposure to using Pharo’s FFI, so before diving in to process some AST, lets try something simpler to gain familiarity with the library. Something real simple…
no parameters and just returning a string. The function clang_getClangVersion() seems to fit the bill. First lets see how it works in pure-C. Continue reading
Table of contents
I wanted to better understand the opensmalltalk-vm that Pharo runs on. I started to manually chart and compare the C code between platforms, which was insightful but tedious and error prone. What I needed was to automatically process these files. Clang is a C language front-end for the LLVM compiler, designed to be integrated into external projects. Libclang provides an interface suitable for the Pharo FFI, but I’d never used FFI before. From a distance FFI had seemed somewhat daunting and complex, but it turns out reasonably straight forward. I’m documenting my experience in the form of this tutorial that I can refer back to, and perhaps shines a newbie light on things that may encourage other FFI neophytes to give it a go. Continue reading