Last week we came up with an idea which might be rather useful for the Solidity to Ligo translation process. Since we already have a main contract detection mechanism we can differentiate between local and foreign calls. Solidity calls to foreign contracts are very similar to the local calls and their gas cost is calculated as a single chunk. In Tezos, however, every call to another contract should be formed as a separate transaction. To aid users with that we go through code while translating and try to convert all foreign calls to transactions. Thanks to the Babylonnet Tezos protocol upgrade, you can make a call to a contract by its arguments, knowing only part of its interface. It brings more versatility to implementing token interactions and lets us save a bit of gas. We take advantage of this capability by creating a transaction call dummies. This might reduce migration cost for systems consisting of several separate contracts in Solidity.

Another great milestone for us personally is now we are able to translate MakerDAO SAI contracts without errors! It surely doesn’t mean that this project can be magically migrated to Tezos in a few clicks. But it definitely means that our Solidity features coverage is quite large so it can swallow proven contracts with real-world usage.

As a small and nice-to-have change, we have added the “Default state” tab in our web version, so now you are able to get your contract Tezos origination params right in your browser! And now we have the main page in our Github wiki, which is aimed to guiding you when getting started.

If you want to stay tuned for more updates subscribe to our Twitter

Sol2Ligo foreign calls update was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

We have also worked on fixing numerous issues with our default state generator. The default state is a LIGO structure representing the initial state of a contract needed for its origination in Tezos. This mechanism is needed because in Ethereum contract is first deployed and then initiated by constructor call. Whereas in Tezos contract is deployed and initiated with some default storage parameters at the same time. Thus default parameters have to be somehow be extracted and prepared. This feature is not yet available in the web version, but you can pass the output file name via--outfile flag transpiler will produce a special .storage.ligo file alongside the main one. Also, this feature is enabled by default if you are translating using the aforementioned directory mode via --dirCLI flag.

Don't forget to give us star on GitHub 😊😊😊

madfish-solutions/sol2ligo

Try Sol2Ligo here: https://madfish-solutions.github.io/sol2ligo/

If you want to stay tuned for more subscribe to our Twitter
Our Website: madfish.solutions

Solidity to LIGO transpiler. Folder mode. was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our team at MadFish continues working on Sol2Ligo transpiler — a utility aimed at helping Ethereum developers migrate to Tezos by transpiling Solidity into LIGO smart contract programming language.

In this update, we fixed and improved Solidity using keyword translation. Now if your underlying type is applying library methods for all its operations in LIGO you will get them too. Even if you use a library broadly as using Foo for * we can translate that as well. Some less prominent bugs in library translation were fixed in the process. For example this.prop() and super.fn() now come out as expected.

As per request, we have improved nested arrays and mapping access. Now your multi-dimensional arrays access like arr[1][2][3] will be split into multiple lines to mitigate LIGO limitation.

Another good news is that we have ported compilation flags previously available only in the CLI version to our web version.

Finally, we have cleaned up our warnings and put links to documentation where the additional explanation was needed. We plan to improve our documentation even further to make Solidity to Ligo transition even smoother.

Feedback

You may try our transpiler with all these new features online here: sol2ligo

Feel free to provide your feedback in our Github Issues should you run in any trouble:

madfish-solutions/sol2ligo

Subscribe to our Twitter to stay tuned: @madfishofficial

Improving library and using keywords on Sol2Ligo transpiler was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

For this example, we have created two nearly identical LIGO contracts based on the better-known increment-decrement contract boilerplate.
Those contracts are pretty simple and the main idea of both is to have a single entrypoint, but with a little twist. The first one accepts a structure and the second one expects a tuple as a parameter. Both of them should also have the same argument types in the same order.

Here is a comparison of these two contracts.

When compiled to Michelson differences between these two are even more minor.

That is what is called annotations: additional information about data that is carried around to assist you in debugging and development. Annotations also make contracts in a block explorer more understandable.

But the trickiest part comes when you compile your parameters to Michelson to perform an actual call.

