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

PharoSpur32Vm
by Nicolai Hess July 23, 2017

July 23, 2017

Where are the latest Pharo-spur-vms (32bit) are built? I don't see them on the build server, only the buildresults at http://files.pharo.org/vm/pharo-spur32/linux/ The latest builds on the buildserver are from the last year only. nicolai

9 27

macOS Sierra support
by Sven Van Caekenberghe July 15, 2017

July 15, 2017

Hi, Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. Thanks, Sven PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.

12 27

Re: [Pharo-dev] [Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)
by Eliot Miranda June 14, 2017

June 14, 2017

Hi Esteban, Hi Igor, Hi All, On Fri, Mar 10, 2017 at 7:35 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Iâm tumbling into an error in Pharo, because we use callbacks intensively, > in Athens(cairo)-to-World conversion in particular, and people is sending > always their crash reportsâ¦ we made the whole conversion a lot more robust > since problems started to arise, but now I hit a wall I cannot solve: I > think problem is in something in callbacks. > > And problem is showing very easy on 64bits (while in 32bits it takes time > and is more random). > I responded in the "image not opening" thread, but it's the same problem. I really want to hear what y'all think because I'll happily implement a fix, but I want to know which one y'all think is a good idea. Here's my reply (edits between [ & ] to add information): On Mon, Mar 13, 2017 at 9:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: I'm pretty confident [I know] this is to do with bugs in the Athens surface code which assumes that callbacks can be made in the existing copyBits and warpBits primitive. They can't do this safely because a GC (scavenge) can happen during a callback, which then causes chaos when the copyBits primitive tries to access objects that have been moved under its feet. I've done work to fix callbacks so that when there is a failure it is the copyBits primitive that fails, instead of apparently the callback return primitive. One of the apparent effects of this fix is to stop the screen opening up too small; another is getting the background colour right, and yet another is eliminating bogus pixels in the VGTigerDemo demo. But more work is required to fix the copyBits and warpBits primitives. There are a few approaches one might take: a) fixing the primitive so that it saves and restores oops around the callbacks using the external oop table [InterpreterProxy>>addGCRoot: & removeGCRoot:]. That's a pain but possible. [It's a pain because all the derived pointers (the start of the destForm, sourceForm, halftoneForm and colorMapTable) must be recomputed also, and of course most of the time the objects don't move; we only scavenge about once every 2 seconds in normal running] b) fixing the primitive so that it pins the objects it needs before ever invoking a callback [this is a pain because pinning an object causes it to be tenured to old space if it is in new space; objects can't be pinned in new space, so instead the pin operation forwards the new space object to an old space copy if required and answers its location in old space, so a putative withPinnedObjectsDo: operation for the copyBits primitive looks like withPinnedFormsDo: aBlock <inline: #always> self cppIf: SPURVM & false ifTrue: [| bitBltOopWasPinned destWasPinned sourceWasPinned halftoneWasPinned | (bitBltOopWasPinned := interpreterProxy isPinned: bitBltOop) ifFalse: [bitBltOop := interpreterProxy pinObject: bitBltOop]. (destWasPinned := interpreterProxy isPinned: destForm) ifFalse: [destForm := interpreterProxy pinObject: destForm]. (sourceWasPinned := interpreterProxy isPinned: sourceForm) ifFalse: [sourceForm := interpreterProxy pinObject: sourceForm]. (halftoneWasPinned := interpreterProxy isPinned: halftoneForm) ifFalse: [halftoneForm := interpreterProxy pinObject: halftoneForm]. aBlock value. bitBltOopWasPinned ifFalse: [interpreterProxy unpinObject: bitBltOop]. destWasPinned ifFalse: [interpreterProxy unpinObject: destForm]. sourceWasPinned ifFalse: [interpreterProxy unpinObject: sourceForm]. halftoneWasPinned ifFalse: [interpreterProxy unpinObject: halftoneForm]] ifFalse: [aBlock value] and tenuring objects to old space is not ideal because they are only collected by a full GC, so doing this would at least tenure the bitBltOop which is very likely to be in new space] c) fixing the primitive so that it uses the scavenge and fullGC counters in the VM to detect if a GC occurred during one of the callbacks and would fail the primitive [if it detected that a GC had occurred in any of the surface functions]. The primitive would then simply be retried. d) ? I like c) as it's very lightweight, but it has issues. It is fine to use for callbacks *before* cop[yBits and warpBits move any bits (the lockSurface and querySurface functions). But it's potentially erroneous after the unlockSurface primitive. For example, a primitive which does an xor with the screen can't simply be retried as the first, falling pass, would have updated the destination bits but not displayed them via unlockSurface. But I think it could be arranged that no objects are accessed after unlockSurface, which should naturally be the last call in the primitive (or do I mean showSurface?). So the approach would be to check for GCs occurring during querySurface and lockSurface, failing if so, and then caching any and all state needed by unlockSurface and showSurface in local variables. This way no object state is accessed to make the unlockSurface and showSurface calls, and no bits are moved before the queryDurface and lockSurface calls. If we used a failure code such as #'object may move' then the primitives could answer this when a GC during callbacks is detected and then the primitive could be retried only when required. [Come on folks, please comment. I want to know which idea you like best. We could fix this quickly. But right now it feels like I'm talking to myself.] > Here is the easiest way to reproduce it (in mac): > > wget files.pharo.org/get-files/60/pharo64-mac-latest.zip > wget files.pharo.org/get-files/60/pharo64.zip > wget files.pharo.org/get-files/60/sources.zip > unzip pharo64-mac-latest.zip > unzip pharo64.zip > unzip sources.zip > ./Pharo.app/Contents/MacOS/Pharo ./Pharo64-60438.image eval "VGTigerDemo > runDemo" > > eventually (like 5-6 seconds after, if not immediately), you will have a > stack like this: > > SmallInteger(Object)>>primitiveFailed: > SmallInteger(Object)>>primitiveFailed > SmallInteger(VMCallbackContext64)>>primSignal:andReturnAs:fromContext: > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > VGTigerDemo>>runDemo > VGTigerDemo class>>runDemo > UndefinedObject>>DoIt > OpalCompiler>>evaluate > OpalCompiler(AbstractCompiler)>>evaluate: > [ result := Smalltalk compiler evaluate: aStream. > self hasSessionChanged > ifFalse: [ self stdout > print: result; > lf ] ] in EvaluateCommandLineHandler>>evaluate: > in Block: [ result := Smalltalk compiler evaluate: aStream.... > BlockClosure>>on:do: > EvaluateCommandLineHandler>>evaluate: > EvaluateCommandLineHandler>>evaluateArguments > EvaluateCommandLineHandler>>activate > EvaluateCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ aCommandLinehandler activateWith: commandLine ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in > Block: [ aCommandLinehandler activateWith: commandLine ] > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > [ self > handleArgument: > (self arguments > ifEmpty: [ '' ] > ifNotEmpty: [ :arguments | arguments first ]) ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ > self... > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activate > PharoCommandLineHandler>>activate > PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ super activateWith: aCommandLine ] in PharoCommandLineHandler > class>>activateWith: in Block: [ super activateWith: aCommandLine ] > > Any idea? > > thanks! > Esteban -- _,,,^..^,,,_ best, Eliot

