August 2015 - Pharo-dev - lists.pharo.org

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

by Sean P. DeNigris

Uko2 wrote > 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. I probably broke it by trying to get the Magritte GT integration enhancements in Pharo 4.0. The baseline of Magritte is broken into several methods, making it prohibitive to create a new baseline, so I broke the cardinal rule and changed an existing baseline. I'll take a look this morning. But immediately, I can say that nobody should load MagritteGlamourForPharo40 directly. It is a way that Magritte uses internally to load a few enhancements to Glamour and GT required for Pharo 4.0. ----- Cheers, Sean -- View this message in context: http://forum.world.st/VoyageMongo-Could-not-resolve-GT-Inspector-GT-Inspect… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Ben Coman

On Sun, Aug 23, 2015 at 10:02 PM, Merwan Ouddane <merwanouddane(a)gmail.com> wrote: > Hi, > > I made a WAV parser, so now we can play music in Pharo :) > > I made an example using OpenAL's binding from Ronnie. > > You can try it with this piece of code : > > Gofer new > smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; > package: 'ConfigurationOfWAVParser'; > load. > (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. > (Smalltalk at: #ALExamplesWAV) exampleBirdChirping > > Merwan > This is great! I never pushed at trying sound since I had the impression there were issues on some platforms and it hadn't been critical for me, but trying your example worked out of the box in build 50264 on OSX Mavericks. Actually it took me a few moments to notice it was the playback and not some birds outside. Made me grin from ear to ear. Probably not critical, but I get informed "Information - The size in the header do not match the real size. The file may be corrupted." In WavParser>>sanityCheckFileSize... stream size --> 215608 header fileSize -> 215600 cheers -ben

Aug. 23, 2015

Re: [Pharo-dev] Monkey validation report statistics

by Ben Coman

They seem like the right priorities. We have a work around to report it manually for now. Just wanted to get the idea on the list while I thought of it. cheers -ben On Sun, Aug 23, 2015 at 6:15 PM, stepharo <stepharo(a)free.fr> wrote: > 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

WAV support in Pharo

by Merwan Ouddane

Hi, I made a WAV parser, so now we can play music in Pharo :) I made an example using OpenAL's binding from Ronnie. You can try it with this piece of code : Gofer new smalltalkhubUser: 'MerwanOuddane' project: 'WAVParser'; package: 'ConfigurationOfWAVParser'; load. (Smalltalk at: #ConfigurationOfWAVParser) loadBleedingEdge. (Smalltalk at: #ALExamplesWAV) exampleBirdChirping Merwan

Aug. 23, 2015

Re: [Pharo-dev] issue with large file path on windows

by stepharo

Thanks for trying to fix this issue! Le 23/8/15 13:44, Nicolai Hess a Ã©crit : > 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] VoyageMongo "Could not resolve: GT-Inspector [GT-Inspector-SeanDeNigris.308]"

by Ferlicot D. Cyril

Le 23/08/2015 10:08, Yuriy Tymchuk a Ã©crit : > 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 Same with Pillar: https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=40,VERSION=stable,V… -- Cheers Cyril

Aug. 23, 2015

Re: [Pharo-dev] issue with large file path on windows

by Tudor Girba

This is great news! I had tons of problems last year with that and I did not know what to do about this. Doru On Sun, Aug 23, 2015 at 1:44 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 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 > > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 23, 2015

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