> ligo compile-parameter ./contracts/Annotated.ligo main “Increment(record [ first = 5; second = 3n])”
(Pair 5 3)
> ligo compile-parameter ./contracts/Tuple.ligo main “Increment(5, 3n)”
(Pair 5 3) 

As you can see, input parameters are compiled to the same Michelson code. Therefore, you can perform calls to a contract either by record convention or by tuple convention without any difference. You should just ensure proper types and their order. As for the “gas cost” part we didn’t immediately have any definitive answer, but we configured a mockup Tezos chain to test this out. We passed this argument to both of our contract and got the following results.

The result is non-annotated contract uses 228 less gas. And that is only by stripping two arguments. This might or might not be a lot in your case. I would recommend trying this on your own contract to see the real-world results. Though you may miss some of those sweet names which make working with your contract a bit more pleasurable.

Links

We are grantees of Tezos Foundation developing multiple projects for Tezos ecosystem. Check out our website: madfish.solutions

Our Twitter: madfishofficial

Our Github: madfish.solutions

Annotations in Tezos and Michelson was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

Though the pandemic is ongoing, we are keeping nose to the grindstone on our Solidity to LIGO transpiler.

We have planned a lot of new and useful features; that’s why we have to drastically rework our the project for its better maintainability in the future. Now our architecture is reorganized according to the modern standards of compiler development. This new architecture will allow us to improve code analysis for implementing more complex features and polishing contract interoperability support.

We have laid the foundation for ERC20 and ERC721 interfaces conversion. This means transpiler will now detect if your Solidity contract uses either of these two interfaces. Thereafter, the transplier will try to replace them to a corresponding FA1.2 and FA2 code respectively. For example, if you want to migrate your Dex contract which works with ERC-20 tokens, you will get a code which theoretically does the same with FA1.2 tokens on Tezos. Since Tezos and Ethereum contracts have different mechanisms of interoperability, this will require some manual intervention. But as of now, it feels extra convenient to have at least a template for things that can’t be translated.

Another thing we worked on was a runtime execution tests. From the very start of this project, we were a bit worried issues could appear at runtime, even when the transpiled code looks valid. To eliminate this risk, we have developed a bunch of tests which compare execution results of a translated code. We have decided to limit ourselves to plain types and maps. But now we at least can be sure that Solidity adding to map is, in fact the same as LIGO's Map.add.

In the process we have improved our static analysis methods along with incorporating some new and more concise LIGO syntax. Now resulting code better detects external functions and returns operation list when appropriate. We are also planning to implement a similar approach to pure functions detection and such.

You can play around with our transpiler online here. Try these new features and tell us what you think! And don’t hesitate to reach out to us if you run into any difficulties. We are open to suggestions — the more users trying out our utility, the better we become.

Links

Try it online: sol2ligo

Feel free to provide your feedback in our Github Issues section:

madfish-solutions/sol2ligo

Subscribe to our twitter for updates on this and other our projects: @madfishofficial

Sol2ligo update #4 was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Official Windows Package Manager similar to apt in Ubuntu or brew in OSX
• DirectX support for WSL. Which may allow Windows to take a crown of Ubuntu being the most used platform for Machine Learning. As a nice side effect it may provide us with Linux GUI apps in Windows.
• Windows Terminal 1.0 release. That should have been done decades ago
• PowerToys — a bunch of utilities inspired by PowerToys for Windows 95 which include Spotlight-like launcher and window-switcher, key remapper and, some more.

So I decided to boot into Windows to check them all out. And they are nice and useful until you include user experience into consideration. And let me spoiler it for you — it just sucks.

Want to read this story later? Save it in Journal.

Terminal and WSL 2

Let me start with the Windows Terminal experience. Overall, it works fine. You can do your development work in a neat Linux environment. But the first launch of the Linux subsystem after system reboot is unbelievably slow. Apparently it needs to initialize a hypervisor once, and then WSL launches fine subsequently. My XFCE Terminal starts almost instantly on the same machine. And it doesn’t matter if I launch it the first or tenth time.

Not to mention that wsl$ folder is inaccessible in File Explorer before the first launch of the terminal. You basically cannot skim through your Linux files without enduring this wait.

