lunedì 12 gennaio 2015

A step-by-step way to port Objective C classes to swift (part 1)

As many programmers around the world i was very pleased at the announce of the new swift language. I started with some sample code and i liked it so much that i wanted to use it in my production projects (even if in beta and often changing, even if not well documented...).
Mixing Objective C and swift code in the same project is quite easy, but when you want to use the most juicy features of swift like enums or generics you start writing a growing section of your project with not-objective-c-accessible code.

This grow up to a point where your old classes need to be rewritten in swift. Tedious and boring, but beneficial to the project.

My experience was that i needed to develop a standard and basically mechanical procedure to go from "@interface MyClass" to "class MyClass", mantaining all the old features and a compiling application, with the benefit of adding the swift compatibility.

Without further ado here is my list, feel free to adapt it to your situation and comment with the needed changes.

Suppose you want to migrate the class MyViewController from Objective c to swift

*) Take your application to a compiling and running state. 
If you have unit tests make sure they all pass or at least the ones related to the class that you want to rewrite. If applicable add a couple of unit tests for the class.
Run your program and note down what works and what don't.

Your current objective is not to fix bugs, it is only to rewrite the same code in swift, with the same bugs. One thing at a time!

*) Include the objective-c class header in your ${project}-bridging-header.h. 
Build, test, run.

*) Create a SwiftMigrations swift class. In my case i just created one for the whole project, but you could prefer to make one for every migrating classes.
This class will be marked @objc or inherit from NSObject, because you will need to call its methods from Objective C code. 
Build, test, run and commit.

*) Now choose one of the methods in your objective c class. The perfect candidate is one from which you would like to access some beautiful new swift-only code, like enums or generics.
So for example you did chose the method 
-(void)viewDidLoad {}
In the SwiftMigrations class you will add this method:
class func MyViewController_viewDidLoad(mvc:MyViewController) {}

*) Go on writing the swift implementation of the all method, using the mvc argument where you would use self.

*) In the objective-c class just comment the old method implementation and delegate to the new implementation like this:

-(void)viewDidLoad
{
    [SwiftMigrations MyViewController_viewDidLoad:self];
}

Build, test, run and commit.


Chances are that you are already happy with this; it's not pretty, but it allows you to use swift-only features from your old class. 

domenica 4 novembre 2012

Policy based design with C++11 variadic template parameters

Policy based design with C++11 variadic template parameters


If you read the book "Modern c++ design" by Andrei Alexandrescu you should already know about policy based design, and you can jump directly to the second section (The problem).
If you have not, i will make a super quick introduction here, but you can find more at http://en.wikipedia.org/wiki/Policy-based_design .

A policy is basically "one way to make something". If you write a class and you want to be able to customize some of its behaviour, you can isolate the customizable part into one or more policy classes and make your class derive from them.

Suppose you have this little class:


 class C{  
   const int array_size=5;  
   int a[array_size];  
 public:  
   int read(int i) {return a[i];}  
 };  

You may want to enable some type of bound checking while debugging the program, but disable it when you are releasing, in order to save those few cpu cycles.
One elegant way to do this is to separate the bound checking behaviour from the rest of the class, something like this:


 class CheckedBoundsPolicy{  
 public:  
   int check(int i,int array_size){  
     if (i<0 || i>=array_size)  
       throw OutOfBoundException;  
     return i;  
   }  
 };  
 class UncheckedBoundsPolicy{  
 public:  
   int check(int i,int array_size){  
     return i;  
   }  
 };  
 template<class BoundsCheckingPolicy>  
 class C: public BoundsCheckingPolicy {  
   const int array_size=5;  
   int a[array_size];  
 public:  
   int read(int i) {  
     return a[BoundsCheckingPolicy::check(i,array_size)];  
   }  
 };  

In this way you can select the behaviour of the class instantiating it:


   C<UncheckedBoundsPolicy> c;  


