- Pharo-dev - lists.pharo.org

issue with large file path on windows

by Nicolai Hess

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. nicolai

Aug. 23, 2015

Re: [Pharo-dev] [squeak-dev] #instSize in Squeak 5 seems to be broken for Traits

by Max Leske

> On 22 Aug 2015, at 19:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Fri, Aug 21, 2015 at 2:11 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 21 Aug 2015, at 19:31, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> On Fri, Aug 21, 2015 at 8:57 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> Hi folks >> >> Iâve been trying to load Fuel into Squeak 5 but canât because I get errors when loading Traits (they have not instance variables). The reason for this error seems to be that #instSize answers 2 for Traits when it should answer 0. >> >> The current implementation is: >> >> ^format bitAnd: 16rFFFF >> >> The comment in the 4.6 version says: >> >> " >> NOTE: This code supports the backward-compatible extension to 8 bits of instSize. >> When we revise the image format, it should become... >> ^ ((format bitShift: -1) bitAnd: 16rFF) - 1 >> Note also that every other method in this category will require >> 2 bits more of right shift after the change. >> â >> >> When I use that version in TraitBehaviour>>instSize in Squeak 5 I get 0 as expected and I can load Fuel without problems. >> >> So Spur has a different layout for format than V3. The above implementation (format bitAnd: 16rFFFF) is correct for Spur. In loading classes or traits via Fuel from 4.6 to 5.0 you're going to have to convert the format inst var to reflect its usage in Spur. So we need to be clear here. >> >> Is the issue that you're trying to load classes and/or traits from a Fuel file written by 4.6 or is it that as part of the Fuel load a new Trait gets created which has a format of 2? > > The latter. This is reproducible by simply creating a new Trait: > > Trait named: #NewTrait > uses: #() > category: ânew catâ. > NewTrait instSize ââ> 2â > > I just took a look at this and it doesn't reproduce. I'm using a trunk Squeak 5 image and I get 0 and required. ? Thanks Eliot. Youâre right. The problem is not with #instSize, I donât know how I managed to get the aboveâ¦ The problem is actually, that TApplyingOnClassSide (which is already present) has a format of 2: TApplyingOnClassSide instSize ââ> 2â Also, all Traits in the image have format 2, while new Traits have format 0: format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. Smalltalk allTraits size = format2 size ââ> true" Trait named: #NewTrait uses: #() category: 'new catâ. NewTrait instSize ââ> 0" format2 := Smalltalk allTraits select: [ :e | e format = 2 ]. Smalltalk allTraits size = format2 size ââ> falseâ This is with build 15113 (which is trunk I suppose). Cheers, Max > > Cheers, > Max > >> >> >> Cheers, >> Max >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot

Aug. 23, 2015

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

by Thierry Goubier

Le 23/08/2015 12:14, stepharo a Ã©crit : > I think that it is trying to get every information. And yes we would > gain all if we can understand this issue. Found it; it's lazy loading the version info of a package. Thierry > > Le 23/8/15 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. 23, 2015

Re: [Pharo-dev] Monkey validation report statistics

by stepharo

HI ben you are right. We are all running like mad. We are focusing on the bootstrap because guille will leave to brussels end of the month. Esteban is fighting with FFI to get migrating to Spur. But yes this issue is a real one. Stef Le 23/8/15 04:08, Ben Coman a Ã©crit : > Is there somewhere that statistics of failures from the CI validation > report are gathered? > > We've all experienced transient CI-monkey validation failures > unrelated to our submitted fix, where just resubmitting to the monkey > without change works fine. The problem is: > > * this may have been introduced several builds ago, but the transient > failure passed the monkey at the time > > * it can be hard to identify which build introduced a transient error > > * doubly hard if the failure is due to some CI infrastructure change, > or one particular build server > > * its hard to get an overview of how many issues get the same failure > - is this a "once in six months" failure or is it happening 50% of the > time in every issue. > > * it takes longer for an individual to observes a false-failure is > common enough to worry about, than if reports were merged. Since > different slices should produce different errors, failures common > across all slices should stand out in statistics. > > If such statistics are not currently available, in cases where a > simple resubmission passed the monkey, should we: > > * have an issue for each such false-failure, to get some early > indication from manually track occurrences > > * where such an issue hasn't yet been created, first report comes to the list > > ------ > So, I just got the following false-failures in separate runs for: > https://pharo.fogbugz.com/f/cases/16265 > * ProcessTerminateBug>>#testTerminationDuringUnwind > * a CISmallIntRule: Timeout (after 0:00:40:00) occured while loading... > > Anyone else? > > cheers -ben > > P.S. I understand some errors are filtered. Can this list be output as > part of the validation report (or is it already) ? > >

