Kretschel Klaus | 1 Jul 09:52 2008
Picon

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}

(Continue reading)

Ashish Kumar Sharma | 4 Jul 09:04 2008

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,
> 
(Continue reading)

Matthias Ringwald | 4 Jul 15:06 2008
Picon

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
Karel Gardas | 4 Jul 15:37 2008

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
(Continue reading)

Markus Schaber | 8 Jul 11:42 2008

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
(Continue reading)

Rudolf Schreiner | 8 Jul 14:33 2008

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
------------------------------------------------------------------------
Hann Wei Toh | 9 Jul 10:25 2008
Picon

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
Attachment (mico2312diff-for-gcc43): application/octet-stream, 578 bytes
_______________________________________________
Mico-devel mailing list
Mico-devel <at> mico.org
http://www.mico.org/mailman/listinfo/mico-devel
Karel Gardas | 17 Jul 15:55 2008

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
(Continue reading)

Karel Gardas | 17 Jul 16:49 2008

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
(Continue reading)

Karel Gardas | 17 Jul 18:54 2008

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
(Continue reading)


Gmane