KOBLDES


KOBLDES

It is a software that models building information. It is a tool for designing building.It uses POV-Ray for visualization.

Before Kobldes can work, POV-Ray needs to be installed correcly.

### To download POV-Ray, click here.

### How to install it? Click here.

### Correct bug in POV-Ray

There is a bug in POV-Ray include file. Open the following file

                 $ sudo gedit /usr/local/share/povray-3.6/include/sunpos.inc

and comment out the line at 125. After this, the line looks like:

                 //(SolarPosition)

—————————————————————————————————————————

### Download Kobldes

### INSTALLATION

1. Open a terminal

2. Create a directory to extract kobldes package.

            $ mkdir ~/kobldes

            $ cd kobldes

            $ unzip kobldes-0..59-2a.zip

3. Open and add the following line to povray.conf:

            read* = %HOME%/kobldes/ ; so kobldes.inc can be read

4.Now, run example

           $ povray kobldes.pov

### How to made our sample file?

1. Create a file named sample.pov and save in kobldes directory.

// file header

#include “kobldes.inc”

// testing kobldes

/*++++++++++++++++++++Start user interface testing +++++++++++++++++++*/

#declare Snap_Object = “box”;

#declare Snap_Point_Size = 10;

// vertical from

// VForm( name of form, edges )

VForm( “F500x900”, 5 ) // 5 edges

// put linear edge

PutLEdge( 500, 0 )                                   // length of edge, angle of edge

PutLEdge( 500, 0 )

PutLEdge( 500, 0 )

PutLEdge( 500, 0 )

ClsLEdge()                                              // linear closing edge

//end of form

EndForm( “F500x900” )   // name of form

// showing form

FCam(“center”, 7)                                    // target, zoom

// ++++++++++++++++++ Create building levels for the project

Site_Level( “TCC”, 0, 0 )                          // name, siteLevel, basementLevel

Building_Level( “TCCLevel”, 3000 )         // name, height

Set_Level( “TCCLevel” )                          // name of level

Space( “TABLE”, 4, 0, 2700 )   // name of space, vertical sides, base for the space, height of space

// rectilinear wall

// name of side- spacename-side1, length of side, width, rotation

RSide( “TABLE-S1”, 2500, 100, 0 )          // left side

// moves object from initial position to final

Put( “TABLE-S1”, 0, 0, 0 )                    // name of object, xpos, ypos, zpos

RSide( “TABLE-S2”, 4000, 50, 90 )       // top side

// moves new object “TABLE-S2” from inintial position by it’s r1 snap-point ti r3 snap-point of existing object “TABLE-S1”

SOffset( “TABLE-S2_r1”, “TABLE-S1_r3”, 0,0,0 )

RSide( “TABLE-S3”, 2500, 102, 0 )        // right side

SOffset( “TABLE-S3_l3”, “TABLE-S2_r3”, 0,0,0 )

// fit rectilinear side between existing sides

FitRSide( “TABLE-S4_r1”, “TABLE-S3_l1”, “TABLE-S1_r1”, 50 )   // bottom side

