July 2017 - Pharo-dev - lists.pharo.org

Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU
by Mariano Martinez Peck Aug. 2, 2017

Aug. 2, 2017

Guys, I am getting "UTF8InvalidText: Invalid utf8 input detected" quite frequently on Pharo 6.0 which come from ombu background job. Has anything seen this too? Quite annoying... This is not the first time I hit it. This time I analyzed a bit why it was failing and it's because I removed a method manually...I mean, I did MyClass removeSelector: #myMethod And the omEntry is a EpMethodRemoval which represents the exact method I deleted... Also I can see the MultiByteFileStream internal 'collection' is full of none ascii things. I can share a fuelout as well as the image with the files if you want. I can also share the ombu file in question. Contact me in private. ---- [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: UTF8InvalidText(Exception)>>signal UTF8InvalidText(Exception)>>signal: UTF8TextConverter>>errorMalformedInput UTF8TextConverter>>nextFromStream: MultiByteFileStream>>next MultiByteFileStream(PositionableStream)>>match: MultiByteFileStream(PositionableStream)>>upToAll: OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: OmBlockFileStore>>refreshNewBlocksFrom: [ :readStream | self refreshNewBlocksFrom: readStream ] in OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: in Block: [ :readStream | self refreshNewBlocksFrom: readStr...etc... [ ^ aBlockClosure value: readStream ascii ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure value: readStream ascii ] BlockClosure>>on:do: [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ... [ aBlock value: stream ] in FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock value: stream ] BlockClosure>>ensure: FileReference(AbstractFileReference)>>readStreamDo: OmBlockFileStore(OmFileStore)>>readEntriesWith: OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: [ | initialPosition initialLocalName | self entryBuffer isEmpty ifTrue: [ ^ self ]. fileReference writeStreamDo: [ :fileStream | fileStream setToEnd. initialPosition := fileStream position. initialLocalName := self entryBuffer first value. ZnBufferedWriteStream on: fileStream do: [ :aWriteStream | | anEntryWriter | anEntryWriter := self newEntryWriter. [ self entryBuffer isEmpty ] whileFalse: [ | next entry | next := self entryBuffer removeFirst. entry := next key. "Write entry to file" anEntryWriter on: aWriteStream nextEntryPut: entry ] ]. "In Linux it was necessary to explicitely flush the file stream" fileStream flush. lastStreamPosition := fileStream size ]. self refreshEntryPositionsByLocalNameStartingAt: initialPosition since: initialLocalName ] in OmBlockFileStore(OmFileStore)>>flushEntryBuffer in Block: [ | initialPosition initialLocalName |... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: OmBlockFileStore(OmFileStore)>>critical: OmBlockFileStore(OmFileStore)>>flushEntryBuffer OmDeferrer>>sendMessage [ self sendMessage ] in OmDeferrer>>flush in Block: [ self sendMessage ] -- Mariano http://marianopeck.wordpress.com

4 5

Launcher and Pharo 6.1
by Sean P. DeNigris Aug. 1, 2017

Aug. 1, 2017

Is it safe to replace the Launcher VM with the one required for Pharo 6.1? I.e. is that VM backward compatible with a Pharo 6.0 image? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Launcher-and-Pharo-6-1-tp4957770.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 3

Catalog down
by Torsten Bergmann July 31, 2017

July 31, 2017

http://catalog.pharo.org/catalog/json responds with "Service Temporarily Unavailable". Sabine already reported it this morning on Discord. Any idea?

2 1

[ANN] Mustache moved to github
by Norbert Hartl July 31, 2017

July 31, 2017

In the spirit of git notificationâ¦I moved mustache to github. https://github.com/noha/mustache <https://github.com/noha/mustache> Enjoy! Norbert

9 16

Re: [Pharo-dev] [ci-announces] IMPORTANT: Virtual Machines loss
by Volkert July 31, 2017

July 31, 2017

Out of curiosity: What is the impact on the Pharo Project? Is the build process is interrupted? Volkert On 28.07.2017 19:18, Christophe Demarey wrote: > Dear CI users, > > Due to a manipulation error, a lot of Virtual Machines hosted on > CloudStack were destroyed and are _not recoverable_! > For the projects being impacted, there is no other solution than > recreate new VMs. Please find as attachment the list of virtual > machines that are not affected. > > Jenkins servers are not concerned by this issue, so all your jobs and > history are safe. > > We are deeply sorry for this failure. > Everything was done in an effort to retrieve the lost VMs, but it has > proven to be an impossible task and the VMs cannot be restored. We are > now working on setting up safeguards to prevent such situations. > > With our sincere apologies, > The CI team. > > >