6 11

ZnInvalidUTF8 on response from squeaksource
by Patrick R. May 22, 2017

May 22, 2017

Hi everyone, I have been working on bringing http://squeaksource.com/ical/ up to speed for Squeak and wanted to make sure that it also works for Pharo. Therefore, I have created a travis build job for Squeak and Pharo (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which pulls the source from squeaksource.com. Now the issue is that loading the package in Pharo fails with a GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this might be the result of the squeaksource page delivering the page as iso-8859-1 as it contains special characters. Any ideas on how to get this to work? I do not have access to the ical repository description and I would liek to avoid mirroring the whole repository on GitHub. Thanks and bests Patrick -- View this message in context: http://forum.world.st/ZnInvalidUTF8-on-response-from-squeaksource-tp4938787… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

6 14

./pharo --help returns exit code 1 on ubuntu
by Andrei Chis May 7, 2017

May 7, 2017

Hi, In an ubuntu installation with the latest vm and Pharo 6 image when executing `./pharo --help` I get an error code of 1. wget -O- get.pharo.org/vmLatest60 | bash wget -O- get.pharo.org/60 | bash ./pharo --help echo $? --> returns 1 On mac the error code is 0. Also when executing './pharo' or './pharo Pharo.image --help' or './pharo --version' the error code is 0 on both mac and linux. So it seems there is some issues with --help. Actually, it gives a usage warning, but still I'd expect to not return an error code. Usage: Pharo.app/Contents/MacOS/Pharo [<option>...] [<imageName> [<argument>...]] Pharo.app/Contents/MacOS/Pharo [<option>...] -- [<argument>...] Cheers, Andrei

