- Pharo-users - lists.pharo.org

Re: [Pharo-users] Issues with recent Pharos reading files

by Alistair Grant

Hi Andrew, On 20 March 2018 at 21:42, Andrew P. Black <apblack(a)pdx.edu> wrote: > >> On 21 Mar 2018, at 03:15 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: >>> >>> Iâm having trouble reading files with the most recent âstableâ versions of Pharo. >> >> OK, this is no answer to your issue, but Pharo 7 latest is far from stable, it is intentionally the development head. >> >> It is very good that you test it and help out, more eyes and all that, but using it is at your own risk, there are no promises about stability. > > I understand this. The point of my post was to try and diagnose the issue and help make Pharo 7 more stable. > > Does my diagnosis of a missing or outdated primitive look reasonable? Not really :-) > If so, how do I check? If you can successfully open World Menu -> Tools -> File Browser then the primitive is working. > That is, where are is this primitive > > <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: errorCode > > > supposed to come from? Iâm guessing that there should be a file with âFilePluginâ somewhere in its name somewhere in one of my VMs. There isnât â although some older Cog vms from back in the day (Iâm talking Pharo 1.4) have something called > âlibAsynchFilePlugin.dylibâ Plugins can either be built-in or external. FilePlugin is built-in. > If this plugin is now essential to run Pharo, shouldnât downloading the launcher and using the launcher to grab a fresh image and launch it (after checking for the appropriate VM) be all that is required to ensure that it is installed? If not, what other steps should I take? The error handling in #lookupEntryIn:index: is less than ideal. I'm working on a replacement, so I don't think it is worthwhile spending a lot of time on it. This primitive returns a directory entry by index number. Just taking a couple of wild guesses: One possibility is that the directory was modified while you were iterating over the directory. I'm also not sure how it handles entries that you don't have permission to read. But to help track down your issue, maybe temporarily replace the code with: <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: errorCode > errorCode ifNotNil: [self halt: errorCode asString]. ^ #badDirectoryPath That should allow you to track down the issue a bit more. P.S. If the primitive really is missing, errorCode will be #'not found'. > Iâm getting on a l-o-n-g flight in a few hours, and would really like to be able to run Pharo ... > > Andrew HTH, Alistair

March 20, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by Andrew P. Black

> On 21 Mar 2018, at 03:15 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: >> >> Iâm having trouble reading files with the most recent âstableâ versions of Pharo. > > OK, this is no answer to your issue, but Pharo 7 latest is far from stable, it is intentionally the development head. > > It is very good that you test it and help out, more eyes and all that, but using it is at your own risk, there are no promises about stability. I understand this. The point of my post was to try and diagnose the issue and help make Pharo 7 more stable. Does my diagnosis of a missing or outdated primitive look reasonable? If so, how do I check? That is, where are is this primitive <primitive: 'primitiveDirectoryLookup' module: 'FilePlugin' error: errorCode > supposed to come from? Iâm guessing that there should be a file with âFilePluginâ somewhere in its name somewhere in one of my VMs. There isnât â although some older Cog vms from back in the day (Iâm talking Pharo 1.4) have something called âlibAsynchFilePlugin.dylibâ If this plugin is now essential to run Pharo, shouldnât downloading the launcher and using the launcher to grab a fresh image and launch it (after checking for the appropriate VM) be all that is required to ensure that it is installed? If not, what other steps should I take? Iâm getting on a l-o-n-g flight in a few hours, and would really like to be able to run Pharo ... Andrew

March 20, 2018

Re: [Pharo-users] Pharo sound with SDL Library

by Mariano Badoglio