3 2

Esteban's ChangeLog week of 24 July 2017
by estebanlm＠gmail.com July 31, 2017

July 31, 2017

Hello! This is my weekly ChangeLog, from 24 July 2017 to 30 July 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=24/7/2017&to=30/7/2017 ChangeLog ========= 25 July 2017: ------------- * I made a [pull request](https://github.com/hpi-swa/smalltalkCI/pull/311) to enable Pharo 6.1 on SmalltalkCI :) 24 July 2017: ------------- * I just released [Pharo 6.1](http://pharo.org/news/pharo6.1-released) to update VM and Iceberg (which now is version 0.5.5). cheers! Esteban

1 0

FileSystem file attributes and #isSymlink patch
by Alistair Grant July 30, 2017

July 30, 2017

Hi All, I'm nearly ready to submit a patch that started with the goal of being able to retrieve the device id and fixing FileReference>>isSymlink and also follows Esteban's suggestion of splitting out file existence and other attributes (which provides a performace gain). See the summary below for a description of the changes. The patch involves adding a new VM plugin, FileAttriubutesPlugin. To minimise the chance of any problems along the way I'd like to submit the patch in three steps: 1. Add the VM plugin (FileAttributesPlugin) 2. Add the code the image that allows testing of the code and plugin, but doesn't do any integration with existing functionality. This will allow the plugin to be tested by a few volunteers (hopefully). 3. Add the patches that make the switch over to the new implementation. Can someone point me to how to submit a new VM plugin? The code is contained in a subclass of InterpreterPlugin. I've been using this as my production environment for about 2 months now on a linux 32 bit VM. Running the full test suite results in the same set of test failing before and after applying the patch. I've also ran file related tests on linux 64 bit (run the Test Runner, select all packages with "file" as part of the name and run all the available tests) and the full test suite on Windows 32 bit. The summary is: 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from FileReference now is: #accessTime (new) #changeTime (new) #creationTime #deviceId (new) #exists #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isDirectory #isExecutable (new) #isFIFO (new) #isFile #isReadable #isRegular (new) #isSocket (new) #isSymlink (works) #isWritable #modificationTime #numberOfHardLinks (new) #permissions #size #targetFile (new) #uid (new) 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called quite often. 4. It is possible to retrieve symbolic link attributes, e.g. all the attributes listed above plus the target path. Given how similar MacOS and BSD are to linux, I assume that this will all work without problem on those platforms (but it obviously needs to be tested). As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkAttributes. Overall, performance is slightly better than before. Code that needs to access multiple attributes and is written to take advantage of the new behaviour will see significant performance improvements. If you've got this far and forgotten the original question :-) Can someone point me to how to submit a new VM plugin? Thanks, Alistair

5 8

[Ann] Calypso is moved to github
by Denis Kudriashov July 29, 2017

July 29, 2017

Hi. I moved Calypso to github https://github.com/dionisiydk/Calypso. You can load it with following script: Metacello new baseline: 'Calypso'; repository: 'github://dionisiydk/Calypso'; load Now you can fork it and pull requests to dev branch. New version includes a lot of new features and fixes. You can read overview in my blog http://dionisiydk.blogspot.fr/2017/07/calypso-update-many-improvements-and.… Best regards, Denis

5 11

WorkingSession log
by Sven Van Caekenberghe July 28, 2017

July 28, 2017

Hi, I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: 1ms startup:true a ClassSessionHandler(ProcessorScheduler) 1ms startup:true a ClassSessionHandler(OSPlatform) 6ms startup:true a ClassSessionHandler(ExternalObject) 1ms startup:true a ClassSessionHandler(DiskStore) 5ms startup:true a ClassSessionHandler(SmalltalkImage) 9ms startup:true a ClassSessionHandler(DisplayScreen) 1ms startup:true a ClassSessionHandler(Cursor) 41ms startup:true a ClassSessionHandler(FT2Handle) 238ms startup:true a ClassSessionHandler(FreeTypeSettings) 1ms startup:true a ClassSessionHandler(WorldMorph) 14ms startup:true a ClassSessionHandler(OmSessionStore) For a total of 318ms I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. Sven PS: The code of SessionManager/WorkingSession was very readable, well done Christophe !

8 15

iceberg / libgit behind proxy
by Nicolai Hess July 28, 2017

July 28, 2017

Anyone got it working to use iceberg /libgit behind a proxy? I can access monticello repositories with the right proxy settings. But using iceberg shows an error about can not access github.org

2 2