The next thing in Windows Terminal that really bugs me is the menu. Why is it animated? Or, even if it is, why is animation so slow? I want any dropdown menus to be fast, at least not slower than the speed of thought. And it is not like animated menus are common across in Windows software. To me it seems like this one was specifically tailored for edgy teenagers to boast about their cool new terminal application. Not for professionals.

My next concern is the settings editor. Being a Linux user I’m used to editing text configs. But, really, Microsoft? You choose Notepad as a default editor for settings stored in JSON? It doesn’t have no syntax highlighting, nor indentation editing, which is quite necessary for editing JSON. But altering your settings manually using your favorite text editor is not an easy task either since documentation is outdated on their official Github page and points to the wrong file path.

PowerToys

I haven’t evaluated all utilities of PowerToys. I’m particularly interested in “PowerToys Run” to fire apps quickly since I use similar functionality on other platforms. But once again it is just impossible to work with. It visibly lags and blinks when I type. My laptop fan starts to rotate loudly while I am at it. And it sits in tray. I still don’t get why every windows application feels obliged to sit in a tray.

Moreover it doesn’t index newly installed applications. I guess we’d say it is an early release and hope for a later fix. Notably it has 23k Stars on Github at a time of writing. I don’t think there is any other alpha software given that much love.

But it made worse by the fact that even default windows search lags and blinks all the time. It generally searches better, but not by much. And lacks window switch functionality. If you try to search by part of the name it may not even work. I thought fuzzy searching was a solved problem, huh, Microsoft? You’ve done it right in VS Code, can you borrow that one employee to help for this specific task?

General windows experience

And now for my favorite part of using Windows. Open or save file Dialog is just the worst in all regards. I don’t know how this happens, but it is super jerky when appearing. My guess is some kind of compositing problem overlapping with an attempt to draw widgets asynchronously. And it is not like you can replace it with a third-party utility of some sort.

The right-click context menu is another favorite annoyance of mine. I don’t get why the context menu should contain all the actions available for this file type. Especially insignificant ones like “Print” or “Edit with Paint 3D”. This oddity is worsened by the fact that sometimes the system needs to load these context menu items and makes me wait, effectively interrupting my thoughts and irritating me.

The context menu itself looks amateurish. Some items have icons some don’t and I haven’t found any way to get rid of all of the unnecessary ones. All I want as a user is a few important generalized actions like “Open with” and “Properties”. And maybe a submenu for specialized ones. I don’t care about “Print” or “Give access to” since these operations are perfectly doable using other means.

Conclusion

I’m not sure if rendering lags are my hardware fault. I have a reasonably powerful laptop: Intel i7 6500U running on full performance, SATA 3 Solid-state drive, DDR4 RAM. Rendering is done on Intel HD520 GPU which is decent enough for the modern desktop. My OS isn’t cluttered, it is only stuffed with a minimal amount of software necessary for development work. Linux UI runs fluidly on this hardware even with a bit heavier Desktops like GNOME3. I’m pretty sure if I install Windows XP right now it will be as fast as any Linux desktop.

But even if it is my hardware fault, why would terminal emulator loading take any noticeable time? A system-wide search should not be as sluggish and unreliable. Guys at Microsoft are going in the right direction, but I don’t think performance is their concern yet (or ever, for that matter). And it is not surprising: with the rise of heavyweight JS applications everything not-Electron is recognized as fast nowadays. People rely on “better hardware is coming” for fixing software performance issues.

It is tempting to implement new and shiny features and tell about it in a development blog. But as you cut corners here and there, the overall user experience is lacking. And this is especially important for power users who need to get their work done fast and not break the flow of thought in the process.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

A router is a system in Michelson (low-level language for LIGO) that allows to pass arguments and make a call to any method specified in the contract. In Solidity, It is quite easy to call a single method of contract from outside. Just get the name from ABI, properly arrange arguments and you are good to go. However, in LIGO you can only call the main method. To work around the problem smart guys have came up with a router, namely: a special structure that allows users to pass the method name and its arguments straight into the main method. It will take care of the branching, make a specified call and return its value. Usually, developers of the contract do it manually, deciding which methods are accessible from the main entrypoint.