Perfect! I have loaded the Merwan WAVParser project, that uses the OpenAL library and it worked fine. Best regards! Mariano El 19/03/18 a las 16:32, Stephane Ducasse escribiÃ³: > Yes we should migrate it and probably include it in Pharo and clean it. > > Stef > > On Mon, Mar 19, 2018 at 6:59 PM, Mariano Badoglio > <marianobadoglio(a)gmail.com> wrote: >> Hi Stephean, Sean, >> >> Thanks for your response. I have installed the Monticello Package >> "Sound" from http://smalltalkhub.com/mc/PharoExtras/Sound/main, the last >> update is Sound-StephaneDucasse.80 package from year 2013. It is from >> Pharo Extras. Is this the right package? >> >> Best regards, >> Mariano >> >> >> El 17/03/18 a las 16:05, Stephane Ducasse escribiÃ³: >>> Hi mariano >>> >>> did you try the sound package that is on Smalltalkhub/Pharo? or >>> PharoExtras. We should migrate it to pharo 70 >>> >>> Stef >>> >>> On Sat, Mar 17, 2018 at 1:14 PM, Mariano Badoglio >>> <marianobadoglio(a)gmail.com> wrote: >>>> Hello! >>>> >>>> I need to use the Pharo Sound over Ubuntu platform, but I couldn't get >>>> it work. I tryied sending the parameter vm-sound-OSS and vm-sound-ALSA >>>> to the vm but I get no results. >>>> >>>> I am now trying to use the SDL Library. I could initialize the sound >>>> SDL_Init(SDL_INIT_AUDIO), very similar to initializing video, but when >>>> trying to use the SDL_LoadWAV, it needs a SDL_AudioSpec data type and I >>>> do not know how to do it. I tried to use an Structure as parameter but >>>> with no result, I couldn't found any similar example to follow. I will >>>> appreciate any help or tips on this. >>>> >>>> Thanks in advance. Best regards, >>>> Mariano. >>>> >>>> >>>> >> >

March 20, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by CÃ©drick BÃ©ler

Just a side note. I had problems with Monticello ftp repo. Ok on pharo 6, not on 7 last week. Iâll try to reproduce. It was in relation to the zip file. Cheers, Cedrick EnvoyÃ© de mon iPhone > Le 20 mars 2018 Ã 15:15, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > > >> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: >> >> Iâm having trouble reading files with the most recent âstableâ versions of Pharo. > > OK, this is no answer to your issue, but Pharo 7 latest is far from stable, it is intentionally the development head. > > It is very good that you test it and help out, more eyes and all that, but using it is at your own risk, there are no promises about stability. > >

March 20, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by Sven Van Caekenberghe

> On 20 Mar 2018, at 14:36, Andrew P. Black <apblack(a)pdx.edu> wrote: > > Iâm having trouble reading files with the most recent âstableâ versions of Pharo. OK, this is no answer to your issue, but Pharo 7 latest is far from stable, it is intentionally the development head. It is very good that you test it and help out, more eyes and all that, but using it is at your own risk, there are no promises about stability.

March 20, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Sven Van Caekenberghe

> On 20 Mar 2018, at 14:51, Andrew P. Black <apblack(a)pdx.edu> wrote: > > I like the structure of streams wrapping streams from the point of view of modularity of implementation and flexibility of reuse (as in applying buffering and encoding to in-memory or network streams). > > But I donât like exposing al the machinery to the user. For example, instead of > > bufferedReadStream := ZnBufferedReadStream on: aReadStream. > bufferedWriteStream := ZnBufferedWriteStream on: aWriteStream. > > why not > > bufferedReadStream := ZnBuffer on: aReadStream. > bufferedWriteStream := ZnBuffer on: aWriteStream > > where the class that implements the buffering looks at the stream and decides whether to do read or write buffering (or both, for a read-write stream). Hmm, then I would prefer real object messages, like #buffered not class facades. > The meaning of #position: on an encoded Unicode stream is perfectly well-defined. Itâs just not the same as the meaning of position on the underlying byteStream â one counts in codePoints, the other in bytes. Yes, agreed. > The old file streams got this wrong; Iâm hoping that the new ones get it right. However, the comment that > > "As a side note: using #size and #position[:] on variable encoded streams > like UTF8 is *very* dangerous and should be avoided.â > > makes me worry that they do not. Please, either implement #size and #position[:] correctly on the encoded stream, or donât implement them at all! Do *not* implement them incorrectly, and then tell me to avoid them because they are dangerous! Well, I will repeat my opinion: #size #position #position: #reset have no place in streams. I have an experimental implementation of a ZnPositionableReadStream that adds 'excursion behaviour' as an add-on on top of more primitive streams that do not. It allows for code like stream savingPositionDo: [ "read ahead" ]. "continue reading as if noting happened" Here is the class comment. I am ZnPositionableReadStream. I am polymorphic with (the most used/important methods of) ReadStream and PositionableStream. I wrap another read stream and store the elements that I read in a sliding circular buffer so that I am able to go back to any position inside that buffer. Essentially, I implement #position and #position: to be used to back out of reading ahead. Note that the size of my buffer limits how far I can go backwards. A SubscriptOutOfBounds exception will be signalled when an attempt is made to go too far backwards. The index returned by #position should be considered abstract, without concrete meaning, but it is currently implemented as the count of elements read by #next on the wrapped stream. On a simple stream over an in memory collection, that will be equivalent to an integer index into that collection. But on network streams or streams that were already further along, this will no longer be the case. The most elementary example of my capabilities can be seen in my implementation of #peek. See also the unit tests #testPlainExcursion and #testSearch Of course, backing out of an excursion is only possible within the window of the buffer size. Implementation - stream <ReadStream> the read stream that I wrap and add positioning to - buffer <String|ByteArray> sliding, circular buffer - index <PositiveInteger> zero based index into buffer, where next will be stored - count <PositiveInteger> number of next operations done on wrapped stream - delta <PositiveInteger> number of positions that I was moved backwards The real core methods are #next, #atEnd, #position and #position: and are used to implement the rest. Part of Zinc HTTP Components