3 5

Re: [Pharo-dev] [Pharo-users] Pharo 5 and retina displays in 2016?
by Tim Mackinnon April 20, 2017

April 20, 2017

Adding this to the Dev user group - is there really no solution for this? I read a few old messages from 2012 about different fonts but nothing seemed to work from what I could see. Has everyone just been putting up with the fuzziness and got used to it? As a new Retina display user, I love the clarity in other apps and find it quite jarring in Pharo. I was going to do a brown bag session on Smalltalk with the current team Iâm working with, however as they all have retina Macs, I think I may reconsider this as unless you love the language its another thing for people to throw stones at. As Stephan mentions below, were Tobiasâ changes not viable? Is there anything we can do to help get them safely in - or can I try it on an experimental branch? Tim > On 29 Nov 2016, at 21:02, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 29/11/16 00:34, Tim Mackinnon wrote: >> Or is this still the same issue thatâs been hanging around for a long >> time as its hard to easily fix? > > Tobias Pape wrote some vm changes that solved the problem this summer, and they somehow interfered, so were reverted. I posted some pictures > on twitter 10/11-7 of it working with both Pharo & Squeak. > > Stephan > > > >> Hi Guys - its been a while since Iâve had a chance to get back into some coding in Smalltalk, and took the plunge again with a new laptop and Pharo 5, however the screen is really blurry? >> >> Doing a google search, I can see this same question raised back in 2012, but has there been no progress in this intervening years or has a workaround not been documented for google to find? Or has everyone just got used to it, and I need to hand in there... >> >> I have tried using a different font - but not sure what constitutes a true-type font (are these the same as free-type mentioned in the Settings Browser?). Has anyone found a font that makes everything look crisp (I tried Helvetica but its only marginally better). >> >> Or is this still the same issue thatâs been hanging around for a long time as its hard to easily fix? >> >> Tim

8 20

Some test where Spur more slow than Cog
by Denis Kudriashov April 12, 2017

April 12, 2017

Hi. I found case where Spur more slow than Cog. Not much but. prototype := BorderedMorph new. result := [prototype veryDeepCopy ] benchFor: 2 seconds. In my computer I got: Cog: a BenchmarkResult(16,982 iterations in 2 seconds 1 millisecond. 8,487 per second) Spur: a BenchmarkResult(12,507 iterations in 2 seconds 33 milliseconds. 6,152 per second). Is it expected behavior for such case?

3 5

the new "fixed" compactor VM has FT broken...
by Peter Uhnak April 5, 2017

April 5, 2017

The new "fixed" compactor VM has broken FT... So any text drawn on Athens canvas results in red cross... Error in... CairoFontFace class>>primFtFace:loadFlags: 'Unable to find function address' Apparently because someone renamed libfreetype-6.dll to libfreetype.dll (Windows VM latest, Pharo 5)

7 20

[gsoc] Advances in Code Quality
by Myroslava Romaniuk April 2, 2017

April 2, 2017

Hello, I'm Myroslava and I'm studying Computer Science at the Ukrainian Catholic University in Lviv. As part of my Google Summer of Code project I'm going to work on the quality of code in Pharo. This <https://docs.google.com/document/d/1cX7VJ2QZejq_Cu6Ur28UCiUwzSD-Bu8GgSDqECi…> is my proposal draft, and I would really appreciate some feedback, comments, suggestions and so on. Thanks!

5 6

Iceberg with SSH on Linux
by Pavel Krivanek April 2, 2017

April 2, 2017

Hi, I want to let you know that the SSH (git@...) support in Iceberg on Linux VM now works with the latest threaded VM (get.pharo.org/vmTLatest60) The threaded VM now runs without root priviledges nor special configuration of the system. Thank you Esteban and others! Cheers, -- Pavel

6 19