- Pharo-dev - lists.pharo.org

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

by Marcus Denker

> > > Great, Thierrys solution works. > > But I think there is still a problem with RGMethodDefinition. We call > self compiledMethod > on a RGMethodDefintion, the implementation *always* returns the compiled method from the system, if > it exists (regardless whether this ring method is active or not). > > I think we should either > - don't call #compiledMethod on ring definitions > - always return nil for not active definitions > - for non active definitions: create a compiled method on demand > > what do you think? Returning nil might be goodâ¦ because non-active ones model methods that are not installed and have no compiled method. But then, the problem is that we use non active Ring definitions as a replacement of what was MethodReferenceâ¦ so we need to check if that breaks anything. Another thing we need to check is all uses of Ring: e.g. SystemNavigation. Do we need Ring there? In general, we need to do another pass over Ring in the context of the remote development project. Marcus

Aug. 25, 2015

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

by Nicolai Hess

2015-08-24 18:21 GMT+02:00 stepharo <stepharo(a)free.fr>: > 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>: > >> > >> > 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 >> >> >> > > Great, Thierrys solution works. But I think there is still a problem with RGMethodDefinition. We call self compiledMethod on a RGMethodDefintion, the implementation *always* returns the compiled method from the system, if it exists (regardless whether this ring method is active or not). I think we should either - don't call #compiledMethod on ring definitions - always return nil for not active definitions - for non active definitions: create a compiled method on demand what do you think?

Aug. 25, 2015

Stability of configurations

by HernÃ¡n Morales Durand

I would like to know your opinion on the following issue: Some supposedly stable published configurations are not loading properly. I read once Stef or someone else commented about validating configurations. I agree completely with such idea because guarantees quality. For example I tried to load Chalten stable (.13) in Pharo 4 and a modal window display this message: This package depends on the following classes: MinusInfinityClassTest ArithmeticObjectIntervalTest InfinityClassTest You must resolve these dependencies before you will be able to load these definitions: testAsTimeSpan testDaysMeasure testDaysMeasure So, the package is stable but not its configuration? Is this issue on the table for Pharo 5? HernÃ¡n

Aug. 25, 2015

Versionner and BaselineOf

by Sean P. DeNigris

For projects developed with git, BaselineOfXyzs replace ConfigurationOfXyzs. What are the plans to update Versionner for this development? I've gotten spoiled and I'm not enjoying writing BaselineOfs by hand! :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-and-BaselineOf-tp4845411.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 25, 2015

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

by Thierry Goubier

Hi Paul, do you still see some of this in one of the filetree branches when doing metacello integration testing? Thierry Le 24/08/2015 19:41, Paul DeBruicker a Ã©crit : > 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

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

by Thierry Goubier

Le 24/08/2015 18:11, stepharo a Ã©crit : > I wanted to harvest the changes in squeak to have MCName but I failed a > couple of years ago. Do you know what those changes are? Many of the things I thought were wrong with MC naming a while ago do not matter anymore once moved to git. Now MC naming quirks are just annoying :( > Now relying on name is a bad idea (we got sometimes burnt by that). The numbering is user-friendly, but unreliable... A safe numbering would be less user-friendly, IMO. Thierry > > 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] [Pharo-users] issue with large file path on windows

by Ben Coman

On Mon, Aug 24, 2015 at 8:44 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-08-24 13:34 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> >> On 23 Aug 2015, at 6:09 , Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> And If you want to review the changes: >> >> >> https://github.com/nicolaihess/pharo-vm/compare/master...nicolaihess:win-lo… >> >> >> 2015-08-23 13:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> For those who had problems with pharo on windows and github based >>> repositories, >>> I built a windows vm with support for long paths: >>> >>> >>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>> >>> >>> For browsing directories with large paths (FileList or Inspect), >>> you may need one additional change in the image (But I am not really >>> sure about that) : >>> >>> DiskStore>>initialize >>> super initialize. >>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ 32767 ]. >>> >>> >>> please test and give feedback. >>> >>> This wasn't as easy as I thought, and I had to make some more changes >>> for the file permissions (the stat-functions don't work for files with >>> long paths). >>> Please test other file/folder operations. >>> >>> >> - Is an alloca version really worth it for the potential problems? >> > > It is what Marcel used for the long path support in the squeak vm (I would > have copy and paste the whole change, but I couldn't find the appropriate > change for directory functions). > > "Potential problems" sounded like something interesting I could learn. Here is a summary... http://stackoverflow.com/questions/5807612/on-the-use-and-abuse-of-alloca On the use and abuse of alloca * alloca five times faster than malloc (but is that necessary given file operations likely take longer anyway?) * most concerns with alloca no problem here e.g. its a very short lifespan; the pointer is not returned from the function. http://www.strchr.com/alloca The Perils of alloca() * remaining concern is potential stack exhaustion... * is MAX_LONG_FILE_PATH=32kB significant today (but also consider embedded application) ? * counter argument, primitive functions are not likely to entered recursively ? Microsoft advises alloca [1] deprecated in favour of malloca [2] which allocates either stack or heap depending on requested size [1] https://msdn.microsoft.com/en-us/library/wb1s57t5(v=vs.80).aspx [2] https://msdn.microsoft.com/en-us/library/5471dc8s(VS.80).aspx https://sourceware.org/ml/libc-alpha/2012-06/msg00246.html An example of a DIY malloca... * might have the advantage of tuning MAX_ALLOCA_CUTOFF post-compilation * minGW gcc might not have malloca * if large allocations go on the heap, maybe MAX_LONG_FILE_PATH test not required, just MAX_ALLOCA_CUTOFF ---------- btw, perhaps rename CONVERT_MULTIBYTE_TO_WIDECHAR_PATH to ALLOC_WIDECHAR_PATH_FROM_MULTIBYTE or similar so its more obviously symmetrical with FREE_WIDECHAR_PATH. cheers -ben

Aug. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 6e5dad: 50267

by Marcus Denker

Nope. I will open a new issue, i guess it interates the wrong slice (I made the mistake that I renamed the issueâ¦ one should never rename an issue where a slide is submitted for the original thing). > On 24 Aug 2015, at 19:55, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 6e5dad7eb6771d49eabe5009bb2725f5add6e959 > https://github.com/pharo-project/pharo-core/commit/6e5dad7eb6771d49eabe5009… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-08-24 (Mon, 24 Aug 2015) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50266.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50267.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50266.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50267.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50267 > 16358 Can not commit three changed method to class TemporaryVariable > https://pharo.fogbugz.com/f/cases/16358 > > http://files.pharo.org/image/50/50267.zip > >

Aug. 24, 2015

[pharo-project/pharo-core] 6e5dad: 50267

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 6e5dad7eb6771d49eabe5009bb2725f5add6e959 https://github.com/pharo-project/pharo-core/commit/6e5dad7eb6771d49eabe5009… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-24 (Mon, 24 Aug 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50266.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50267.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50266.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50267.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50267 16358 Can not commit three changed method to class TemporaryVariable https://pharo.fogbugz.com/f/cases/16358 http://files.pharo.org/image/50/50267.zip

Aug. 24, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 24, 2015