March 20, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Sven Van Caekenberghe

> On 20 Mar 2018, at 12:56, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > This is great! > And, +1 on the need for some more convenience constructors... > > Word of warning (which would be nice to mention in the guide); using > writeStreamDo: and manually constructed buffered writers will not #flush the > buffered stream automatically on close, so it's crucial this is done > manually. Yes, you are right, but it is clearly documented in the class comment of ZnBufferedWriteStream There is also ZnBufferedWriteStream class>>#on:do: to help Now, these are system classes more than user classes. Normal users should get a ready made stream not knowing much about the construction process. > charGen := Random seed: 16543986234. > output := String new: 1024*1024*50. > 1 to: output size do: [ :ix | output at: ix put: ((charGen nextInt: 256) - > 1) asCharacter ]. > > [(File named: 'utf16test.txt') writeStreamDo: [:ws | |encStream| > encStream := ZnCharacterWriteStream > on: (ZnBufferedWriteStream on: ws) > encoding: 'utf16'. > encStream nextPutAll: output > ]] timeToRun. > > FileSize: 102 336 KB. > > [(File named: 'utf16test2.txt') writeStreamDo: [:ws | |encStream| > encStream := ZnCharacterWriteStream > on: (ZnBufferedWriteStream on: ws) > encoding: 'utf16'. > encStream nextPutAll: output;flush > ]] timeToRun. > > FileSize: 102 400 KB. > > It's about 4 times slower than the corresponding > > [FileStream forceNewFileNamed: 'utf16test2.txt' do: [:ws | > ws converter: UTF16TextConverter new. > ws nextPutAll: output > ]] timeToRun > > but it's 100MB of UTF16, and 4 secs vs 1, so probably not relevant to real > use cases . Ah, but you are cheating (deliberately or not ;-). Your test string is a ByteString not a WideString, and UTF16TextConverter contains a fast path that basically does nothing. Try another string, like 1 to: output size do: [ :ix | output at: ix put: ((charGen nextInt: 1024) - 1) asCharacter ]. Zn is the same speed, the old one does not even stop for me. I am not sure we have to optimise UTF16, maybe ... adding the same fast path would not be too difficult I guess. > Another addition to the guide valuable to those of use still stuck in the > stone age, would be code equivalents to FileStream methods: > forceNewFileNamed:do: > newFileNamed:do: > oldFileNamed:do: > > Cheers, > Henry > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

March 20, 2018

Re: [Pharo-users] New Files in Pharo - Migration Guide, How To's and examples

by Andrew P. Black

