- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] e600c1: 50266

by Marcus Denker

> > 16358 Can not commit three changed method to class TemporaryVariable > https://pharo.fogbugz.com/f/cases/16358 > aarghâ¦ monkey checked one, integrator integrated the other. Will do another updateâ¦ Marcus

Aug. 24, 2015

Re: [Pharo-dev] Random access to meta repos?

by Paul DeBruicker

per this discussion: https://github.com/dalehenrich/metacello-work/issues/354 You might check that your copy of MCFileRepositoryInspector>>#refresh doesn't refer to a nonexistent instvar Uko2 wrote > Hi, > > Iâve noticed that when I try to open a gitfiletree repo, before displaying > its contents something from meta repos is loaded (seen on screenshot). Why > does it need file names from meta repos to display contents of the repo > which is present on my machine? > > Uko > > > > > > Screen Shot 2015-08-21 at 19.06.39.png (587K) > <http://forum.world.st/attachment/4845061/0/Screen%20Shot%202015-08-21%20at%2019.06.39.png> -- View this message in context: http://forum.world.st/Random-access-to-meta-repos-tp4845061p4845346.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50266 Home: https://github.com/pharo-project/pharo-core

Aug. 24, 2015

[pharo-project/pharo-core] e600c1: 50266

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e600c10119392bde5ca6dd0865607762f684f3a4 https://github.com/pharo-project/pharo-core/commit/e600c10119392bde5ca6dd08… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-24 (Mon, 24 Aug 2015) Changed paths: M BlueInk-Core.package/BIConfigurableFormatter.class/instance/private/needsMethodSignatureOnMultipleLinesFor_.st A Monticello.package/MCRepository.class/instance/error handling/retryOnCredentialRequest_.st M Monticello.package/MCRepository.class/instance/storing/storeVersion_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50265.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50266.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50265.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50266.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyAtPutPersistent.st M Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyBlockPersistent.st M Slot-Tests.package/TemporaryVariableTest.class/instance/properties/testPropertyContextPersistent.st Log Message: ----------- 50266 16119 Monticello doent ask for user credidentials https://pharo.fogbugz.com/f/cases/16119 16219 BIConfigurableFormatter>>#needsMethodSignatureOnMultipleLinesFor: uses to:do: instead of with:do: https://pharo.fogbugz.com/f/cases/16219 16358 Can not commit three changed method to class TemporaryVariable https://pharo.fogbugz.com/f/cases/16358 http://files.pharo.org/image/50/50266.zip

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by stepharo

This is really nice to have people like you guys around. This is a really nice example where the sum is more than its elements Stef Le 24/8/15 16:44, Thierry Goubier a Ã©crit : > > > 2015-08-24 16:32 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>>: > > > > > solves loading Sven test packages. Marcus, can you try on yours? > > > > Yes! Very good! > > > Slice pushed to 16358. We'll see what the tests say. > > Why has it started to fail? All the involved code is old. > > Thierry > > Marcus > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by stepharo

