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

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

Currently there is no such option. You might want to customize how your "development session" objects are encoded. Like in DateAndTime... you can look at these methods: #fuelAccept: #serializeOn: #materializeFrom: (at class-side) Or you can tell fuel to ignore some instance variables, if you override #fuelIgnoredInstanceVariableNames at class-side. Both alternatives are covered in the documentation http://rmod.lille.inria.fr/web/pier/software/Fuel (which is sadly down in this moment, but will be up again soon) MartÃn On Mon, Oct 28, 2013 at 4:10 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi Martin, > > Thanks for the answer, I have another question. Is there any way to tell > Fuel to serialize only the object with its instance variables and thatâs it? > > I donât want Fuel to traverse any reference, just the object with its > fields. > > Thanks, > Roberto > > On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > I don't remember the previous discussion. When you tell fuel to > serialize an object, it traverses the references of that object *to* other > objects. By default, it uses some criteria to prune the traversal. For > example, when the traversed object is a class, then it encodes the name of > that class. Similar for a method. > > > > So I think in some way your object is referencing that problematic block > closure. > > > > Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: > > > > Maybe a "self haltIf: anObject isClosure" > > > > HTH, > > MartÃn > > > > > > On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > > Hi, > > > > Iâm struggling with Fuel and I probably discovered my problem. > > > > When trying to serialize an object (that represents a development > session, i.e., contains some meta-data (title, author, etc.) and some > objects representing actions of the developer) I often encounter problem > with some BlockClosureâs which are somewhat corrupt and Fuel crashes and > cannot serialize them. We already discussed this issue in this mailing list > a while ago with Max. > > > > I do not ask directly Fuel to serialize some BlockClosures, so my > intuition is that Fuel serializes all the references to the objects I am > trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > > > Cheers and thanks for the help, > > Roberto > > > > >

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by roberto.minelli＠usi.ch

Hi Martin, Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it? I donât want Fuel to traverse any reference, just the object with its fields. Thanks, Roberto On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. > > So I think in some way your object is referencing that problematic block closure. > > Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: > > Maybe a "self haltIf: anObject isClosure" > > HTH, > MartÃn > > > On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi, > > Iâm struggling with Fuel and I probably discovered my problem. > > When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max. > > I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > Cheers and thanks for the help, > Roberto >

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. So I think in some way your object is referencing that problematic block closure. Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: Maybe a "self haltIf: anObject isClosure" HTH, MartÃn On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi, > > Iâm struggling with Fuel and I probably discovered my problem. > > When trying to serialize an object (that represents a development session, > i.e., contains some meta-data (title, author, etc.) and some objects > representing actions of the developer) I often encounter problem with some > BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot > serialize them. We already discussed this issue in this mailing list a > while ago with Max. > > I do not ask directly Fuel to serialize some BlockClosures, so my > intuition is that Fuel serializes all the references to the objects I am > trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > Cheers and thanks for the help, > Roberto >

Oct. 28, 2013

Re: [Pharo-dev] github repository documentation

by Camillo Bruni

On 2013-10-28, at 15:16, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Oct 28, 2013 at 11:02 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> https://github.com/pharo-project/pharo-project-proposals >> https://github.com/pharo-project/pharo-ubuntu >> https://github.com/pharo-project/pharo-flyers > > > I will do it for these 3 nice :)

Oct. 28, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by Camillo Bruni

On 2013-10-27, at 20:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Oct 27, 2013, at 6:18 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Things got updated: >> >> The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has >> now a version number check + the recent pharo version allows the #update command line handler >> to detect if wrong update files were specified. Together with Stef's fix to always >> merge updates the update process should now be more stable. > Tx camillo. > > Pay attention that my change is to ignore conflict warning I am not fully sure about that, since there are two steps required: 1. MCMergeOrLoadWarning 2. MergeResolutionRequest >From what I got, you only deal with the first one, which asks the user if he wants to merge or not (which for instance in git never happens). The second one actually does the merging. I am pretty much convinced that we don't need the two of them, since I see that we basically spread the following code all over the place: [aLoadBlock on: MCMergeOrLoadWarning do: [ :request | request merge ]] on: MCMergeResolutionRequest do: [ :request | request autoMerge ]. The real merge conflict is only available in the MCMergeResolutionRequest, before it is a warning that is solely based on whether a package is dirty or not, a very crude approximation of a conflict...

