Shefali Dutta | 1 Jul 2009 08:19
Favicon

Re: [os-libsythesis] How to runasampleapplication

Hello Patrick,
  Thanks for your reply.

I am again surprised by a strange output. "nm libsmltk.a" does not show the required functions. This
library is being linked but does not contain any of the required functions. What can be the probable reason?

Rgds,
Shefali

-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly@...]
Sent: Tuesday, June 30, 2009 5:52 PM
To: Shefali Dutta
Cc: Lukas Zeller; os-libsynthesis@...
Subject: RE: [os-libsynthesis] [os-libsythesis] How to runasampleapplication

Hello Shefali!

Good to see that you haven't given up on SyncEvolution yet. I'm still a
bit mystified why you keep running into issues that I haven't seen
before - I swear, this should work ;-}

On Tue, 2009-06-30 at 05:02 -0700, Shefali Dutta wrote:
> I have tried compilation using --with-synthesis-src and --disable-shared option. I am getting some
linking errors related to libsynthesis:
>
> File engineinterface.cpp -> Undefined reference to smlLockWriteBuffer, smlLockReadBuffer, smlUnlockWriteBuffer.
> And many more errors related to smlxxx functions.

These are in libsmltk, built in the same directory as libsynthesis
(Continue reading)

Patrick Ohly | 1 Jul 2009 09:14
Picon
Favicon
Gravatar

Re: [os-libsythesis] How to runasampleapplication

On Tue, 2009-06-30 at 23:19 -0700, Shefali Dutta wrote:
> I am again surprised by a strange output. "nm libsmltk.a" does not
> show the required functions. This library is being linked but does not
> contain any of the required functions. What can be the probable
> reason?

This is really strange. At least we are on-topic for this list again.
Let's compare where I get the symbols from:

src/build-synthesis/src$ nm -o .libs/libsmltk.a | grep smlLockWriteBuffer
.libs/libsmltk.a:libsmltk_la-mgrinstancemgr.o:00000000000005f3 T smlLockWriteBuffer
.libs/libsmltk.a:libsmltk_la-mgrcmdbuilder.o:                 U smlLockWriteBuffer

The source is in
libsynthesis/src/syncml_tk/src/sml/mgr/all/mgrcmdbuilder.c.

Does your libsmltk.a contain the object file (ar tv .libs/libsmltk.a |
grep mgrinstancemgr.o)? If so, was it compiled successfully? Try
rebuilding it and check what the compiler does.

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Lukas Zeller | 1 Jul 2009 17:19
Picon
Favicon
Gravatar

Re: unified log file

Hello Patrick,

Before going into details, i.e. reviewing the patch I'd like to make  
sure I understand what is the goal:

- you want a single log file for ALL logging, which means:
   - both global and session log of libsynthesis (including messages  
generated by the DB plugins)
   - PLUS messages generated by your application

Right?

I don't see why you need two engines for that. You can initialize the  
same engine twice, once at the beginning with basically only the log  
options, and a second time when your generated config stream is ready.

Within the engine, you need:

- a new flag to have the session logger redirect its output to the  
global logger, and also forwarding the <appendtoexisting> flag to the  
global logger such that it won't overwrite the beginning of the log.  
Maybe some changes are needed to prevent re-instantiation of the  
global logger at the second init, I'll have to check that.

- a way to send debug message from the outside (the app) into the  
global log. Luckily, these already exist (Beat uses them exactly this  
way in his test suite). See DB_DebugPuts, DB_DebugBlock,  
DB_DebugEndBlock and DB_DebugEndThread entries in the UI_Call_In  
record, or the ready-to-use wrappers for these in SDK_utils (DEBUG_xxx).

(Continue reading)

Patrick Ohly | 1 Jul 2009 17:51
Picon
Picon
Gravatar

Re: [os-libsynthesis] unified log file

