Re: Problem with event channels

Hi,

On Monday 30 June 2008 13:33, Karel Gardas wrote:
> Hi,
>
> just short question: are you sure your second application imr does not
> work against the first application micod? If so, then please try to
> provide more information, even better might be simple example including
> all starting scripts which duplicates this behavior.

No, I'm not sure since I did not really understand the imr arguments (and also 
Arno Puder's etc. book that I just got a few days ago did not help much on 
this topic). 

The software is much too big to supply it, but the start-up scripts (condensed 
to the essential parts) may hopefully supply enough information:

# Usage: start_mico.sh MICO_ADDR (i.e. port number)

MICO_ADDR=$1
RC="-ORBImplRepoAddr $1 -ORBNamingAddr $1"

# Run BOA daemon (micod)
micod -ORBIIOPAddr ${MICO_ADDR} --forward &

# Register name service (nsd)
imr create NameService poa \ 
nsd "IDL:omg.org/CosNaming/NamingContext:1.0#NameService" \
-ORBImplRepoAddr ${MICO_ADDR}

RE: mico for Mac OSX 10.3

Hello Ed & Karel

We also encounter this problem. For the immediate fix, after running
configure, edit the $(MICO_ROOT)/orb/makefile and append  -lcrypto -lssl
to the $(LDSO) line.

Regards
Ashish

-----Original Message-----
From: mico-devel-bounces <at> mico.org [mailto:mico-devel-bounces <at> mico.org]
On Behalf Of Karel Gardas
Sent: Monday, June 30, 2008 4:49 PM
To: Ed Johnson
Cc: mico-devel <at> mico.org
Subject: Re: [mico-devel] mico for Mac OSX 10.3

Ed,

it seems nobody here does have your platform at hand. Could you be so
kind and provide us with config.log and include/mico/config.h files
which are generated by the configure script. Also configure run output
is handy.

Thanks,
Karel

Ed Johnson wrote:
> Greetings,
> 

errors on mac os x (10.5) in demo/bench

Hi

if I run demo/bench, I get the following output.

$ [sudo] ./bench

### same process:
0.000733333 ms per call
### same machine (pipe):
0.213967 ms per call
### same machine (TCP):
0.266633 ms per call
### same machine (UDP):
Assertion failed: (0), function accept, file transport/udp.cc, line 429.
cannot bind to inet-dgram:vs15.inf.ethz.ch:12123
### same machine with micod (TCP):
0.275467 ms per call
./bench: line 46: 71587 Abort trap              ./server -ORBIIOPAddr  
$DADDR $RC
./bench: line 47: kill: (71587) - No such process

sudo does not change anything.

is this ok? or what goes wrong here?

matthias

Re: errors on mac os x (10.5) in demo/bench

No, expected output is something like:

### same process:
0.0003 ms per call
### same machine (pipe):
0.121933 ms per call
### same machine (TCP):
0.122933 ms per call
### same machine (UDP):
0.125133 ms per call
### same machine with micod (TCP):
0.122133 ms per call

the problem you see is also observable on FreeBSD. Thanks to MacOS X
heritage I would guess you are hit by the same issue. i.e. the problem
is in MICO's udp transport, but so far nobody was able to fix it.

Cheers,
Karel

Matthias Ringwald wrote:
> Hi
> 
> if I run demo/bench, I get the following output.
> 
> $ [sudo] ./bench
> 
> ### same process:
> 0.000733333 ms per call

Some issues / problems

Hi,

We are using mico for one of our projects inhouse, and we falsely got
the impression that mico was not maintained any more (no releases,
debian packages vanishing, and no time to really investigate the
issues.). Yesterday, I had some time to look at the mico website, and
found out that mico still is actively worked on, and I think that we
may have something to contribute.

Building mico (latest release) and our software with GCC 4.3.1, we
stumbled over some bugs and warnings. We fixed them inhouse by patching
the mico source, being unaware that some of them were already fixed in
darcs HEAD.

The first issue were lots of warnings about deprecated casts of string
literals to char*, all of those seem fixed in mico head.

Some other issue are the strict alias warnings, which are worked-around
with -fno-strict-aliasing both inhouse and in darcs HEAD. As this is
only a workaround which also disables some optimizations, we intend to
"really" fix those issues, but I can't give any promise or timeline.
Also, I don't know whether someone else is working on this issue.

The next one was the issue in idl/codegen-midl.cc where insert_guid()
was writing into a string constant. The fix you provided in HEAD seems
to look like a memory leak to me, as the string should be freed with
CORBA::string_free() at the end.

We had a different fix for that, which also has the advantage that it
does allocate the buffer on the stack which is cheaper on most

Re: Some issues / problems

On Tue, 8 Jul 2008, Markus Schaber wrote:

> We are using mico for one of our projects inhouse, and we falsely got
> the impression that mico was not maintained any more (no releases,
> debian packages vanishing, and no time to really investigate the
> issues.). Yesterday, I had some time to look at the mico website, and
> found out that mico still is actively worked on, and I think that we
> may have something to contribute.