However, we believe it is crucial for our transpiler to remove this burden from the developer’s shoulders and let the machine do its work (so to speak). Sol2ligo analyzes input code, finds all declared methods and determines if a function should be added to the router. We analyze Solidity modifiers like public, internal, pure, view to detect the most suitable way to include the method. We have also improved our state extraction code which picks methods that should accept and return a contract state depending on pure/view modifiers in Solidity input code.

Let’s take a look at how we translate a simple Solidity method declaration into a LIGO function:

As you can see, even the simplest methods have to be augmented with opList and state variables to achieve the same logic as they have in Solidity.

But if you want to call a method from outside it gets more complex since you have to provide a router, so, practically, every method is being translated into the following piece:

This one is much more complex. Initially, record named <funcname>_args containing all arguments is formed for every method. Then, a composite type variant enclosing this record is generated and put into router_enum. Later, according to LIGO requirements, a method declaration is translated and modified to return both an operation list and a record for keeping state. Finally, the main function is created and it performs matching of input params with router_enum for calling a specific action. To better understand why all these complications are necessary, you may refer to the Entrypoints section of LIGO documentation.

Conversion highlights

One may wonder how we translate such different languages and, to be fair, that’s not an easy task. We want to share some highlights and clever hacks we have had to apply to get the best-looking result. I’m not sure if they’d settle since every the smallest detail raises heated debates inside our team of how to provide the best result for an end-user. Thereby, I’ve collected a few interesting cases to look at.

Array declaration

It’s implemented this way because LIGO doesn’t have any array support and map with an unsigned integer key is well suited for this job. Notice how we lose array size in the process - it doesn’t make sense to have a fixed length for a map

Map access

In Solidity, maps will return a default value if no value is found under the specified key. In LIGO we have to emulate this behavior by using one neat trick —case is an expression! It enables us to use its results anywhere in the code, even on the right-hand side.

C-like for loop

This is the exact case of for loop translation I have described in our previous story. Solidity doesn’t support for3, so we have had to transform it into a while loop. You can also notice that LIGO doesn’t have += operator, so this one has to be emulated as well.

Changelog

It was a fruitful month, so here are some key things we have been working on:

• Types and their default values: numbers, strings, bytes. Aliases for bytes<num> and int<num>
• Modifiers inlining, basic libraries unrolling, improved handling for pure functions
• Comparisons, bitwise math, negations, pow
• Cryptographic functions conversion
• Stubs for event and emit, more warnings and more explanations
• Improved type inference for number types and arrays
• Better tuples support
• require and assert (shout out to LIGO team for helping out)
• Basic support for address methods like (send, transfer)
• enum and struct declarations and definitions
• Tests for all of that

Work in progress

Lots of things are being changed, fixed and broken in the process. We change API and output trying to balance out readability and correctness. If you want to try it out be aware that’s an unventured territory, since no real-world testing has been done yet.

Check out repo at https://github.com/madfish-solutions/sol2ligo

Show us your support by leaving a star!

Subscribe for updates

Facebook and Twitter

https://tezos.org.ua/ — Tezos Ukraine community website
https://twitter.com/UkraineTezos — Tezos Ukraine twitter