On Wed, 2009-07-01 at 08:19 -0700, Lukas Zeller wrote:
> Hello Patrick,
> 
> Before going into details, i.e. reviewing the patch I'd like to make  
> sure I understand what is the goal:
> 
> - you want a single log file for ALL logging, which means:
>    - both global and session log of libsynthesis (including messages  
> generated by the DB plugins)
>    - PLUS messages generated by your application
> 
> Right?

Right.

> I don't see why you need two engines for that. You can initialize the  
> same engine twice, once at the beginning with basically only the log  
> options, and a second time when your generated config stream is ready.

How do I do that? Calling InitEngineXML() twice? Wouldn't that reset the
logging that was set up earlier?

> Within the engine, you need:
> 
> - a new flag to have the session logger redirect its output to the  
> global logger, and also forwarding the <appendtoexisting> flag to the  
> global logger such that it won't overwrite the beginning of the log.  
> Maybe some changes are needed to prevent re-instantiation of the  
> global logger at the second init, I'll have to check that.

(Continue reading)

Patrick Ohly | 2 Jul 2009 09:43
Picon
Favicon
Gravatar

Re: unified log file

On Wed, 2009-07-01 at 08:51 -0700, Patrick Ohly wrote:
> On Wed, 2009-07-01 at 08:19 -0700, Lukas Zeller wrote:
> > I don't see why you need two engines for that. You can initialize the  
> > same engine twice, once at the beginning with basically only the log  
> > options, and a second time when your generated config stream is ready.
> 
> How do I do that? Calling InitEngineXML() twice? Wouldn't that reset the
> logging that was set up earlier?

There's one additional requirement: I also need to remove the datastores
from the engine without shutting down the engine completely. That's
because I want to continue writing to the log while the datastores clean
up and after that is done.

> > Within the engine, you need:
> > 
> > - a new flag to have the session logger redirect its output to the  
> > global logger, and also forwarding the <appendtoexisting> flag to the  
> > global logger such that it won't overwrite the beginning of the log.  
> > Maybe some changes are needed to prevent re-instantiation of the  
> > global logger at the second init, I'll have to check that.
> 
> Does <appendtoexisting> work for HTML?

... in particular considering that HTML and XML need opening and closing
tags. The instance which starts an empty log could write the preamble,
but who writes the end?

--

-- 
Best Regards, Patrick Ohly
(Continue reading)

Lukas Zeller | 2 Jul 2009 13:49
Picon
Favicon
Gravatar

Re: unified log file

Hi Patrick,

On Jul 2, 2009, at 9:43 , Patrick Ohly wrote:

> On Wed, 2009-07-01 at 08:51 -0700, Patrick Ohly wrote:
>> On Wed, 2009-07-01 at 08:19 -0700, Lukas Zeller wrote:
>>> I don't see why you need two engines for that. You can initialize  
>>> the
>>> same engine twice, once at the beginning with basically only the log
>>> options, and a second time when your generated config stream is  
>>> ready.
>>
>> How do I do that? Calling InitEngineXML() twice? Wouldn't that  
>> reset the
>> logging that was set up earlier?
>
> There's one additional requirement: I also need to remove the  
> datastores
> from the engine without shutting down the engine completely. That's
> because I want to continue writing to the log while the datastores  
> clean
> up and after that is done.

How do you define "remove"?

Once the session completes or when you force it down by calling  
CloseSession() the session (TSyncSession descendants) and datastores  
(TSyncDatastore descendants) will automatically be deleted, taking  
down all plugin contexts in the process.

(Continue reading)

Lukas Zeller | 2 Jul 2009 14:03
Picon
Favicon
Gravatar

Re: unified log file

Hi Patrick,

I hit the send button to early for the previous mail. Here's the  
second half of the answer:

On Jul 2, 2009, at 9:43 , Patrick Ohly wrote:

>> Does <appendtoexisting> work for HTML?
>
> ... in particular considering that HTML and XML need opening and  
> closing
> tags. The instance which starts an empty log could write the preamble,
> but who writes the end?