indeed we extracted a chunkImporter or something like that out of crappy code logic. Le 24/8/15 17:08, Thierry Goubier a Ã©crit : > > > 2015-08-24 16:53 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > > > 2015-08-24 16:07 GMT+02:00 Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: > > Hi Nicolai, > > I think you're right. But why irregular errors? > > > Good question, important question, because we need to know what > may have been wrongly imported. > > can you check this: > > MCMczReader>>loadDefinitions > definitions := OrderedCollection new. > (self zip memberNamed: 'snapshot.bin') ifNotNil: > [:m | [^ definitions := (MCDataStream on: m contentStream) > next definitions] > on: Error do: [:fallThrough]]. > "otherwise" > (self zip membersMatching: 'snapshot/*') > do: [:m | self extractDefinitionsFrom: m]. > > and replace > on: Error do: [:fallThrough]]. > with > on: Error do: [:fallThrough | self halt]]. > > some package can be loaded without error. But some throwing errors > (for example: Error: Improper store into indexable object) and > the falltrough in the original code follow the > second "otherwise" path, and this is the reason why some package > loadings modify the MCDefinition cache and some not. > > > I don't know enough of the adding path to be sure, but I wonder if the > use of Ring as an intermediary to and from MCMethodDefinition isn't > new, and exercising those paths. You may be pointing something else. > > A short difference with Pharo4 shows that yes, Pharo5 goes through > Ring and not Pharo4. > > (see MCPackage>>#snapshot, changed in late june) > > Thierry > > > Ok, for that particular method, with Zinc smalltalkhub repo > open and Zn-Tests.231 selected (this forces a read of the mcz > definitions in the image), what I have is: > > ZnEntityTests>>#testUnspecifiedEncoding -> old version. > ok > MCMethodDefinition cachedDefinitions at: > ZnEntityTests>>#testUnspecifiedEncoding -> new version > ok > ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition -> > old version > ok > ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition > asMCMethodDefinition -> new version > not ok. > > Thierry > > 2015-08-24 15:37 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > > > On 24 Aug 2015, at 15:31, Nicolai Hess > <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > > > > Can someone look at > > > > RGMethodDefinition>>#asMCMethodDefinition > > I think this method uses one cache > > (MCMethodDefinition cachedDefinitions) > > even for both, methods from the MCPackage and methods > from the image package, > > of course, they should not be equal. But they are index > by the compiledMethod > > and this is always the compiled method of the existing > method in the image (RGMethodDefinition>>compiledMethod) > > > > But if this is the cause of this bug, I would guess we > see much more strange errors..... > > Well, Stef reported a problem a couple of days ago, then > Marcus another one, and now mine. All with versions, > changes, code loading. > > > 2015-08-24 15:06 GMT+02:00 Martin Dias > <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>>: > > > > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > > > > > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > I have to concur, something very strange is wrong. > > > > #50265 > > > > Load Zinc-Tests-SvenVanCaekenberghe.231 from > http://mc.stfx.eu/ZincHTTPComponents > > > > ZnEntityTests>>#testUnspecifiedEncoding should have > today as latest version and it simply does not (the code > is wrong too), I can't imagine how that is possible. > > > > And this is with loading code ... seems quite dangerous. > > > > Fun: copying Zinc-Tests-SvenVanCaekenberghe.231 to a > filetree repo, then loading from the filetree is correct, > at least for ZnEntityTests>>#testUnspecifiedEncoding > > > > #50265 > > > > Strange. Once the MCDefinitions are loaded (repository > type dependent, that), the code path is > repository-independent, no? > > > > Strange. Does this happen for all changed methods, or > only some of them? > > > > > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by stepharo

I know that we got a similar behavior with franck. It looks like the metadata of the package was confused. Stef Le 24/8/15 12:05, Marcus Denker a Ã©crit : > Hi, > > I have a *very* strange bug. > > I am trying to add change these three methods in class âTemporaryVariableâ: > (I copy the new version): > > > ensureProperties > method saveTemp: self. > ^ Properties at: self ifAbsentPut: WeakKeyDictionary new > > removePropertiesIfEmpty > ^ Properties at: self ifPresent: [ :dict | > dict ifEmpty: [ > method removeSavedTemp: self. > Properties removeKey: self ] ] > > hash > > ^ (name hash > bitXor: method hash) > bitXor: (startpc ifNil: 0) > > > Now when I save the MC package, these changes are *not* saved, even though when I diff against the repository > of Pharo5, they are shown as different. > > The only special things I did is to move TemporaryVariable to a new tag some updates ago. And I had extension > methods in *slot where the same thing happened, but that was fixed by putting them into *Slot. > > This looks like some wired RPackage problem. But the RPackage seems to correctly know TemporaryVariable and these three selectors > as local from the package Slot. > > I really have no idea what the problem could be. > > Marcus >

Aug. 24, 2015

Re: [Pharo-dev] Random access to meta repos?

by stepharo

I wanted to harvest the changes in squeak to have MCName but I failed a couple of years ago. Now relying on name is a bad idea (we got sometimes burnt by that). Stef Le 24/8/15 00:00, Thierry Goubier a Ã©crit : > Le 23/08/2015 22:00, Yuriy Tymchuk a Ã©crit : >> Thanks Thierry! >> >> Iâm not completely aware about the issue details, but maybe it makes >> sense to change something in metacello itself? > > No, not really, or maybe in a very complex way... > > The issue is inside Monticello, in the way the Monticello GUI > interacts with each package version history, and how that interacts > with the lazy version info I added late in the Pharo 4 development cycle. > > The Monticello GUI is designed to be able to display the newer/not > newer version feedback (you know, the underlined, bold, non bold > package version status you see in a repository) out of two things: > first the complete knowledge of the complete version history of all > the packages loaded in the image. And second, the names of the mcz > files in the repository. Why the names? To avoid downloading all the > mcz in the repository to get their version history... Monticello just > pray and hopes the names are right... Oh, by the way, Gofer also prays > and hopes that the names are right when you are loading something via > a configuration and a script[*]. > > When I added[**] lazyness to the version history in the image, I > removed that complete history Monticello relies on (and a bit of > memory out of the image). And, as a result, this has immediately > created issues in the GUI that are taken care of as they come. Some > are simple, like the gitfiletree ones, because you get all the proper > version history with a few git commands in the repository. But you > can't do that with a http repository (smalltalkhub, squeaksource) > since you can't get the remote repository version history. > > Thierry > > [*] Which is very fun because, at times, the names aren't right... and > the wrong package get loaded. Incomprehensible pain and confusion ensue:( > > [**] I'm the second guy doing this lazy thing with Monticello. > Smalltalk/X seems to had (have?) the same thing before. Would like to > share the experience one day;) > > >> >> Uko >> >>> On 23 Aug 2015, at 20:26, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Nicolas, Uko, >>> >>> I added an optimisation to gitfiletree which avoids the unnecessary >>> loading all file names. Available on Pharo4 and Pharo5 (development >>> and stable). >>> >>> Thierry >>> >>> Le 23/08/2015 09:08, Nicolas Anquetil a Ã©crit : >>>> >>>> worse than that >>>> last week over a slow connection, I noticed that it "loaded all file >>>> names" (from Pharo40Inbox in my case) over and over again >>>> >>>> nicolas >>>> >>>> On 22/08/2015 21:29, Yuriy Tymchuk wrote: >>>>> Hi, >>>>> >>>>> Iâve noticed that when I try to open a gitfiletree repo, before >>>>> displaying its contents something from meta repos is loaded (seen on >>>>> screenshot). Why does it need file names from meta repos to display >>>>> contents of the repo which is present on my machine? >>>>> >>>>> Uko >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> >> > > >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Thierry Goubier

2015-08-24 16:53 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Nicolai, >> >> I think you're right. But why irregular errors? >> > > Good question, important question, because we need to know what may have > been wrongly imported. > > can you check this: > > MCMczReader>>loadDefinitions > definitions := OrderedCollection new. > (self zip memberNamed: 'snapshot.bin') ifNotNil: > [:m | [^ definitions := (MCDataStream on: m contentStream) next > definitions] > on: Error do: [:fallThrough]]. > "otherwise" > (self zip membersMatching: 'snapshot/*') > do: [:m | self extractDefinitionsFrom: m]. > > and replace > on: Error do: [:fallThrough]]. > with > on: Error do: [:fallThrough | self halt]]. > > some package can be loaded without error. But some throwing errors (for > example: Error: Improper store into indexable object) and > the falltrough in the original code follow the > second "otherwise" path, and this is the reason why some package loadings > modify the MCDefinition cache and some not. > I don't know enough of the adding path to be sure, but I wonder if the use of Ring as an intermediary to and from MCMethodDefinition isn't new, and exercising those paths. You may be pointing something else. A short difference with Pharo4 shows that yes, Pharo5 goes through Ring and not Pharo4. (see MCPackage>>#snapshot, changed in late june) Thierry > > >> >> Ok, for that particular method, with Zinc smalltalkhub repo open and >> Zn-Tests.231 selected (this forces a read of the mcz definitions in the >> image), what I have is: >> >> ZnEntityTests>>#testUnspecifiedEncoding -> old version. >> ok >> MCMethodDefinition cachedDefinitions at: >> ZnEntityTests>>#testUnspecifiedEncoding -> new version >> ok >> ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition -> old version >> ok >> ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition >> asMCMethodDefinition -> new version >> not ok. >> >> Thierry >> >> 2015-08-24 15:37 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> >>> > On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> > >>> > Can someone look at >>> > >>> > RGMethodDefinition>>#asMCMethodDefinition >>> > I think this method uses one cache >>> > (MCMethodDefinition cachedDefinitions) >>> > even for both, methods from the MCPackage and methods from the image >>> package, >>> > of course, they should not be equal. But they are index by the >>> compiledMethod >>> > and this is always the compiled method of the existing method in the >>> image (RGMethodDefinition>>compiledMethod) >>> > >>> > But if this is the cause of this bug, I would guess we see much more >>> strange errors..... >>> >>> Well, Stef reported a problem a couple of days ago, then Marcus another >>> one, and now mine. All with versions, changes, code loading. >>> >>> > 2015-08-24 15:06 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: >>> > >>> > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> > >>> > >>> > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> > I have to concur, something very strange is wrong. >>> > >>> > #50265 >>> > >>> > Load Zinc-Tests-SvenVanCaekenberghe.231 from >>> http://mc.stfx.eu/ZincHTTPComponents >>> > >>> > ZnEntityTests>>#testUnspecifiedEncoding should have today as latest >>> version and it simply does not (the code is wrong too), I can't imagine how >>> that is possible. >>> > >>> > And this is with loading code ... seems quite dangerous. >>> > >>> > Fun: copying Zinc-Tests-SvenVanCaekenberghe.231 to a filetree repo, >>> then loading from the filetree is correct, at least for >>> ZnEntityTests>>#testUnspecifiedEncoding >>> > >>> > #50265 >>> > >>> > Strange. Once the MCDefinitions are loaded (repository type dependent, >>> that), the code path is repository-independent, no? >>> > >>> > Strange. Does this happen for all changed methods, or only some of >>> them? >>> > >>> >>> >>> >> >

Aug. 24, 2015

Re: [Pharo-dev] Strange Monticello bug: methods are not saved

by Nicolai Hess

2015-08-24 16:07 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Nicolai, > > I think you're right. But why irregular errors? > Good question, important question, because we need to know what may have been wrongly imported. can you check this: MCMczReader>>loadDefinitions definitions := OrderedCollection new. (self zip memberNamed: 'snapshot.bin') ifNotNil: [:m | [^ definitions := (MCDataStream on: m contentStream) next definitions] on: Error do: [:fallThrough]]. "otherwise" (self zip membersMatching: 'snapshot/*') do: [:m | self extractDefinitionsFrom: m]. and replace on: Error do: [:fallThrough]]. with on: Error do: [:fallThrough | self halt]]. some package can be loaded without error. But some throwing errors (for example: Error: Improper store into indexable object) and the falltrough in the original code follow the second "otherwise" path, and this is the reason why some package loadings modify the MCDefinition cache and some not. > > Ok, for that particular method, with Zinc smalltalkhub repo open and > Zn-Tests.231 selected (this forces a read of the mcz definitions in the > image), what I have is: > > ZnEntityTests>>#testUnspecifiedEncoding -> old version. > ok > MCMethodDefinition cachedDefinitions at: > ZnEntityTests>>#testUnspecifiedEncoding -> new version > ok > ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition -> old version > ok > ZnEntityTests>>#testUnspecifiedEncoding asRingDefinition > asMCMethodDefinition -> new version > not ok. > > Thierry > > 2015-08-24 15:37 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> > On 24 Aug 2015, at 15:31, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > Can someone look at >> > >> > RGMethodDefinition>>#asMCMethodDefinition >> > I think this method uses one cache >> > (MCMethodDefinition cachedDefinitions) >> > even for both, methods from the MCPackage and methods from the image >> package, >> > of course, they should not be equal. But they are index by the >> compiledMethod >> > and this is always the compiled method of the existing method in the >> image (RGMethodDefinition>>compiledMethod) >> > >> > But if this is the cause of this bug, I would guess we see much more >> strange errors..... >> >> Well, Stef reported a problem a couple of days ago, then Marcus another >> one, and now mine. All with versions, changes, code loading. >> >> > 2015-08-24 15:06 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: >> > >> > On Mon, Aug 24, 2015 at 3:03 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> > >> > >> > 2015-08-24 14:43 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > I have to concur, something very strange is wrong. >> > >> > #50265 >> > >> > Load Zinc-Tests-SvenVanCaekenberghe.231 from >> http://mc.stfx.eu/ZincHTTPComponents >> > >> > ZnEntityTests>>#testUnspecifiedEncoding should have today as latest >> version and it simply does not (the code is wrong too), I can't imagine how >> that is possible. >> > >> > And this is with loading code ... seems quite dangerous. >> > >> > Fun: copying Zinc-Tests-SvenVanCaekenberghe.231 to a filetree repo, >> then loading from the filetree is correct, at least for >> ZnEntityTests>>#testUnspecifiedEncoding >> > >> > #50265 >> > >> > Strange. Once the MCDefinitions are loaded (repository type dependent, >> that), the code path is repository-independent, no? >> > >> > Strange. Does this happen for all changed methods, or only some of them? >> > >> >> >> >

Aug. 24, 2015