I like the structure of streams wrapping streams from the point of view of modularity of implementation and flexibility of reuse (as in applying buffering and encoding to in-memory or network streams). But I donât like exposing al the machinery to the user. For example, instead of bufferedReadStream := ZnBufferedReadStream on: aReadStream. bufferedWriteStream := ZnBufferedWriteStream on: aWriteStream. why not bufferedReadStream := ZnBuffer on: aReadStream. bufferedWriteStream := ZnBuffer on: aWriteStream where the class that implements the buffering looks at the stream and decides whether to do read or write buffering (or both, for a read-write stream). The meaning of #position: on an encoded Unicode stream is perfectly well-defined. Itâs just not the same as the meaning of position on the underlying byteStream â one counts in codePoints, the other in bytes. The old file streams got this wrong; Iâm hoping that the new ones get it right. However, the comment that "As a side note: using #size and #position[:] on variable encoded streams like UTF8 is *very* dangerous and should be avoided.â makes me worry that they do not. Please, either implement #size and #position[:] correctly on the encoded stream, or donât implement them at all! Do *not* implement them incorrectly, and then tell me to avoid them because they are dangerous! Andrew

March 20, 2018

Re: [Pharo-users] Issues with recent Pharos reading files

by Cyril Ferlicot

On Tue, Mar 20, 2018 at 2:36 PM, Andrew P. Black <apblack(a)pdx.edu> wrote: > Iâm having trouble reading files with the most recent âstableâ versions of Pharo. > > Today, I downloaded Pharo (32-bit), loaded my code into the image using git and Iceberg, and half of my tests failed because Pharo claimed that the files that are on my disk are in a directory that does not exist. If I go back to an older image, everything works fine. > > Iâm seeing a similar thing on Travis-CI: the build under Pharo 6 works fine, and all the tests are green, but the build under Pharo 7 fails: > >> Loaded -> SmalltalkCI-Coverage-Core-fn.5 --- filetree:///home/travis/smalltalkCI-master/repository [:] --- cache >> SmalltalkCIPharo class>>deprecationWarning (TestCoverage is Undeclared) >> SmalltalkCIPharo7 class>>stdout (ZnCrPortableWriteStream is Undeclared) >> Loaded -> SmalltalkCI-Pharo-Core-fn.62 --- filetree:///home/travis/smalltalkCI-master/repository [:] --- cache >> ...finished baselineMessageNotUnderstood: receiver of "on:" is nil >> UndefinedObject(Object)>>doesNotUnderstand: #on: >> SmalltalkCIPharo7 class>>stdout >> SmalltalkCIPharo7 class(SmalltalkCI class)>>travisFold:id:block: >> SmalltalkCIPharo7 class(SmalltalkCI class)>>stage:id:block: >> SmalltalkCIPharo7(SmalltalkCI)>>reportImageInfo >> SmalltalkCIPharo7(SmalltalkCI)>>basicLoad >> [ super basicLoad ] in [ [ super basicLoad ] >> on: (Smalltalk at: #MCMergeOrLoadWarning) >> do: [ :ex | ex resume: true ] ] in SmalltalkCIPharo7(SmalltalkCIPharo)>>basicLoad in Block: [ super basicLoad ] > > (The logs are here: https://travis-ci.org/apblack/GraceInPharo. Look at build #83. Iâm not sure if they are public â I think that they are!) > > Whatâs weird is that my co-worker, who I was introducing to Pharo, was able to download a Pharo distribution and install and run the same git commit with no problems. > > So I decided that maybe my launcher was out of date. I just downloaded and installed a new version of the launcher. When I use it to create a new image, it is unable to launch it, because it canât find the VM. (The VM package was there, but with a âno entryâ sign across it.) > > I eventually patch up the launcher by hand, and load my code into a new image. Half of my tests fail once again. There are two issues. > > First, file streams are now ZnCharacterReadStreams instead of MultiByteFileStreams. Ok, thatâs a change that I had been expecting. But ZnCharacterReadStreams donât understand readStream, whereas MultiByteFileStreams did (and returned self). I can code around that. > > The second issue is one that I canât code around. Iâm getting a "directory does not existâ error from DiskStore>>#basicEntry:path:nodesDo:, even though the sending method, FileSystemStore>>#directoryAt:ifAbsent:nodesDo: has just correctly verified that the directory does exist. Looking at the offending method, I think that the problem is that > > Primitives lookupEntryIn: encodedPathString index: index. > > always returns #badDirectoryPath. Since this method contains a call to a primitive, followed by ^ #badDirectoryPath if the primitive fails, Iâm guessing that either I donât have the primitive installed, or I have an old version of the primitive. > > How do I fix this? More interesting in some ways: if I download a new copy of the launcher, and then use the launcher to install a new copy of the development image, shouldnât all of the necessary files be installed along with it. > > From the fact that this isnât working on Travis either, Iâm guessing that there might be a problem with the distribution. > > Andrew > > > Hi, Fast answer, I did not had the time to check for a long time. I see it the logs: SmalltalkCIPharo7 class>>stdout (ZnCrPortableWriteStream is Undeclared) I think ZnCrPortableWriteStream was renamed into ZnNewLineWriterStream. Maybe it is SmalltalkCI who need to adapt? Probably this method: https://github.com/hpi-swa/smalltalkCI/blob/master/repository/SmalltalkCI-P… -- Cyril Ferlicot https://ferlicot.fr