Solidity to LIGO translation challenges (sol2ligo update #2) was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Transpilation” unlike “compilation” is a process of translating a code from one language into another, given that they are on the same level of abstraction. Take assembly, for instance. It is a low-level language and its instructions practically correspond to commands issued directly on the processor. Rust and C, on the other hand, operate on abstract mathematical entities such as variables and functions. Only later these entities are being compiled (hence the name) into processor instructions. But if you translate C to Rust this process is called “transpilation”, since they are both high-level languages.

How it is done

The process of translation is pretty similar to the one of compilation. In a nutshell, the idea is to parse the source language and generate target language output. In between there is a medium of translation called Abstract Syntax Tree, or AST for short. You may think of AST as of a tree-like JSON structure, containing every word and instruction of the language. And since it is a tree, every language unit is aware its own properties and also stores pointers to its parents and siblings. For example, this code:

Would be roughly represented as the following AST:

In detail

Transpiling a language generally involves a few stages: parsing, transformation, type inference, and translation

The very first stage required is Parsing. Parser takes the input language and splits it into syntactic units to create aforementioned AST. To our luck, Solidity compiler solc is able to produce such AST in JSON format out of the box. Parsing language is a complex task with hundreds of articles on this topic existing already. So let’s just continue to interesting parts and assume we have our input language neatly parsed into AST structure.

Next one is Transformation — a process of modifying a syntax tree for the purpose of getting data better suited for the target language. The stage is aimed at adapting the semantics of the language, since even seemingly
equivalent statements may require a special treatment. For example, in Solidity we can write widely used C-like for loop with 3 expressions like this:
for (init; condition; step)

LIGO doesn’t support such a statement, but as you may have guessed, it is possible to convert any for loop into a while loop like so:

init;
while (condition) {
 …
 step;
}

And that’s exactly where the transformer fits. It removes a for3 node from AST and creates a logically equivalent while statement to replace it. Keep in mind, it is operating on the syntax tree and not on the actual language text yet. Transformer is what accepts AST and outputs modified AST by recursively traversing nodes. You can take a look at our for3 transformer for sol2ligo here for a better understanding.

Sure thing quite a bit more transformers are necessary for different cases of ranging complexity in sol2ligo. They perform a wide range of operations: generating router, emulating state, inlining modifiers, unrolling libraries, taking care of inheritance and so forth.

Type inference — is a special step required to perform better informed decisions on types translation. Since LIGO compiler can’t do a type inference on its own, we kindly lend our helping hand here. Let’s consider returning from a function as an often occurring case. If you want to use the returned value you are ought to declare a variable like this:

const v : <type> = func()

Basically type inferrer’s task is to analyze all function declarations beforehand and remember their returned types for every function call. The same thing happens when we deal with variable declarations. In case we need to translate assignment operation we just peek to the right side of expression and infer the type based on what’s going on there.

Sometimes it is not easy to infer a type based on the data of the node’s closest siblings. That is why our type inference is divided into two stages. Roughly speaking, the first one identifies type from AST node and its neighbors and the second one may perform line traversal to fetch type info from farther away. Sometimes even this may not be enough, since statements like var x = 0; simply do not provide enough information about the type. Solidity assumes x of some ambiguous number type and we have to seek later operations to understand if this was intended to be int or nat.

If we got you interested, our type inference module can be found here.

Finally, the Translation stage (sometimes called “generation”) is what produces actual code from a syntax tree. You pass the an AST as an input and it outputs a valid LIGO code and does formatting, knowing how to interpret each node of the tree. It understands where to put brackets and what statements should be grouped into blocks. It recursively enters every leaf thus monstrosity like this:

Effectively gets translated into neat little function like this:

That is basically how your Solidity contract gets translated into LIGO contract. It is a simple enough process, but it requires careful thinking. We always keep in mind that similarly looking code may not work properly and even introduce subtle vulnerabilities, which did not exist in the original source code.

You may take a look at our project here: Github — sol2ligo. Give us a star to show your support!

This is a followup to the our story on Solidity to LIGO transpiler funded by Tezos Foundation. Check out our introduction story here if you want to learn more.

What is a transpiler? was originally published in Madfish Solutions on Medium, where people are continuing the conversation by highlighting and responding to this story.

I often send different documents via Telegram and proper Share menu would be super handy. But since I couldn’t find any graphical way to do that I decided to write my own script for this very purpose.

To achieve that I have created a script, which accepts only one argument — a file path. Executing this script brings up Telegram window in “Choose recipient…” mode, where you can immediately type desired receiver name. A file will be sent as soon as Enter is pressed. No more Alt+Tab and drag and dropping. No more clunky file chooser navigation.

How to

You may need to install wmctrl as prerequisite. On Debian-based system it can be done using sudo apt install wmctrl

Now create the following two-line script

#!/bin/sh
telegram-desktop -sendpath "$(readlink -f "$1")"
wmctrl -x -a Telegram.TelegramDesktop

First statement resolves any provided path to an absolute path using readlink utility and then invokes Telegram passing a special flag. Second line asks your window manager to focus and activate Telegram window so you can immediately start typing recipient name.

Save this script to file at your favorite scripts location and apply chmod +x to it. Then to execute this script use

./tg-share-file.sh file-to-send.jpg

For convenience you may want to add it to your aliases by the name of, for example, tgsend

alias tgsend=/home/user/scripts/tg-share-file.sh

And invoke it anywhere like so:

tgsend vacation-photo.jpg

I would also advice considering integration into your favorite File manager if you need to send files or photos often. One handy shortcut may save you a lot of time otherwise spent dragging and dropping files. Just find a way to pass selected file path as argument to this script and you are good to go! But because there are myriads of file managers out there I leave this as an exercise for the reader :)

