February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Voyage: GC collecting random objects?

by Bernat Romagosa

OK! It looks like it's working now! Thank you so much! :) Bernat. p.s. After garbage collection, #selectAll is really slow. I guess this is normal as all objects have to be retrieved all over from the DB, is this right? 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > no, isVoyageRoot mark the objects of the graph that you want as roots. All > the others are just embedded objects. > Just try adding enableMissingContent to class "D" (I don't know what is > the real name in your case :) > > Esteban > > > > On Feb 8, 2013, at 12:39 PM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > Hmm I'm not sure I understand. Now I've tried not even having the objects > stored in a classvar at all, but saving them from a materialized fuel file > straight away: > > *(FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | > each save ].* > > It's all ok and working, until I do *Smalltalk garbageCollect* and there > goes the "Reference not found" error again, without me having removed any > object. > > Would making ALL of my classes respond *true* to *#isVoyageRoot* fix the > issue? > > Thanks again! > > Bernat. > > p.s. se entiende el idioma, no el contenido, pero eso es culpa mÃa! jeje > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > >> yes, this is what happens: >> >> You have a graph that can look like this: >> >> A->b->c->D >> >> where A and D represent roots of voyage (#isVoyageRoot = true) >> >> you removed D, but A is not updated (the logic for auto update references >> is too complex, and this is a known limitation of voyage). >> So, in a next cycle you try to bring A to the image, and A is trying to >> load eagerly an instance of D... which does not exists anymore, so you have >> the error. >> To prevent this kind of problems, I use something that I call "eventual >> integrity" :) you can configure your collection to not fail when you try to >> get it and it does not exists. For achieve that, you have to add a setting >> to the class you want to take as "lazy deletable" (is a very dangerous >> property to just allow it by defect). >> You have to do something like this: >> >> D class>>#mongoContainer >> <mongoContainer> >> ^VOMongoContainer new >> enableMissingContent; >> yourself >> >> note that who is enabling missing content is D, not A :) >> >> hope it helps. >> >> Cheers, >> Esteban >> >> ps: y si no se entiende nada, mandame un mail privado y lo explico en >> espaÃ±ol :) >> >> On Feb 8, 2013, at 12:12 PM, Bernat Romagosa < >> tibabenfortlapalanca(a)gmail.com> wrote: >> >> It says "Reference not found", and the method signaling the error is >> VOMongoMaterializer >> #missingContentFor:id: >> >> I can try to set up a minimal test case and sent it to you, would that >> help? >> >> Thanks! >> >> >> 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> >> >>> Hi, >>> >>> Voyage should keep a weak cache... objects should be disposed as soon as >>> they are not used anymore. >>> Now... it is saying "Reference not found", or "Lazy reference not found"? >>> >>> Esteban >>> >>> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>> Hi! >>> >>> We've been trying to migrate the data of our Iliad webapp to Voyage, and >>> so far everything was going great, until the garbage collector collected >>> objects it shouldn't have... Here's what we did: >>> >>> We used to have all objects stored in an Instances classVar belonging to >>> their own classes, so: >>> >>> >>> 1. I had our classes return true to *#isVoyageRoot* >>> 2. *ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i >>> save ]]* >>> 3. I checked MongoDB and all was looking great. From Pharo, we could >>> get all our instances and explore all of their relationships by *OurClass >>> selectAll*. Everything was working, so we thought we didn't need the >>> image stored instances anymore, thus: >>> 4. *ourClasses do: [ :c | c classVarNamed: #Instances put: nil ]* >>> 5. *Smalltalk garbageCollect* >>> 6. *RMUser selectAll* â (long delay) â BOOM â 'Reference not found >>> RMUser: OID(3725800612)' >>> >>> So, should we actually keep references to our instances in the image? I >>> doubt this is the case, cos that'd mean we still have the 2Gb storage >>> limitation, and then having an external DB would not be helping much... >>> >>> Thanks a lot in advance! >>> >>> Bernat. >>> >>> p.s. I've also tried saving copies of my objects, but the result's been >>> the same, after garbage-collecting, I lose references. >>> >>> -- >>> Bernat Romagosa. >>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> >> >> > > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Esteban Lorenzano