Aug. 23, 2015

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

by stepharo

I think that it is trying to get every information. And yes we would gain all if we can understand this issue. Le 23/8/15 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. 23, 2015

Re: [Pharo-dev] Confused about libFT2Plugin

by Sven Van Caekenberghe

You are right, Hilaire, the freetype lib does not pull in X11, problem solved, thanks a lot! > On 23 Aug 2015, at 07:40, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 20/08/2015 15:08, Sven Van Caekenberghe a Ã©crit : >> Yes, of course, but isn't that an X11 library that will pull in all of X11 and friends on a server that does not need a GUI ? I run all my servers pure command line, out of principle. >> > > Are you sure libfreetype depends on X11? > > hilaire@pchome ~ $ apt-cache show libfreetype6 > Package: libfreetype6 > Priority: optional > Section: libs > Installed-Size: 895 > Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> > Original-Maintainer: Steve Langasek <vorlon(a)debian.org> > Architecture: amd64 > Source: freetype > Version: 2.5.2-1ubuntu2.4 > Depends: libc6 (>= 2.14), libpng12-0 (>= 1.2.13-4), zlib1g (>= 1:1.1.4) > > Hilaire > -- > Dr. Geo > > http://drgeo.eu > http://google.com/+DrgeoEu

Aug. 23, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Yuriy Tymchuk

Maybe I cannot debug metacello correctly :) but this is what Iâve managed to come up with. Also there was no issue with loading it 2 days ago. Uko > On 23 Aug 2015, at 12:02, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Something is wrong here. MagritteGlamourForPharo40 should ideally not depend on GT-Inspector, and GT-Inspector certainly does not reside in the Glamour repo. > > Cheers, > Doru > > > On Sun, Aug 23, 2015 at 10:08 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi, > > when I load VoyageMongo in Pharo 4, it loads MagritteGlamourForPharo40 which loads Magritte3 which loads MagritteGlamourForPharo40 which needs GT-Inspector-SeanDeNigris.308 from http://www.smalltalkhub.com/mc/Moose/Glamour/main <http://www.smalltalkhub.com/mc/Moose/Glamour/main> and it is not there. > > Any clues? > Uko > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Aug. 23, 2015

Re: [Pharo-dev] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Tudor Girba

Something is wrong here. MagritteGlamourForPharo40 should ideally not depend on GT-Inspector, and GT-Inspector certainly does not reside in the Glamour repo. Cheers, Doru On Sun, Aug 23, 2015 at 10:08 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > when I load VoyageMongo in Pharo 4, it loads MagritteGlamourForPharo40 > which loads Magritte3 which loads MagritteGlamourForPharo40 which > needs GT-Inspector-SeanDeNigris.308 from > http://www.smalltalkhub.com/mc/Moose/Glamour/main and it is not there. > > Any clues? > Uko > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 23, 2015

VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Yuriy Tymchuk

Hi, when I load VoyageMongo in Pharo 4, it loads MagritteGlamourForPharo40 which loads Magritte3 which loads MagritteGlamourForPharo40 which needs GT-Inspector-SeanDeNigris.308 from http://www.smalltalkhub.com/mc/Moose/Glamour/main <http://www.smalltalkhub.com/mc/Moose/Glamour/main> and it is not there. Any clues? Uko

Aug. 23, 2015

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

by Nicolas Anquetil

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. 23, 2015