One useful tecnique for defining powerful PolicyClasses is the CRTP (http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).
Basically you pass the derived class to the policy class as a template argument, and the policy class can then use all the fields and types defined in the derived class. In our example we could do:


 template<class Concrete>  
 class CheckedBoundsPolicy{  
 public:  
   int check(int i){  
     if (i<0 || i>=((Concrete*)this)->array_size)  
       throw OutOfBoundException;  
     return i;  
   }  
 };  
 template<class Concrete>  
 class UncheckedBoundsPolicy{  
 public:  
   int check(int i){  
     return i;  
   }  
 };  
 template<template <class> class BoundsCheckingPolicy>  
 class C: public BoundsCheckingPolicy<C> {  
   const int array_size=5;  
   int a[array_size];  
 public:  
   int read(int i) {  
     return a[BoundsCheckingPolicy<C>::check(i)];  
   }  
 };  


I like to call Concrete the final class to underline the fact that a resulting instance will be of that type.
Note that thanks to multiple inheritance you can also define many policies for a single class.


The Problem


Each policy class can also add its own fields to the concrete class, but this possibility leads to a little problem.
Suppose a class C derive from one of 2 policies P1 and P2 like this:


 class P1  
 {  
   Object& obj;  
 public:  
   P1(Object& _obj): obj(_obj) {};  
   void f(){... obj ... };  
 };  
 class P2  
 {  
 public:  
   void f(){...}:  
 };  
 template<class P>  
 class C : public P  
 {  
   C(?????): ??????????????  
 };  


Suddenly we are unable to write a costructor for C which will work with both policies. If we use


   C(Object& obj):P(obj) {};  


the policy P2 becomes incompatible, because it doesn't have a constructor which accept a reference to Object. On the other hand, if we don't write a constructor, or don't initialize P, the policy P1 becomes incompatible, because it doesn't have a default constructor. Even if we wanted to write one we couldn't, because we need that reference to Object at construction time.
IMO this was a big limit, and until now i used the workaround of giving the same constructor set to all the policies of the same group, in our case by adding a constructor to P2 which would ignore the unused arguments:


   P2(Object& ) {}; // just ignore it  

.
This is absolutely ugly, and if the two policies have different members which needs initialization it becomes even more ugly from the point of view of the usability of the final class. You can select the behaviour you want, but you must carry all the baggage coming from all the policy members.

