Hello, I too am using Mozart 1.3.2 and only the case that I described fails. Anyway, I have changed the features into attributes and everything is fine now.
If it's not much to ask I have yet another question. Let's say I want to use Open and not OS so this class can write something in a file whose path, for example, is the following "C:\Cygwin\home\file1.txt". Since I'm working on localhost as the remote site on which the instance is running, this path works just fine by putting it as "name:" but if I were to change localhost into some other machine, what are the changes I need to make in order to have the same result? I'm thinking of changing the "name:" into "url:" but I have to admit that I'm confused and don't know exactly what to write in this field (Is there a section in the mozart documentation that I missed and which deals with how to write urls? because even though I searched hard for such a thing I still couldn't find the answer I needed). I'm only asking for help after looking for a solution for so long that my eyes are starting to hurt from staring at my screen :-( Thanks. 2010/9/7 Boriss Mejias <[email protected]> > Dear Khadija, > > To me it fails in both cases, where Child inherits from Parent or from > GrandParent. It's important to mention that I'm using mozart-1.3.2. > > Now, since it works for you when Child inherits from GrandParent, I assume > something changed in the distribution of class features between mozart-1.3.2 > to mozart-1.4.0. I remember I did some part of the distribution of > dictionaries, but I don't know if those are related to features. Anyway, > replacing the features by object attributes works well in Mozart-1.3.2, even > if Child inherits from Parent. See the code attached (I did not modify > Main.oz). > > I hope that solves the issue with the features. Now back to the OS.rand > thing, I have some code that might help you, although I noticed in Main.oz > that you are already following the approach of sending messages through > ports, so this code will be easy for you to understand. > > At site A > > ------------------------------------------------------------------------------- > First I create the class Foo that uses {OS.rand} to assign the id of the > object. > > declare > class Foo > attr id > meth init > id := {OS.rand} > end > meth resetId > {self init} > end > meth getId($) > @id > end > end > > Then I create the port and stream that will locally forward every request > to an instance of class Foo. > > declare > P S Obj in > Obj = {New Foo init} > P = {NewPort S} > thread > for Msg in S do > {Obj Msg} > end > end > > Now I build a proxy, which is simply a procedure that sends a message to > the port. Note that ObjProxy does not include any reference to a resource. > > declare > proc {ObjProxy Method} > {Send P Method} > end > {Pickle.save {Connection.offerUnlimited ObjProxy} 'object.tket'} > > > ----------------------------------------------------------------------------- > Now the code at Site B > > ----------------------------------------------------------------------------- > > I get a reference to the proxy using the ticket, and I just use the remote > reference as if it was an object. > > declare > Remote = {Connection.take {Pickle.load 'object.tket'}} > {Browse {Remote getId($)}} > {Remote resetId} > {Browse {Remote getId($)}} > > > ----------------------------------------------------------------------------- > > I hope it helps > cheers > Boriss > > > > > On 07/09/10 11:50, Khadija EL MAHRSI wrote: > >> Hello, >> >> I've made so many tests that I don't know what to think anymore. >> I don't think I'm doing anything wrong so here is the complete code. >> In this code changing the MyClasses.oz file by writing "from >> GrandParent" will make everything work. >> If anyone has an explanation please enlighten me. >> >> Thanks. >> >> 2010/9/6 Khadija EL MAHRSI <[email protected] >> <mailto:[email protected]>> >> >> Hello again, >> I have to admit I'm really puzzled. The warning disappeared >> (apparently it doesn't appear each time that's why I didn't notice >> it earlier) and yet the error is here to stay. >> The code is basically something like this: >> class GrandParent >> attr (or feat) >> x >> y >> z >> meth init(X) >> x receives X >> y receives 78 (for example) >> end >> >> getters for x, y and z >> end >> >> class Parent from GrandParent >> meth init(X) >> GrandParent, init(X) >> z receives 'K' (for example) >> end >> end >> >> class Child from Parent >> meth init(X) >> Parent, init(X) >> z receives 'H' (for example) >> end >> end >> >> The problem I get is that if I create stationary instances of the >> class "Child" on a remote site and I try to access x, y or z I get >> the following error: >> >> %********************** error in application ************* >> %** >> %** Application of non-procedure and non-object >> %** >> %** In statement: {<Resource> getX(_<optimized>)} >> >> I want to remind that instances created from the Parent class cause >> no problem and changing "class Child from Parent" into "class Child >> from GrandParent" makes everything work. Any explanation? >> >> Thanks. >> >> >> 2010/9/6 Khadija EL MAHRSI <[email protected] >> <mailto:[email protected]>> >> >> Hello, >> you were right I get the warning in this application too but I >> didn't notice it. I will review my code and try to find out >> what's wrong otherwise I will write the code in my next message. >> >> Thanks a lot. >> >> 2010/9/6 Khadija EL MAHRSI <[email protected] >> <mailto:[email protected]>> >> >> Hello, >> I need to clarify something. In this application I don't get >> the warning it is in another application that I'm writing >> that the marshalling warning occurs. >> >> Thanks. >> >> 2010/9/6 Boriss Mejias <[email protected] >> <mailto:[email protected]>> >> >> >> On 06/09/10 10:32, Khadija EL MAHRSI wrote: >> >> Hello, >> the weird thing is that if I create an instance of >> the class "parent" on >> the remote site it works just fine. Any ideas? >> >> >> Yes, it is probably related to the resources that you >> can't export to other sites, so they are just marshalled >> as "resource/unusable" (depending on Mozart's version). >> Post the code of the parent class, and the error message >> and we might be able to help you better. >> >> cheers >> Boriss >> >> Thanks >> >> 2010/9/5 Wolfgang Meyer >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> >> >> >> Hi, >> >> there is probably something about class "parent" >> which causes problems >> on the remote site, like for example usage of a >> sited module in the >> constructor of "parent". Hard to say without >> more details. Is there >> any error message? Can you show the code of >> class "parent"? >> >> Cheers, >> Wolfgang >> >> >> On Sun, Sep 5, 2010 at 5:12 PM, Khadija EL MAHRSI >> <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> > Hello, >> > I have encountered a problem and I was wondering >> if anyone had an >> > explanation to it. >> > I have the following hierarchy: >> > class grandParent >> > class parent from grandParent >> > class child from parent >> > If I try to create an instance of the child class >> on a remote >> site, the >> > creation fails. If I write "class child from >> grandParent" instead >> of "class >> > child from parent" the creation of the child >> instance on the >> remote site is >> > successful. >> > I tried to seperate the 3 classes in 3 different >> .oz files but it >> still >> > didn't work. When working locally, the creation >> works perfectly >> using "class >> > child from parent". >> > Can anyone explain why? >> > Maybe I'm doing something wrong? Am I supposed to >> do things >> differently now >> > that the instance is being created on a remote site? >> > I need an answer. >> > Thanks. >> > >> > >> >> >> >> _________________________________________________________________________________ >> > mozart-users mailing list >> > [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> > >> http://www.mozart-oz.org/mailman/listinfo/mozart-users >> > >> >> >> >> _________________________________________________________________________________ >> mozart-users mailing list >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> http://www.mozart-oz.org/mailman/listinfo/mozart-users >> >> >> >> >> >> >> _________________________________________________________________________________ >> mozart-users mailing list [email protected] >> <mailto:[email protected]> >> http://www.mozart-oz.org/mailman/listinfo/mozart-users >> >> >> >> _________________________________________________________________________________ >> mozart-users mailing list [email protected] >> <mailto:[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 >> > > > > _________________________________________________________________________________ > 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
