Hello,
I finally got rid of the warning which was caused by one of my classes that
used "IOFile".

Thanks

2010/9/10 Wolfgang Meyer <[email protected]>

> Hi again,
>
> On Fri, Sep 10, 2010 at 9:59 AM, Khadija EL MAHRSI
> <[email protected]> wrote:
> > Hello,
> > making the change you suggested made the application block completely
> > sending a bug report so I kept the old version.
>
> Ok, it looks like the encapsulated exception causes problem when it
> gets distributed in Mozart 1.3.2. We should therefore avoid its
> distribution.
> To see error messages, you could modify the
> CreateRemoteStationaryObject such that is does NOT return the
> exception, but displays it on the machine where it runs, like this:
>
> local
>   RM = {New Remote.manager init}
> in
>   fun {CreateRemoteStationaryObject Class Init}
>      functor RemoteCode
>      import Inspector
>      export result:Result
>      define
>         Result
>         %% create a stationary instance on the remote site
>         try
>            Result = {NewStat Class Init}
>         catch E then
>            Result = error
>            thread
>               {Inspector.inspect E}
>            end
>         end
>      end
>      AppliedFunctor = {RM apply(RemoteCode $)}
>   in
>      AppliedFunctor.result
>   end
> end
>
>  (This is only a short-term solution. In a real application, you
> certainly don't want to run to a remote machine to see an error
> message...)
>
>
> > The weird thing is that this warning sometimes appears and sometimes it
> > doesn't (even though I don't recall changing anything) and in both cases
> I
> > get the famous error:
> >
> > %********************** error in application *************
> > %**
> > %** Application of non-procedure and non-object
> > %**
> > %** In statement: {<Resource> getX(_<optimized>)})
> >
>
> This looks like the object was not successfully constructed, i.e.
> something went wrong in the init method. As a consequence, instead of
> calling "getX" on an object, it is erroneously called on a "failed
> value" which was (for some reason) distributed as a "resource". (Sorry
> if this sounds confusing.)
> With the above change you should be able to see the original error message.
>
> > I've noticed something, this warning appears if I click on the main.exe
> > generated after ozc -x main.oz but if ran ./main using Cygwin the warning
> > doesn't appear. Any explanation?
>
> That's strange. Maybe it has something to do with different path settings.
>
> >
> >> I don't think this is related to threads. While threads themselves
> >> cannot be distributed, objects that merely use threads should not
> >> cause problems when distributed.
> > Are you sure about this? because I don't want to change the class that
> uses
> > threads at all.
>
> I have tested a small example. I'm pretty sure that using a thread in
> the constructor does not cause problems. When a mobile object is used
> on a remote site, that thread will not magically be transferred to the
> other machine, it just continues where the object was originally
> started.
>
> >
> > I wanted to ask something about the class using threads. Since this class
> is
> > going to be used by different instances created from some other class
> (which
> > also use threads and which are stationary on the sites where they are
> > created) distributed among many sites. Is this instace going to travel
> among
> > the sites so that it can be used by all the instances that need it? If
> so,
> > is the application going to work the same way as if it weren't
> distributed
> > (because this is exactly what I want)?
> >
> Yes, by default the methods will run on the caller site and the
> object's state will be synchronized between sites. Such a mobile
> object may NOT use any sited entities like OS or QTk, though. And as
> indicated above, the thread that was started in the constructor, will
> not travel.
>
> Cheers,
>   Wolfgang
>
> _________________________________________________________________________________
> mozart-users mailing list
> [email protected]
> http://www.mozart-oz.org/mailman/listinfo/mozart-users
>
_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users

Reply via email to