- Pharo-dev - lists.pharo.org

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

by Nicolai Hess

Hi HernÃ¡n Thanks for your feedback 2015-08-24 8:13 GMT+02:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Nicolai > > 2015-08-23 8:44 GMT-03: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. >> >> > Using Win 8.1, I confirm FileList tree now is reading directories beyond > 260 limit, without need to #initialize DiskStore. > > However there should be another concern with GitFileTree uncompression > because loading Aconcagua/Chalten, etc with your new VM in a directory name > with more characters, still signals File not found :( > I tried Aconcagua from Catalogbrowser in pharo 5.0 and it worked for me. Can you show what path is the base path, the working directory of your pharo package-cache/github directory. Is there something special in your path name or the disk? > > Is the VM using the "Unicode-aware API"? According to this guys > http://serverfault.com/questions/163419/window-256-characters-path-name-lim… > such Win Unicode API would let VM to use the 32767 bricks > I am not sure, we are using all file/directory operations that should use the unicode version with multibyte char (CreateFileW / FindFirstFileW / ...) > > > 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. >> >> > Thank you Nicolai for your effort, I know it's hard to dive into depths > with C. > > HernÃ¡n > > >> nicolai >> >> >> >> >

Aug. 24, 2015

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

by HernÃ¡n Morales Durand

Nicolai 2015-08-23 8:44 GMT-03: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. > > Using Win 8.1, I confirm FileList tree now is reading directories beyond 260 limit, without need to #initialize DiskStore. However there should be another concern with GitFileTree uncompression because loading Aconcagua/Chalten, etc with your new VM in a directory name with more characters, still signals File not found :( Is the VM using the "Unicode-aware API"? According to this guys http://serverfault.com/questions/163419/window-256-characters-path-name-lim… such Win Unicode API would let VM to use the 32767 bricks 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. > > Thank you Nicolai for your effort, I know it's hard to dive into depths with C. HernÃ¡n > nicolai > > > >

Aug. 24, 2015

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

by Sean P. DeNigris

Tudor Girba-2 wrote > The dependency to Glamour should go through the #stable version Yes, ideally. But stable doesn't contain the fixes I want, and given that the Moose configs have no platform blocks, I assumed that Pharo 5.0-only code would be committed preventing loading in Pharo 4.0. Again, if I'm mistaken about any of that, I'd much rather do what you suggested. ----- 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] Random access to meta repos?

by Thierry Goubier

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

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

by Yuriy Tymchuk

Thanks Thierry! Iâm not completely aware about the issue details, but maybe it makes sense to change something in metacello itself? 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. 23, 2015

Re: [Pharo-dev] WAV support in Pharo

by Dimitris Chloupis

yeap it works fine now. The funny thing is that I have a parrot and each time I play your example my parrot signs with your example , actually he syncs his chirps with the chirps of your examples , he is pretty accurate :D On Sun, Aug 23, 2015 at 7:56 PM Merwan Ouddane <merwanouddane(a)gmail.com> wrote: > Retry now, I forgot to update the configuration > > > On 23/08/2015 18:41, Dimitris Chloupis wrote: > > it gives me MNU OpenAL class>>isAvailable > > On Sun, Aug 23, 2015 at 5:56 PM Ben Coman <btc(a)openinworld.com> wrote: > >> 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] WAV support in Pharo

by Merwan Ouddane

Thanks :) On 23/08/2015 19:30, stepharo wrote: > cool! > I blog it. :) > > > Le 23/8/15 16:02, Merwan Ouddane a Ã©crit : >> 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] WAV support in Pharo

by stepharo

cool! I blog it. :) Le 23/8/15 16:02, Merwan Ouddane a Ã©crit : > 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] Random access to meta repos?

by Thierry Goubier

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

Re: [Pharo-dev] WAV support in Pharo

by Merwan Ouddane

On 23/08/2015 18:25, Vincent BLONDEAU wrote: > Thanks! It is working better now! > > Nice tool! > Do you plan to add Mp3? (because it is the current format now ;)). Maybe one day ^^ I took WAV because it's a really easy audio format to parse. At least now we do have something working for a common format :) > > Vincent > > -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Merwan Ouddane > EnvoyÃ© : dimanche 23 aoÃ»t 2015 17:43 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] WAV support in Pharo > > Yes you have to download OpenAL for the openAL binding to work :p > > The name of the dll is OpenAL32.dll > > > On 23/08/2015 17:25, Vincent BLONDEAU wrote: >> Hi, >> >> It does not work under windows.. Should I download a specific .dll ? >> >> Cheers, >> Vincent >> >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part >> de Merwan Ouddane EnvoyÃ© : dimanche 23 aoÃ»t 2015 16:02 Ã : Pharo >> Development List Objet : [Pharo-dev] WAV support in Pharo >> >> 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