Carbider | 05 October, 2007 15:50
there was a period while all features were enabled. I used Carbide professional edition.
Then the test period was over, and Carbide came to Express(free, test) edition automatically.
For now I could not use UI Designer tool.
As a
S2F blogs author, I was linked up with
https://pro.forum.nokia.com/ launchpad program. We ordered there license of Carbide
Developer edition.
It took some time to understand, why the license is not still available for me though it was ordered. The reason was that there are different statuses of launchpad members. They are: the account owner and the account users. After purchasing Carbide, the account owner directs the license to account user. At this step user can activate the license.
There are “Node-locked” and “Floating” licenses models. The first means, that the license will be tied to concrete user’s computer by mac-address. The floating license allows to use several carbide products on several computers inside one development team’s network.
My license was node-locked. I clicked “Activate” link in front of license in my account.
The activation page has appeared. There I putted in my mac-address. I have Windows XP machine, so I used “IP CONFIG /ALL” command in prompt to retrieve those address. The license’s text appeared on screen, I copied it to Carbide’s “Help->Carbide Licenses->Install License”.
That was it. After IDE restarted I have had already enabled UI Designer feature.
The S60v3 SDK wants to be registered after 14 days too. It is simple free registration. The code would be send to your e-mail.
The license installation is described step-by-step while you’re ordering and retrieving it at
http://www.forum.nokia.com/main/e-store/.
The most full description is in pfd:
http://wiki.forum.nokia.com/images/1/1b/EStore-UM-v3.0.pdf
Carbider | 16 October, 2007 15:01
After unsatisfactory attempt to port BlueZ system to Symbian due to <sys/signal.h> differences, David advised me to look at P.I.P.S libraries. P.I.P.S. are Symbian libraries that are compatible with POSIX standard.
That could mean reducing efforts while migrating the project to mobile device.
That was true on several positions. But there still was a trouble with <sys/system.h>.
It has sigaction{} structure inside. But BlueZ needs sigaction() function too.
I don’t know, if the trouble is that BlueZ doesn’t support POSIX. Or it is a Symbian’s trait.
[PIPS_Essential_Booklet.pdf]
Which says: “The P.I.P.S. environment does not support signals”.
Other functions that are not supported:
sigfillset()
sigdelset()
I had to examine what Signals are used for. I came to conclusion that they are used to halt child processes.
Sigaction()function was used to specify the action to be associated with a specific signal. After that the process generates his child instance (with fork and exec) which can be killed by sending “halt” signal with this statement:
kill(pid, SIGHUP)
So, I did not still find the replacement to this function to kill child processes. I’m thinking about Symbian’s RProcess class. Any ideas?
I found that Carbide C++ is very strict to data types. Even more strict than unix c.
I had to replace statements like:
struct bnep_setup_conn_req *req;
req = (void *) pkt;
to
req = (struct bnep_setup_conn_req *) pkt;
At this 2 documents:
I found recommendations how to substitute ther “fork”, “exec” operations with other posix functions. The main is posix_spawn().
I tried to follow this idea, outflanking the forks and execs with posix_spawn().It worked well.
At run_script() function there is instruction:
execv(script, argv);
Before run_script()is used, the fork()function is called to create the instance of program itself.
This “execv+fork”pair is replaced by one
posix_spawn(&Childpid,script,NULL,NULL,argv,NULL);
call.
There are still lots of goals to reach. I don’t know how to pass command line arguments to Carbide’s console application.
The sdp.c is not implemented in this version of port because it still makes too much errors and it will take time to solve.
I think there will be resulting GUI application which will run main PAND console instances. After that they should get into single signed SIS installation file.
Carbider | 17 October, 2007 16:11
One more difference between Carbide C++ and standard C++ that I found while porting is pointers maintaining.
If you have a pointer 'p'
void *p = other_pointer;
in C you can sum it up with integer value to walk through memory:
p += sizeof(uint8_t);
That is frequently used in BlueZ libraries.
But Carbide doesn't allow such manipulation motivating with:
"illegal operands 'void *' + 'unsigned int'"
That is because Carbide is more strict with types than C is.
So to move through memory I need that pointer 'p' would be a pointer to specific data type, not ‘void’.
I decided, 'p' should be a pointer to 'uint8_t' because it is used as type’s length to determine data’s displacement step.
So the final declaration looks like this:
uint8_t *p;;
p += sizeof(uint8_t);