In my previous post about Python to Rust transpiler I’ve said, that one of the biggest problems is absence of types in python and inability to infer them for functions. But it turns out there is a solution to this problem. Guys from Instagram have developed an incredible tool for runtime type inference called MonkeyType. It monitors what types functions accept and return while running a program. This approach works quite nicely so I want to share with you how it’s done.

Let’s take a look at the following totally practical example for determining if there is an even number in a list:

After transpiling to Rust you get:

This code can’t be compiled by rustc because only we know that argument is a vector, but not the compiler:

2 |     for num in numbers {
  |                ^^^^^^^ `T0` is not an iterator

And return type RT is not bool, for sure

4 |     return true;
  |            ^^^^ expected type parameter, found bool

But now let’s run our python code using monkeytype run __init__.py and then apply collected results by monkeytype apply main

And whoosh! We have List[int] type automatically derived for numbers argument and bool for a return type

Now the transpiled result will successfully compile by rustc because enough type information is known

This MonkeyType utility is quite powerful, so I ran it through our consensus prototype project and implemented translation for most frequently encountered types:

• List[T]will become Vec<T>
• Dict[T,S] will be HashMap<T,S>
• Optional[T] translates to Option<T>
• Tuple[T,S] is going to be (T,S)

But there are also types like Any and Union which cannot be easily translated to Rust type system due to their dynamic nature. And they suggest architectural problems in the code which have to be addressed.

In addition I’ve also implemented support for variable type annotations in translator, so you can write x:int = 1 in python and it will translate to let x: i32 = 1; Though it must be noted MonkeyType does not generate such annotations at all.

Porting guide

So, If you are like me and have found yourself in need to port a Python project to Rust I highly recommend you using MonkeyType before converting any code. First thing to do is to make sure you have Python 3.7, because typing support has much improved since its introduction in version 3.5. Then install MonkeyType using: pip install MonkeyType

Now launch your main file like this monkeytype run main.py. Since this utility infers types as it runs, you want to make sure you execute as much code as possible. If you have user interaction run all possible branching paths. If you have high test coverage you could run tests using monkeytype run `which pytest`. As you finished collecting symbols you can put all modules into file with monkeytype list-modules > module_list.txt. Edit that file and remove all external modules. Now use while read p; do monkeytype apply $p; done <module_list.txt to apply type annotations to all project modules from that file. In the process you may encounter python errors. Here are my errors and suggested solutions:

• Cyclic dependencies, which I resolved by creating forward declaration or simply removing both import and types referenced by them
• Methods returning Self. Python doesn’t support this in 3.7, so you may want to add from __future__ import annotations to the very beginning of file where function returns its class instance.

Because process of adding types stops on errors, you should fix them, remove corresponding file from module_list.txt and then reapply everything again. Repeat this steps until you got no errors. After that you can invoke pyrs on your folder to convert whole project to Rust. Viola! Both your Python and Rust methods now have types. I also worked a bit on struct definition generation lately, so your class fields will guess their types based on that as well.

Conclusion

Big props to guys at Instagram for creating and open sourcing such an amazing tool. It adds some performance burden and requires code to be evaluated to infer types, but works well and makes idea of converting Python to Rust a bit more practical. It may save some time when migrating languages, but don’t expect your code to compile out-of-the-box, because Rust’s borrow checker exists for a reason.

Check out the monkeytype in examples folder of pyrs repository to try it for yourself.