no, isVoyageRoot mark the objects of the graph that you want as roots. All the others are just embedded objects. Just try adding enableMissingContent to class "D" (I don't know what is the real name in your case :) Esteban On Feb 8, 2013, at 12:39 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hmm I'm not sure I understand. Now I've tried not even having the objects stored in a classvar at all, but saving them from a materialized fuel file straight away: > > (FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | each save ]. > > It's all ok and working, until I do Smalltalk garbageCollect and there goes the "Reference not found" error again, without me having removed any object. > > Would making ALL of my classes respond true to #isVoyageRoot fix the issue? > > Thanks again! > > Bernat. > > p.s. se entiende el idioma, no el contenido, pero eso es culpa mÃa! jeje > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > yes, this is what happens: > > You have a graph that can look like this: > > A->b->c->D > > where A and D represent roots of voyage (#isVoyageRoot = true) > > you removed D, but A is not updated (the logic for auto update references is too complex, and this is a known limitation of voyage). > So, in a next cycle you try to bring A to the image, and A is trying to load eagerly an instance of D... which does not exists anymore, so you have the error. > To prevent this kind of problems, I use something that I call "eventual integrity" :) you can configure your collection to not fail when you try to get it and it does not exists. For achieve that, you have to add a setting to the class you want to take as "lazy deletable" (is a very dangerous property to just allow it by defect). > You have to do something like this: > > D class>>#mongoContainer > <mongoContainer> > > ^VOMongoContainer new > enableMissingContent; > yourself > > note that who is enabling missing content is D, not A :) > > hope it helps. > > Cheers, > Esteban > > ps: y si no se entiende nada, mandame un mail privado y lo explico en espaÃ±ol :) > > On Feb 8, 2013, at 12:12 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > >> It says "Reference not found", and the method signaling the error is VOMongoMaterializer >> #missingContentFor:id: >> >> I can try to set up a minimal test case and sent it to you, would that help? >> >> Thanks! >> >> >> 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> >> Hi, >> >> Voyage should keep a weak cache... objects should be disposed as soon as they are not used anymore. >> Now... it is saying "Reference not found", or "Lazy reference not found"? >> >> Esteban >> >> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: >> >>> Hi! >>> >>> We've been trying to migrate the data of our Iliad webapp to Voyage, and so far everything was going great, until the garbage collector collected objects it shouldn't have... Here's what we did: >>> >>> We used to have all objects stored in an Instances classVar belonging to their own classes, so: >>> >>> I had our classes return true to #isVoyageRoot >>> ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i save ]] >>> I checked MongoDB and all was looking great. From Pharo, we could get all our instances and explore all of their relationships by OurClass selectAll. Everything was working, so we thought we didn't need the image stored instances anymore, thus: >>> ourClasses do: [ :c | c classVarNamed: #Instances put: nil ] >>> Smalltalk garbageCollect >>> RMUser selectAll â (long delay) â BOOM â 'Reference not found RMUser: OID(3725800612)' >>> So, should we actually keep references to our instances in the image? I doubt this is the case, cos that'd mean we still have the 2Gb storage limitation, and then having an external DB would not be helping much... >>> >>> Thanks a lot in advance! >>> >>> Bernat. >>> >>> p.s. I've also tried saving copies of my objects, but the result's been the same, after garbage-collecting, I lose references. >>> >>> -- >>> Bernat Romagosa. >> >> >> >> >> -- >> Bernat Romagosa. > > > > > -- > Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Bernat Romagosa

(I've tried making all objects be voyageRoot and still no luck) 2013/2/8 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Hmm I'm not sure I understand. Now I've tried not even having the objects > stored in a classvar at all, but saving them from a materialized fuel file > straight away: > > *(FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | > each save ].* > > It's all ok and working, until I do *Smalltalk garbageCollect* and there > goes the "Reference not found" error again, without me having removed any > object. > > Would making ALL of my classes respond *true* to *#isVoyageRoot* fix the > issue? > > Thanks again! > > Bernat. > > p.s. se entiende el idioma, no el contenido, pero eso es culpa mÃa! jeje > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > >> yes, this is what happens: >> >> You have a graph that can look like this: >> >> A->b->c->D >> >> where A and D represent roots of voyage (#isVoyageRoot = true) >> >> you removed D, but A is not updated (the logic for auto update references >> is too complex, and this is a known limitation of voyage). >> So, in a next cycle you try to bring A to the image, and A is trying to >> load eagerly an instance of D... which does not exists anymore, so you have >> the error. >> To prevent this kind of problems, I use something that I call "eventual >> integrity" :) you can configure your collection to not fail when you try to >> get it and it does not exists. For achieve that, you have to add a setting >> to the class you want to take as "lazy deletable" (is a very dangerous >> property to just allow it by defect). >> You have to do something like this: >> >> D class>>#mongoContainer >> <mongoContainer> >> ^VOMongoContainer new >> enableMissingContent; >> yourself >> >> note that who is enabling missing content is D, not A :) >> >> hope it helps. >> >> Cheers, >> Esteban >> >> ps: y si no se entiende nada, mandame un mail privado y lo explico en >> espaÃ±ol :) >> >> On Feb 8, 2013, at 12:12 PM, Bernat Romagosa < >> tibabenfortlapalanca(a)gmail.com> wrote: >> >> It says "Reference not found", and the method signaling the error is >> VOMongoMaterializer >> #missingContentFor:id: >> >> I can try to set up a minimal test case and sent it to you, would that >> help? >> >> Thanks! >> >> >> 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> >> >>> Hi, >>> >>> Voyage should keep a weak cache... objects should be disposed as soon as >>> they are not used anymore. >>> Now... it is saying "Reference not found", or "Lazy reference not found"? >>> >>> Esteban >>> >>> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>> Hi! >>> >>> We've been trying to migrate the data of our Iliad webapp to Voyage, and >>> so far everything was going great, until the garbage collector collected >>> objects it shouldn't have... Here's what we did: >>> >>> We used to have all objects stored in an Instances classVar belonging to >>> their own classes, so: >>> >>> >>> 1. I had our classes return true to *#isVoyageRoot* >>> 2. *ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i >>> save ]]* >>> 3. I checked MongoDB and all was looking great. From Pharo, we could >>> get all our instances and explore all of their relationships by *OurClass >>> selectAll*. Everything was working, so we thought we didn't need the >>> image stored instances anymore, thus: >>> 4. *ourClasses do: [ :c | c classVarNamed: #Instances put: nil ]* >>> 5. *Smalltalk garbageCollect* >>> 6. *RMUser selectAll* â (long delay) â BOOM â 'Reference not found >>> RMUser: OID(3725800612)' >>> >>> So, should we actually keep references to our instances in the image? I >>> doubt this is the case, cos that'd mean we still have the 2Gb storage >>> limitation, and then having an external DB would not be helping much... >>> >>> Thanks a lot in advance! >>> >>> Bernat. >>> >>> p.s. I've also tried saving copies of my objects, but the result's been >>> the same, after garbage-collecting, I lose references. >>> >>> -- >>> Bernat Romagosa. >>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> >> >> > > > -- > Bernat Romagosa. > -- Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Bernat Romagosa

Hmm I'm not sure I understand. Now I've tried not even having the objects stored in a classvar at all, but saving them from a materialized fuel file straight away: *(FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | each save ].* It's all ok and working, until I do *Smalltalk garbageCollect* and there goes the "Reference not found" error again, without me having removed any object. Would making ALL of my classes respond *true* to *#isVoyageRoot* fix the issue? Thanks again! Bernat. p.s. se entiende el idioma, no el contenido, pero eso es culpa mÃa! jeje 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > yes, this is what happens: > > You have a graph that can look like this: > > A->b->c->D > > where A and D represent roots of voyage (#isVoyageRoot = true) > > you removed D, but A is not updated (the logic for auto update references > is too complex, and this is a known limitation of voyage). > So, in a next cycle you try to bring A to the image, and A is trying to > load eagerly an instance of D... which does not exists anymore, so you have > the error. > To prevent this kind of problems, I use something that I call "eventual > integrity" :) you can configure your collection to not fail when you try to > get it and it does not exists. For achieve that, you have to add a setting > to the class you want to take as "lazy deletable" (is a very dangerous > property to just allow it by defect). > You have to do something like this: > > D class>>#mongoContainer > <mongoContainer> > ^VOMongoContainer new > enableMissingContent; > yourself > > note that who is enabling missing content is D, not A :) > > hope it helps. > > Cheers, > Esteban > > ps: y si no se entiende nada, mandame un mail privado y lo explico en > espaÃ±ol :) > > On Feb 8, 2013, at 12:12 PM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > It says "Reference not found", and the method signaling the error is > VOMongoMaterializer >> #missingContentFor:id: > > I can try to set up a minimal test case and sent it to you, would that > help? > > Thanks! > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > >> Hi, >> >> Voyage should keep a weak cache... objects should be disposed as soon as >> they are not used anymore. >> Now... it is saying "Reference not found", or "Lazy reference not found"? >> >> Esteban >> >> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa < >> tibabenfortlapalanca(a)gmail.com> wrote: >> >> Hi! >> >> We've been trying to migrate the data of our Iliad webapp to Voyage, and >> so far everything was going great, until the garbage collector collected >> objects it shouldn't have... Here's what we did: >> >> We used to have all objects stored in an Instances classVar belonging to >> their own classes, so: >> >> >> 1. I had our classes return true to *#isVoyageRoot* >> 2. *ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i >> save ]]* >> 3. I checked MongoDB and all was looking great. From Pharo, we could >> get all our instances and explore all of their relationships by *OurClass >> selectAll*. Everything was working, so we thought we didn't need the >> image stored instances anymore, thus: >> 4. *ourClasses do: [ :c | c classVarNamed: #Instances put: nil ]* >> 5. *Smalltalk garbageCollect* >> 6. *RMUser selectAll* â (long delay) â BOOM â 'Reference not found >> RMUser: OID(3725800612)' >> >> So, should we actually keep references to our instances in the image? I >> doubt this is the case, cos that'd mean we still have the 2Gb storage >> limitation, and then having an external DB would not be helping much... >> >> Thanks a lot in advance! >> >> Bernat. >> >> p.s. I've also tried saving copies of my objects, but the result's been >> the same, after garbage-collecting, I lose references. >> >> -- >> Bernat Romagosa. >> >> >> > > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Esteban Lorenzano

yes, this is what happens: You have a graph that can look like this: A->b->c->D where A and D represent roots of voyage (#isVoyageRoot = true) you removed D, but A is not updated (the logic for auto update references is too complex, and this is a known limitation of voyage). So, in a next cycle you try to bring A to the image, and A is trying to load eagerly an instance of D... which does not exists anymore, so you have the error. To prevent this kind of problems, I use something that I call "eventual integrity" :) you can configure your collection to not fail when you try to get it and it does not exists. For achieve that, you have to add a setting to the class you want to take as "lazy deletable" (is a very dangerous property to just allow it by defect). You have to do something like this: D class>>#mongoContainer <mongoContainer> ^VOMongoContainer new enableMissingContent; yourself note that who is enabling missing content is D, not A :) hope it helps. Cheers, Esteban ps: y si no se entiende nada, mandame un mail privado y lo explico en espaÃ±ol :) On Feb 8, 2013, at 12:12 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > It says "Reference not found", and the method signaling the error is VOMongoMaterializer >> #missingContentFor:id: > > I can try to set up a minimal test case and sent it to you, would that help? > > Thanks! > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > Voyage should keep a weak cache... objects should be disposed as soon as they are not used anymore. > Now... it is saying "Reference not found", or "Lazy reference not found"? > > Esteban > > On Feb 8, 2013, at 11:46 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > >> Hi! >> >> We've been trying to migrate the data of our Iliad webapp to Voyage, and so far everything was going great, until the garbage collector collected objects it shouldn't have... Here's what we did: >> >> We used to have all objects stored in an Instances classVar belonging to their own classes, so: >> >> I had our classes return true to #isVoyageRoot >> ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i save ]] >> I checked MongoDB and all was looking great. From Pharo, we could get all our instances and explore all of their relationships by OurClass selectAll. Everything was working, so we thought we didn't need the image stored instances anymore, thus: >> ourClasses do: [ :c | c classVarNamed: #Instances put: nil ] >> Smalltalk garbageCollect >> RMUser selectAll â (long delay) â BOOM â 'Reference not found RMUser: OID(3725800612)' >> So, should we actually keep references to our instances in the image? I doubt this is the case, cos that'd mean we still have the 2Gb storage limitation, and then having an external DB would not be helping much... >> >> Thanks a lot in advance! >> >> Bernat. >> >> p.s. I've also tried saving copies of my objects, but the result's been the same, after garbage-collecting, I lose references. >> >> -- >> Bernat Romagosa. > > > > > -- > Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Ciprian Teodorov

Hi, I'm not particulary knowledgeable of inner workings of Iliad or voyage. But I think you should have a look at ghostproxy http://rmod.lille.inria.fr/web/pier/software/Marea/GhostProxies. The idea being that after storing your objects you should keep proxies to them in the image. These proxies would replace your objects and have knowledge of how to retrieve them from voyage. Something like that is done by the marea project. http://rmod.lille.inria.fr/web/pier/software/Marea Cheers On Feb 8, 2013 11:48 AM, "Bernat Romagosa" <tibabenfortlapalanca(a)gmail.com> wrote: > Hi! > > We've been trying to migrate the data of our Iliad webapp to Voyage, and > so far everything was going great, until the garbage collector collected > objects it shouldn't have... Here's what we did: > > We used to have all objects stored in an Instances classVar belonging to > their own classes, so: > > > 1. I had our classes return true to *#isVoyageRoot* > 2. *ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i > save ]]* > 3. I checked MongoDB and all was looking great. From Pharo, we could > get all our instances and explore all of their relationships by *OurClass > selectAll*. Everything was working, so we thought we didn't need the > image stored instances anymore, thus: > 4. *ourClasses do: [ :c | c classVarNamed: #Instances put: nil ]* > 5. *Smalltalk garbageCollect* > 6. *RMUser selectAll* â (long delay) â BOOM â 'Reference not found > RMUser: OID(3725800612)' > > So, should we actually keep references to our instances in the image? I > doubt this is the case, cos that'd mean we still have the 2Gb storage > limitation, and then having an external DB would not be helping much... > > Thanks a lot in advance! > > Bernat. > > p.s. I've also tried saving copies of my objects, but the result's been > the same, after garbage-collecting, I lose references. > > -- > Bernat Romagosa. >

Feb. 8, 2013

Re: [Pharo-project] [Update] Zinc-SSO now supports Dropbox !

by Sabine KnÃ¶fel

Hi, thank you, I have it running now. Now I can adopt it in my application. Thank you very much for your help, Sven and Jan! Sabine On Fri, Feb 8, 2013 at 11:51 AM, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hi, > > The Zinc-SSO-Seaside-Support package contains Seaside configuration classes > for the required configuration data of the different OAuth/OpenID providers. > When you use these classes you don't have to hardcode the specific > consumerKey and consumerSecret in your code but you can use the Seaside > config web page to setup the correct values. > > See ZnSSOSeasideDemo>>#register for an example. > > If you want to run the demo you need a registration with at least one of the > SSO providers. > > Jan. > > > On Fri, Feb 8, 2013 at 11:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Gofer it >> url: 'http://mc.stfx.eu/ZincHTTPComponents'; >> package: 'ConfigurationOfZincHTTPComponents'; >> load. >> >> ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. >> >> Gofer it >> url: 'http://mc.stfx.eu/ZincHTTPComponents'; >> package: 'Zinc-Seaside'; "not necessary, updating to the latest >> version" >> package: 'Zinc-SSO-Seaside-Support'; >> package: 'Zinc-SSO-Seaside-Demo'; >> load. >> >> Should load all necessary code (provided you have Seaside already), no ? >> >> But running it is another matter: you need to setup all the providers. >> I have done this, but using Jan's credentials, but these can of course not >> be shared. >> I would guess that the demo will not do anything unless these are set up. >> >> Jan, what can be done about this ? >> >> On 08 Feb 2013, at 10:37, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >> >> > Hi Sven, >> > >> > I loaded ConfigurationOfZincHTTPComponents '2.3.2' from >> > http://mc.stfx.eu. >> > With this, I have the ZnSSOSeasideDemo loaded. >> > >> > But in the register method of ZnSSOSeasideDemo , there are classes >> > referenced, which are not loaded with this Conf. >> > Where can I find them? >> > ZnOpenIDConfiguration, >> > ZnOAuth1TwitterConfiguration, >> > ZnOAuth2FacebookConfiguration, >> > ZnOAuth2GoogleConfiguration, >> > ZnOAuth2MicrosoftConfiguration. >> > >> > Greetings >> > Sabine >> > >> > On Fri, Feb 8, 2013 at 9:08 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> > wrote: >> > >> > On 07 Feb 2013, at 17:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > >> Where can I find the code/package of the seaside demo app from Jan? >> > > >> > > It is in the main Zn repository: http://mc.stfx.eu >> > >> > Make that http://mc.stfx.eu/ZincHTTPComponents >> > >> > There is no GUI to this repository, it is storage only. >> > >> > Sven >> > >> > >> >> >

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Bernat Romagosa

It says "Reference not found", and the method signaling the error is VOMongoMaterializer >> #missingContentFor:id: I can try to set up a minimal test case and sent it to you, would that help? Thanks! 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > Voyage should keep a weak cache... objects should be disposed as soon as > they are not used anymore. > Now... it is saying "Reference not found", or "Lazy reference not found"? > > Esteban > > On Feb 8, 2013, at 11:46 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > Hi! > > We've been trying to migrate the data of our Iliad webapp to Voyage, and > so far everything was going great, until the garbage collector collected > objects it shouldn't have... Here's what we did: > > We used to have all objects stored in an Instances classVar belonging to > their own classes, so: > > > 1. I had our classes return true to *#isVoyageRoot* > 2. *ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i > save ]]* > 3. I checked MongoDB and all was looking great. From Pharo, we could > get all our instances and explore all of their relationships by *OurClass > selectAll*. Everything was working, so we thought we didn't need the > image stored instances anymore, thus: > 4. *ourClasses do: [ :c | c classVarNamed: #Instances put: nil ]* > 5. *Smalltalk garbageCollect* > 6. *RMUser selectAll* â (long delay) â BOOM â 'Reference not found > RMUser: OID(3725800612)' > > So, should we actually keep references to our instances in the image? I > doubt this is the case, cos that'd mean we still have the 2Gb storage > limitation, and then having an external DB would not be helping much... > > Thanks a lot in advance! > > Bernat. > > p.s. I've also tried saving copies of my objects, but the result's been > the same, after garbage-collecting, I lose references. > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Esteban Lorenzano

Hi, Voyage should keep a weak cache... objects should be disposed as soon as they are not used anymore. Now... it is saying "Reference not found", or "Lazy reference not found"? Esteban On Feb 8, 2013, at 11:46 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi! > > We've been trying to migrate the data of our Iliad webapp to Voyage, and so far everything was going great, until the garbage collector collected objects it shouldn't have... Here's what we did: > > We used to have all objects stored in an Instances classVar belonging to their own classes, so: > > I had our classes return true to #isVoyageRoot > ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i save ]] > I checked MongoDB and all was looking great. From Pharo, we could get all our instances and explore all of their relationships by OurClass selectAll. Everything was working, so we thought we didn't need the image stored instances anymore, thus: > ourClasses do: [ :c | c classVarNamed: #Instances put: nil ] > Smalltalk garbageCollect > RMUser selectAll â (long delay) â BOOM â 'Reference not found RMUser: OID(3725800612)' > So, should we actually keep references to our instances in the image? I doubt this is the case, cos that'd mean we still have the 2Gb storage limitation, and then having an external DB would not be helping much... > > Thanks a lot in advance! > > Bernat. > > p.s. I've also tried saving copies of my objects, but the result's been the same, after garbage-collecting, I lose references. > > -- > Bernat Romagosa.

Feb. 8, 2013

[Pharo-project] [update 2.0] #20524

by Marcus Denker

20524 ----- Issue 7027: Wrong halo handle balloon text showing http://code.google.com/p/pharo/issues/detail?id=7027 Diff information: http://ss3.gemstone.com/ss/Pharo20/MorphicTests-MarcusDenker.66.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1347.diff

Feb. 8, 2013