March 20, 2018

Issues with recent Pharos reading files

by Andrew P. Black

Iâm having trouble reading files with the most recent âstableâ versions of Pharo. Today, I downloaded Pharo (32-bit), loaded my code into the image using git and Iceberg, and half of my tests failed because Pharo claimed that the files that are on my disk are in a directory that does not exist. If I go back to an older image, everything works fine. Iâm seeing a similar thing on Travis-CI: the build under Pharo 6 works fine, and all the tests are green, but the build under Pharo 7 fails: > Loaded -> SmalltalkCI-Coverage-Core-fn.5 --- filetree:///home/travis/smalltalkCI-master/repository [:] --- cache > SmalltalkCIPharo class>>deprecationWarning (TestCoverage is Undeclared) > SmalltalkCIPharo7 class>>stdout (ZnCrPortableWriteStream is Undeclared) > Loaded -> SmalltalkCI-Pharo-Core-fn.62 --- filetree:///home/travis/smalltalkCI-master/repository [:] --- cache > ...finished baselineMessageNotUnderstood: receiver of "on:" is nil > UndefinedObject(Object)>>doesNotUnderstand: #on: > SmalltalkCIPharo7 class>>stdout > SmalltalkCIPharo7 class(SmalltalkCI class)>>travisFold:id:block: > SmalltalkCIPharo7 class(SmalltalkCI class)>>stage:id:block: > SmalltalkCIPharo7(SmalltalkCI)>>reportImageInfo > SmalltalkCIPharo7(SmalltalkCI)>>basicLoad > [ super basicLoad ] in [ [ super basicLoad ] > on: (Smalltalk at: #MCMergeOrLoadWarning) > do: [ :ex | ex resume: true ] ] in SmalltalkCIPharo7(SmalltalkCIPharo)>>basicLoad in Block: [ super basicLoad ] (The logs are here: https://travis-ci.org/apblack/GraceInPharo. Look at build #83. Iâm not sure if they are public â I think that they are!) Whatâs weird is that my co-worker, who I was introducing to Pharo, was able to download a Pharo distribution and install and run the same git commit with no problems. So I decided that maybe my launcher was out of date. I just downloaded and installed a new version of the launcher. When I use it to create a new image, it is unable to launch it, because it canât find the VM. (The VM package was there, but with a âno entryâ sign across it.) I eventually patch up the launcher by hand, and load my code into a new image. Half of my tests fail once again. There are two issues. First, file streams are now ZnCharacterReadStreams instead of MultiByteFileStreams. Ok, thatâs a change that I had been expecting. But ZnCharacterReadStreams donât understand readStream, whereas MultiByteFileStreams did (and returned self). I can code around that. The second issue is one that I canât code around. Iâm getting a "directory does not existâ error from DiskStore>>#basicEntry:path:nodesDo:, even though the sending method, FileSystemStore>>#directoryAt:ifAbsent:nodesDo: has just correctly verified that the directory does exist. Looking at the offending method, I think that the problem is that Primitives lookupEntryIn: encodedPathString index: index. always returns #badDirectoryPath. Since this method contains a call to a primitive, followed by ^ #badDirectoryPath if the primitive fails, Iâm guessing that either I donât have the primitive installed, or I have an old version of the primitive. How do I fix this? More interesting in some ways: if I download a new copy of the launcher, and then use the launcher to install a new copy of the development image, shouldnât all of the necessary files be installed along with it. >From the fact that this isnât working on Travis either, Iâm guessing that there might be a problem with the distribution. Andrew

March 20, 2018