Oct. 28, 2013

Re: [Pharo-dev] github repository documentation

by Damien Cassou

On Mon, Oct 28, 2013 at 11:02 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > https://github.com/pharo-project/pharo-project-proposals > https://github.com/pharo-project/pharo-ubuntu > https://github.com/pharo-project/pharo-flyers I will do it for these 3 -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 28, 2013

Re: [Pharo-dev] SmalltalkHub red

by Stephan Eggermont

SmalltalkHub uses Seaside 3.0.8, referring to an old version of Grease. Upgrading to a newer Seaside should solve that problem, AFAIK Stephan

Oct. 28, 2013

Re: [Pharo-dev] Url deprecated

by Henrik Johansen

On 28 Oct 2013, at 11:22 , Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Oct 2013, at 11:19, phil(a)highoctane.be wrote: > >> FWIW I also have serious issues with MetacelloToolBox against an FTP repository. > > We should remove FTP. FTP is evil: the passed is passed in the clear, it is old, it makes > problems with NAT and firewalls. > > FTP should *not* be used in 2013! > > Marcus By the first criteria, shouldnât we remove HTTP repositories as well? Base64 isnât much less plaintext than normal plaintext :) IMHO, from a security POV theyâre both usable if connecting to a local/VPNâed repository on a properly firewalled network. Which also gives an answer to the NAT/firewall dilemma, you shouldnât use FTP directly over the internet anyways. What *would* be nice, is a warning when you add a repository with an insecure authentication protocol, that it better not be accessed through public networks . Cheers, Henry

Oct. 28, 2013

Re: [Pharo-dev] Url deprecated

by Esteban A. Maringolo

+1 to FTP. Esteban A. Maringolo 2013/10/28 phil(a)highoctane.be <phil(a)highoctane.be> > FTP is easy, and setting up a monticello repo like this takes no time. > Especially on whatever shared hosting account, my NAS, on my own box where > I can share the package-cache folder that way. > > And it can be browsed as well. > > I am not in the mood of maintaining an STH instance with mongo and friends. > > I tried filetree and gitfiletree but those weren't supporting my workflow > easily enough (and for some reason, I got a corrupt something w/ Bitbucket > which let me fight with it for a full damn day). > > Keep FTP alive. > > Phil >

Oct. 28, 2013

Re: [Pharo-dev] Url deprecated

by Goubier Thierry

Le 28/10/2013 11:18, Sven Van Caekenberghe a Ã©crit : > Thierry, > > ZnUrl now implements #mcRepositoryAsUser:withPassword: though it is currently a hack. > Do you have a suggestion how to make it extendable ? > I will think about it as well, I do have some ideas. Well, I would just move the schemeName on the repository class and add a fromUrl:asUser:withPassword: in the repository instance creation, and change the mcRepositoryAsUser:withPassword: to search among repository types based on the scheme in the url and dispatch with a call to fromUrl:asUser:withPassword: on the right repository class. Thierry > Sven > > On 28 Oct 2013, at 11:18, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Hi All, >> >> Url has been deprecated. What is to be done with the Monticello use of the subclasses of Url? >> >> At the moment, ZnUrl has a hardcoded case switch to redirect on the right type of repository [1], but... It's not extendable, and breaks gitfiletree://. >> >> [1] https://github.com/pharo-project/pharo-core/blob/e89b4ac70d5cef761667317d58… >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 28, 2013