Hello, I just wanted to say that the only way I could come up with to overcome this problem was to load the pickles, create the modules and then pass them as arguments to the RemoteClass. So far, I still haven't tested whether RemoteClass can create instances of MyClass or not but at least I got rid of the warning.
2012/6/29 Khadija EL MAHRSI <khadija.elmah...@gmail.com> > Thank you for taking the time to consider my problem. > > 2012/6/29 jorge.pelizz...@gmail.com <jorge.pelizz...@gmail.com> > > >> 1 - you get that warning when trying to unpickle MyClass, right? >> > > I'm guessing the warning is rather caused by some other class which uses > the RemoteClass instance (This other class needs one of RemoteClass' > attributes to assign it to one of its own attributes). I assume the error > occurs because the RemoteClass instance isn't created correctly because of > the problem with the pickle. > > >> >> 2 - do you mean you have successfully unpickled it in a different >> application and also instantiated it? >> > > Yes. > > >> >> 3 - currently everything is running on the same machine? >> > > Yes. > > >> >> 4 - in the final system, will the producer application of MyClass and its >> consumer app (where RemoteClass reside) be running concurrently? >> > > I'm sorry but I'm not quite sure I understand what you mean. All I can say > is that the different instances (whether it is RemoteClass, MyClass or > anything else) are running independently. If I understood your question, > I'd say yes. > > >> >> 5 - what exactly are you pickling in MyClass.ozf? A class or a functor >> exporting the class? In the latter case, make sure you apply the functor >> before trying to access the class and instantiate it. >> > > It's the second case and I used Module.apply to be able to create > instances of MyClass. > > >> >> 6 - any chance you show us some actual code? >> > > The problem with this is that the code is quite big and complicated which > is why I tried to isolate the problem. However, I might be able to show a > specific part of the code if requested. > > >> >> Jorge. >> >> >> >> >> Enviado por Samsung Mobile >> >> >> Khadija EL MAHRSI ** escreveu: >> >> What I'm trying to pickle is a .ozf file of a class I've created; I tried >> pickling the file in another application and it worked just fine. >> Maybe I should explain what the failing application is supposed to do so >> that you would get a better idea on it and maybe be able to find the >> problem. >> In my application, I'm trying to achieve the following (hopefully it's >> not a far-fetched idea): >> First, I create a remote stationary instance of a class (let's call it >> RemoteClass). This RemoteClass instance is running on a remote site and is >> supposed to be able to load a pickle which would allow it to create >> instances of some other class (MyClass for example) on the site where it >> resides. It's MyClass' ozf file that I'm trying to pickle but fail to do >> so. For the moment, I'm trying to test this on localhost using the URL " >> http://127.0.0.1:8080/oz/MyClass.ozf"; and nginx. >> I know this seems a little complicated so if you need further details, >> feel free to ask. Also, if you notice anything wrong that I'm doing, please >> tell me. It's really important that I solve this problem. >> >> Thanks. >> >> 2012/6/29 Jorge Marques Pelizzoni <jorge.pelizz...@gmail.com> >> >>> Humm, I guess I got why your application fails with no explanation. It >>> is actually not failing, but rather HANGING on a variable somewhere, >>> waiting for it to get determined. You must be pickling something that >>> is not exactly what you intend. Make sure there are no variables >>> anywhere in the value you are trying to pickle. Consider if you should >>> not be pickling a TICKET to that thing. >>> >>> Jorge. >>> >>> 2012/6/29 Khadija EL MAHRSI <khadija.elmah...@gmail.com>: >>> > I get a "*** Warning: marshaling a variable as a resource!" which is >>> not >>> > very specific and I'm not sure what could be the cause of this warning >>> so I >>> > figured that maybe displaying the exception would be more helpful but >>> if >>> > this is the same exception that I might get either way, I'm afraid I >>> may >>> > never know the problem :-( >>> >>> _________________________________________________________________________________ >>> mozart-users mailing list >>> mozart-users@mozart-oz.org >>> http://www.mozart-oz.org/mailman/listinfo/mozart-users >>> >> >> >> >> _________________________________________________________________________________ >> mozart-users mailing list >> mozart-users@mozart-oz.org >> http://www.mozart-oz.org/mailman/listinfo/mozart-users >> > >
_________________________________________________________________________________ mozart-users mailing list mozart-users@mozart-oz.org http://www.mozart-oz.org/mailman/listinfo/mozart-users