The TDebugLoggerBase object handles all this. The new  
<logsessionstoglobal> which makes one logger use another for output  
using outputVia() makes sure that the preamble is not written in the  
middle of the global log.

The end is written by the DebugFinalizeOutput() routine which is  
called when a logger is disposed. It tries to close the open blocks  
(only thise generate tags that span more than one message), and  
finally writes the suffix (like a closing </html>. This routine tries  
to play nice even if the block hierarchy is not correct, but might  
still fail in some cases.

Usually, a correct end is nice but not needed - the most interesting  
logs are those that abruptly end due to a crash anyway :-)

Best Regards,
(Continue reading)

Patrick Ohly | 3 Jul 2009 10:32
Picon
Favicon
Gravatar

Re: Synthesis client sometimes does not send an suspend alert during suspending

On Fri, 2009-06-26 at 00:37 -0700, Chen, Congwu wrote:
> Hello Luz,
> 
> I come up with this simple fix, I just add a flag to help. 
> For synthesis server, next sync can still resume even if client failed to 
> send an suspend alert; while this maybe not true for other servers. 
> Scheduleworld is such a server.

This patch is also in the Moblin git repo in the "congwu" branch. Should
I merge it into master? I don't want it to get forgotten.

--

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Chen, Congwu | 3 Jul 2009 10:39
Picon
Favicon

Re: Synthesis client sometimes does not send an suspend alert during suspending

Lukas, could you help provide your opinion? 

Thanks,
Chen,Congwu

>-----Original Message-----
>From: Ohly, Patrick
>Sent: Friday, July 03, 2009 4:32 PM
>To: Chen, Congwu
>Cc: luz@...; os-libsynthesis@...
>Subject: Re: [os-libsynthesis] Synthesis client sometimes does not send an
>suspend alert during suspending
>
>On Fri, 2009-06-26 at 00:37 -0700, Chen, Congwu wrote:
>> Hello Luz,
>>
>> I come up with this simple fix, I just add a flag to help.
>> For synthesis server, next sync can still resume even if client failed to
>> send an suspend alert; while this maybe not true for other servers.
>> Scheduleworld is such a server.
>
>This patch is also in the Moblin git repo in the "congwu" branch. Should
>I merge it into master? I don't want it to get forgotten.
>
>--
>Best Regards, Patrick Ohly
>
>The content of this message is my personal opinion only and although
>I am an employee of Intel, the statements I make here in no way
>represent Intel's position on the issue, nor am I authorized to speak
(Continue reading)

Patrick Ohly | 3 Jul 2009 12:24
Picon
Favicon
Gravatar

Re: unified log file

On Thu, 2009-07-02 at 05:03 -0700, Lukas Zeller wrote:
> On Jul 2, 2009, at 9:43 , Patrick Ohly wrote:
> 
> >> Does <appendtoexisting> work for HTML?
> >
> > ... in particular considering that HTML and XML need opening and  
> > closing
> > tags. The instance which starts an empty log could write the preamble,
> > but who writes the end?
> 
> The TDebugLoggerBase object handles all this. The new  
> <logsessionstoglobal> which makes one logger use another for output  
> using outputVia() makes sure that the preamble is not written in the  
> middle of the global log.

I gave this a try. I found that message dumping doesn't pick up the
right path from the linked logger; an additional indirection via
fOutputLoggerP is needed.

I also tried re-initializing the engine with a second call to
InitEngineXML(). This worked well, too, after disabling the check in the
engine which makes datastore configs obligatory.

I merged the Synthesis master and my own changes into the Moblin master.
Lukas, if you agree with them, please merge back. Thanks a lot for
introducing the much cleaner solution. It's a bit as in the Linux
kernel: propose a crappy solution and someone will come up with
something better. Some use this as a strategy to get things implemented;
this wasn't my intention here ;-)

(Continue reading)


Gmane