Just for your info: MICO is indeed actively worked on. We are currently 
involved in some ports of large scale, mission critical systems to 
MICO. As part of one of these projects, we will soon release a new 
MICO version.
The silence on this list does not mean that nothing is happening. Just 
what's happening is too "sensitive" for a public list...

Cheers,
Rudi
------------------------------------------------------------------------
Rudolf Schreiner, CTO, ObjectSecurity Ltd.
St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS
Tel. +44 1223 420252, Fax. +44  870 762 6041
USA: Tel.+1-800-898-9148, Fax +1-360-933-9591
ras <at> objectsecurity.com, www.objectsecurity.com
------------------------------------------------------------------------

mico-2.3.12 and gcc-4.3.0

Hi,

I have just realized that mico-2.3.12 needs a minor patch to make it compilable by gcc-4.3.0 (on Fedora 9,
i386).  Two additional includes are added to CORBA.h, as shown in the attached diff output.  May be it can be
useful.  However, I do not have a pre-4.3.0 gcc at this time to verify if it is all right with older versions of
the compiler.

Hann Wei

_______________________________________________
Mico-devel mailing list
Mico-devel <at> mico.org
http://www.mico.org/mailman/listinfo/mico-devel

Re: Some issues / problems

Hi,

Markus Schaber wrote:
> Hi,
> 
> We are using mico for one of our projects inhouse, and we falsely got
> the impression that mico was not maintained any more (no releases,
> debian packages vanishing, and no time to really investigate the
> issues.). Yesterday, I had some time to look at the mico website, and
> found out that mico still is actively worked on, and I think that we
> may have something to contribute.
> 
> Building mico (latest release) and our software with GCC 4.3.1, we
> stumbled over some bugs and warnings. We fixed them inhouse by patching
> the mico source, being unaware that some of them were already fixed in
> darcs HEAD.
> 
> The first issue were lots of warnings about deprecated casts of string
> literals to char*, all of those seem fixed in mico head.
> 
> Some other issue are the strict alias warnings, which are worked-around
> with -fno-strict-aliasing both inhouse and in darcs HEAD. As this is
> only a workaround which also disables some optimizations, we intend to
> "really" fix those issues, but I can't give any promise or timeline.
> Also, I don't know whether someone else is working on this issue.

as far as I know nobody is working on strict aliasing issue yet. I've
investigated this just shortly few years ago and was satisfied with the
-fno-strict-aliasing workaround although as you mentioned this is not

Re: mico-2.3.12 and gcc-4.3.0

Hi,

could you be so kind and give a try to
http://mico.org/snapshots/mico-2008-07-17.tar.bz2 snapshot on your
platform? I think patches provided by Marcus Schaber just few days ago
should also fix build failure on your platform. If not, then I'm happy
to merge your fixes too (but at least IMHO cstring include should be
needless as Marcus included string.h in throw.h)

Thanks for testing!
Karel

Hann Wei Toh wrote:
> Hi,
> 
> I have just realized that mico-2.3.12 needs a minor patch to make it compilable by gcc-4.3.0 (on Fedora 9,
i386).  Two additional includes are added to CORBA.h, as shown in the attached diff output.  May be it can be
useful.  However, I do not have a pre-4.3.0 gcc at this time to verify if it is all right with older versions of
the compiler.
> 
> Hann Wei
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mico-devel mailing list
> Mico-devel <at> mico.org
> http://www.mico.org/mailman/listinfo/mico-devel

Re: Some issues / problems

Hi Marcus,

I'm cc-ing mico-devel, since this might be of interest to others as well.

Markus Schaber wrote:
> Hi, Karel,
> 
> Karel Gardas <kgardas <at> objectsecurity.com> wrote:
> 
>>> Some other issue are the strict alias warnings, which are worked-around
>>> with -fno-strict-aliasing both inhouse and in darcs HEAD. As this is
>>> only a workaround which also disables some optimizations, we intend to
>>> "really" fix those issues, but I can't give any promise or timeline.
>>> Also, I don't know whether someone else is working on this issue.
>> as far as I know nobody is working on strict aliasing issue yet. I've
>> investigated this just shortly few years ago and was satisfied with the
>> -fno-strict-aliasing workaround although as you mentioned this is not
>> optimal solution. If you do have idea how to fix it, I'm happy to
>> discuss it with you here. (I don't remember exactly, but IIRC it was
>> something to do with marshaling/un-marshaling using unions...)
> 
> OK, then I'll have a look into this issue. However, I'll be on vacation
> the next week, so don't hold your breath.

That's perfectly OK. I think this might be a little bit destabilizing
change and so this will not go into 2.3.13 anyway. FYI: 2.3.13 should be
out sometime in next 2 weeks or so.

>> Not applied as this breaks build on any platform without finite with