The solution (or what's changed with c++11 ?)


By experimenting whit the c++11 variadic template arguments i got the idea to use them inside the constructor of the final (concrete) class. In that way i could call the constructor with exactly the needed number and types of arguments needed by the selected policy/ies, without knowing them beforehand. Writing such constructor is really simple, in our example case:


   template<typename... Args>  
   C(Args... args):P(args...) {};  


This work just perfectly if your class derives from exactly one policy, but what if you have more? Suppose our class was defined like this:


   template<class P,class Q>  
   class C: public P, public Q  
   {  
   public:  
     template<typename... Args>  
     C(Args... args):P(args...), Q(???) {};  
   };  

C++11 doesn't give us any tool to split an "argument pack", the only tool is the extraction of a certain number of types from the head of the list.
We could think of:


   ...  
   C(Object& obj,Args... args):P(obj),Q(args...) {} // don't work  


But this has the same problem as before: we cannot know if P constructor have 1 or zero arguments.

So we can only use an argument pack if we derive from a single policy, but who says that policy cannot derive from another policy?
So i decided to try this approach: i will build a deep hierarchy of policies, and have them all extract the arguments they need from the pack and pass along the rest of the pack.

So here is my creation:


 /////////////////////////////////////////////  
 //               Generic part              //  
 ///////////////////////////////////////////// 
 template<class Concrete,class Mother,class Policy>  
 struct PolicyHolder{};  

 struct DeepHierarchyFinal{};  

 template<class Concrete,class P,typename... Args>  
 struct DeepHierarchy:   public PolicyHolder<Concrete,DeepHierarchy<Concrete,Args...>,P>,  
                         public P  
 {  
   template<typename... ConstructorArgs>  
   DeepHierarchy(ConstructorArgs... cargs):  
           PolicyHolder<Concrete,DeepHierarchy<Concrete,Args...>,P>(cargs...){};  
 };
  
 template<class Concrete,class P>  
 struct DeepHierarchy<Concrete,P>:   public PolicyHolder<Concrete,DeepHierarchyFinal,P>,  
                                     public P  
 {  
   template<typename... ConstructorArgs>  
   DeepHierarchy(ConstructorArgs... cargs):  
           PolicyHolder<Concrete,DeepHierarchyFinal,P>(cargs...){};  
 };  
 ///////////////////////////////////////////  
 //                Test case              //  
 ///////////////////////////////////////////
  
 ///////////////////////////////////////////  
 //                Policies               //  
 ///////////////////////////////////////////  
 struct Policy1{};  
 struct Policy2{};  
 struct Policy3{};  
 struct Policy4{};
  
 template<class Concrete,class Mother>  
 struct PolicyHolder<Concrete,Mother,Policy1> : public Mother  
 {  
   int x;  
   template<typename... Args>  
   PolicyHolder(int _x,Args... args):Mother(args...),x(_x) {};  
 };
  
 template<class Concrete,class Mother>  
 struct PolicyHolder<Concrete,Mother,Policy2> : public Mother  
 {  
   template<typename... Args>  
   PolicyHolder(Args... args):Mother(args...){  
     cout<<"Policy2 initialized";  
     // Here is a way to know (at runtime) if a particular  
     // policy has been selected in the concrete class  
     if (boost::is_convertible<Concrete,Policy3>::value)  
       cout<<" together with Policy3\n";  
     else  
       cout<<" without Policy3\n";  
   };  
 };
  
 template<class Concrete,class Mother>  
 struct PolicyHolder<Concrete,Mother,Policy3> : public Mother  
 {  
   string s;  
   char c;  
   template<typename... Args>  
   PolicyHolder(string _s,char _c,Args... args):Mother(args...), s(_s),c(_c) {};  
 };
  
 template<class Concrete,class Mother>  
 struct PolicyHolder<Concrete,Mother,Policy4> : public Mother  
 {  
   template<typename... Args>  
   PolicyHolder(Args... args):Mother(args...) {  
     // Here is a way to check (at compile time) that 2 incompatible policies  
     // does not coexist  
     BOOST_STATIC_ASSERT(( ! boost::is_convertible<Concrete,Policy1>::value));  
   };  
 };  
 //////////////////////////////////////////////  
 //              Concrete class              //  
 //////////////////////////////////////////////  
 template<class... PoliciesPack>  
 struct C: public DeepHierarchy<C<PoliciesPack...>,PoliciesPack...>  
 {  
   using Policies=DeepHierarchy<C<PoliciesPack...>,PoliciesPack...>;  
   string s;  
   template<typename... Args>  
   C(string _s,Args... args):Policies(args...),s(_s){};  
 };
  
 BOOST_AUTO_TEST_CASE( testDeepHierarchyConstruction )  
 {  
   C<Policy1,Policy2> c0("foo",4);  
   BOOST_CHECK_EQUAL(c0.x,4);
   
   C<Policy1,Policy2,Policy3> c1("bar",3,"foo",'f');  
   BOOST_CHECK_EQUAL(c1.c,'f');

   C<Policy3,Policy4> c2("rab","oof",'d');  
   BOOST_CHECK_EQUAL(c2.c,'d');  
 } 

If you have any idea how to make this more usable please leave a comment. I have not tested this design in a real world program yet, so there may be some issues, but i'm sure that this test case do compile and works (i'm using clang in c++11 mode and the boost libraries);

domenica 26 febbraio 2012

slic3r support tests

the print is good

seen from the bottom

the support perimeters are a bit too much: 3 perimeters of the configuration +1

the hole in this case have double perimeters, so 8 perimeters!

however they come off

but not without some damage :(

for this time i'll use some superglue to repair it, not a big deal..

Here i tried to print the ball bearing (which i could never properly configure with skeinforge).


Sadly, by configuring 1 perimeter, the support generated is just a single 2 mm long line under each ball, and so after a few layers some of the balls are detached from the bed. Maybe a super slow print could do the trick, i'll try that.  If i try to configure with 2 perimeters or more i get no support generated at all under the balls..

So, the feature seems promising but in my opinion is still not ready to be used blindly. Too bad i cannot write a single line of perl, and all i can do is test and wait..

domenica 22 gennaio 2012

my hot end




diametro del foro: 0.45 mm






Ecco il mio imbuto segreto per la ventola..
altezza layer: 0.3 mm