/*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/

//////////////////////////////// Environmental settings

RenderMode( “basic”, 5, 3, no )           // mode, quality, brightness, save

DayLight( “North-East”, 2013, 4, 14 )  // location, year, month, hour

// isometric view

ICam( “TABLEView”, “TABLE-S2_c2”, 2700 ) // name of space wih view, target spacename-side2_center2, target height

// view

View( “TABLEView”, 230, 40, 50 )        // name of space with view, pan, tilt, zoom

2. RUN

               $ povray sample.pov

2. OUTPUT

sample

Learn more, read kobldes.pdf.

Google C++ Testing Framework(Google Test / GTest) 


INTRODUCTION

Google’s framework for writing C++ tests on a variety of platforms(Linux Mac OS X, Windows).

It supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal test and non-fatal failures, value and type – parameterised tests, various options for running the tests, and XML test report generation.

Why GTest framework ?

1. When GTest fails, GTest allows you to run it in isolation for quick debugging.

2. GTest groups related tests into test cases that can share data and subroutines.

3. GTest works on different OSs with different compilers , with or without exceptions.

( Note: Here we discussing GTest on Linux. )

How GTest Works ?

When using GTest, you start by writing assertions, which are statements that check whether a condition is true. Tests use assertions to verify the tested code’s behavior. If a test crashes or has a failed assertion, then it fails; otherwise it succeeds.

ASSERTIONS

GTest assertions are macros that resemble function calls. You test a class or function by making assertions about its behavior. When an assertion fails, GTest prints the assertion’s source file and line number location, along with a failure message.

ASSERT_* versions generate fatal failures when they fail, and abort the current function.

EXPECT_* versions generate nonfatal failures, which don’t abort the current function.

Usually, EXPECT_* are preferred, as they allow more than one failures to be reported in a test. However, you should use ASSERT_*  if it doesn’t make sense to continue when the assertion in question fails.

1. Basic Assertions

These assertions do basic true/false condition testing.

Fatal Assertion Non-fatal Assertion Verifies
ASSERT_TRUE(condition); EXPECT_TRUE(condition); condition is true
ASSERT_FALSE(condition); EXPECT_FALSE(condition); condition is false

2. Binary Comparison

These assertions compare two values.

Fatal Assertion Non-fatal Assertion Verifies
ASSERT_EQ(expected,actual); EXPECT_EQ(expected,actual); expected==actual
ASSERT_NE(val1, val2); EXPECT_NE(val1, val2); val1!=val2
ASSERT_LT(val1,val2); EXPECT_LT(val1,val2); val1<val2
ASSERT_LE(val1,val2); EXPECT_LE(val1, val2); val1=<val2
ASSERT_GT(val1,val2); EXPECT_GT(val1, val2); val1>val2
ASSERT_GE(val1,val2); EXPECT_GE(val1, val2); val1>=val2

3. String Comparison

These assertions compare two C strings. If you want to compare two string objects, use EXPECT_EQEXPECT_NE, and etc instead.

Fatal Assertion Non-fatal Assertion Verifies
ASSERT_STREQ(expected_str,actual_str); EXPECT_STREQ(expected_str,actual_str); the two C strings havethe same content
ASSERT_STRNE(str1,str2); EXPECT_STRNE(str1,str2); the two C strings havedifferent content
ASSERT_STRCASEEQ(expected_str,actual_str); EXPECT_STRCASEEQ(expected_str,actual_str); the two C strings havethe same content, ignoring case
ASSERT_STRCASENE(str1,str2); EXPECT_STRCASENE(str1,str2); the two C strings havedifferent content, ignoring case

Download GTest

To download GTest, click here.

Linux Requirements

1. GNU  make

               $ sudo apt-get install make

2. POSIX standard shell

              $ sudo apt-get install bash

3. C++ compiler

             $ sudo apt-get install g++

Installation Steps

1. Decompress

            $ unzip gtest-1.6.0.zip

2. Go to this directory.

            $ cd gtest-1.6.0/

3. Standard GNU configure script

            $ ./configure

4. Standard makefile

            $ make

3. Builds and run all tests

           $ make check

Build Sample Test

As an example, the make/ directory contains a Makefile that you can use to build Google Test on systems (e.g. Linux, Mac OS X). It just builds the Google Test library and a sample test.

           $ cd make

           $ make

          $ ./sample1_unittest

If you are getting errors while running make, then open Makefile with sudo power

           $ sudo gedit Makefile

and replace “-lpthread” with “-pthread” at line number 80.

Build GTest samples

Jointly with the GTest, it also comes some C++ unit test examples, found in the samples directory. You can build this examples using CMake. It can be installed :

            $ sudo apt-get install cmake

The CMake uses a configuration file named CMakeLists.txt. To build a project with CMake is create a build directory, generate a Makefile using CMake and build it with make.

            $ mkdir build

            $ cd build

          $ cmake –Dgtest_build_samples=ON ..

           $ make

One advantage of using CMake is that you separate the deploy from source code and can make the deploy in multiple places with the same CMake file.

Now, execute all examples.

             $ ./sample1_unittest

             $ ./sample2_unittest

                   . . . 

            $ ./sample10_unittest

Build a simple example

1. First, build the GTest Library.

               $ g++ -I. -I./include -c src/gtest-all.cc

               $ ar -rv libgtest.a gtest-all.o

It will generates the libgtest.a.

2. Consider a simple unit test example of a C source code named mytest.c:

             #include <gtest/gtest.h>

            TEST(MathTest, Addition)

             { 

                        EXPECT_EQ(2 + 2, 4);

             }

             int main(int argc, char **argv)

             {

                    ::testing::InitGoogleTest( &argc, argv );

                    return RUN_ALL_TESTS();

             }

To build it, it is necessary to defines the GTest headers directory (parameter includes dir -I), compile the source code and link it with the GTest library (libgtest.a) and pthread :

               $ g++ -I. -I./include mytest.c libgtest.a -lpthread -o mytest

3. Now, call

               $ ./mytest

Output is :

mytest

Learn more.