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

Re: [Pharo-users] How to run a window in full-screen mode?

by Nicolai Hess

2017-07-17 15:50 GMT+02:00 Luke Gorrie <luke(a)snabb.co>: > Hoi! > > I am looking for a way to run a window in full-screen mode in Pharo. That > is it should maximize, beyond the bounds that the expand button usually > takes, and it should automatically resize when the world does. > > I'm thinking of the GTInspector but a custom class would be fine too. > > Is there a simple solution? > > On Discord I got a partial solution: > > window := GTInspector openOn: self. > window > removeBoxes; > beSticky; > bounds: window world clearArea. > > but the main problem here is that it doesn't resize when the world does. > > I wonder if it would make more sense to avoid the SystemWindow and embed > the inspector directly in the World somehow...? > > Cheers! > -Luke > > There is a FullscreenMorph see for example StandardWindow>>#openFullscreen

July 17, 2017

How to run a window in full-screen mode?

by Luke Gorrie

Hoi! I am looking for a way to run a window in full-screen mode in Pharo. That is it should maximize, beyond the bounds that the expand button usually takes, and it should automatically resize when the world does. I'm thinking of the GTInspector but a custom class would be fine too. Is there a simple solution? On Discord I got a partial solution: window := GTInspector openOn: self. window removeBoxes; beSticky; bounds: window world clearArea. but the main problem here is that it doesn't resize when the world does. I wonder if it would make more sense to avoid the SystemWindow and embed the inspector directly in the World somehow...? Cheers! -Luke

July 17, 2017

Re: [Pharo-users] Using the Debugger to write code

by Marcus Denker

>>> >>> 2017-07-12 9:09 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >>> in the workspace it creates a variable (with value nil)â¦ so it treats upper-case >>> unknown vars the same as lower case. >>> >>> I think it might make sense to have for upper case instead the menu that asks >>> what to do (it could there have a âadd binding to workspaceâ entry for the current >>> way, too) >>> >>> I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. >> >> yes, we should fix it. binding should just be created for lower case vars. >> > > How to fix it: > > OCRequestorScope is the scope of variables in tools. #lookupVar: is the method that is doing the lookup. > > replace the code > > global := self lookupGlobalVar: name. > global ifNotNil: [ ^ global ]. > > with: > > name first isUppercase ifTrue: [ ^ outerScope lookupVar: name]. > > But: right now we abuse the requesterscope to implement the feature that you can hand > in an additional dictionary with bindings. See testEvaluateWithBindingsWithUppercaseName > This change breaks this featureâ¦ but it just means we need to implement this better, which > I will do . > For Pharo6: https://pharo.fogbugz.com/f/cases/20254/Playground-should-ask-to-create-cla… <https://pharo.fogbugz.com/f/cases/20254/Playground-should-ask-to-create-cla…> This adds a scope for additional bindings and uses this for the bindings, which then allows us to change the requestorscope as needed. Marcus

July 17, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Tim Mackinnon

Well Iâve been shooting in the dark a bit - but I also left out the sound and display soâs (e.g. -x execlude the following and add back the null so's zip -r --symlinks ../deploy/$LAMBDA_NAME.zip * -x pharo-local/\* \*.sources \*.changes \*.st \*.log */libgit2.* */libSDL2* */B3DAccelerator* */JPEGRead* */vm-sound* */vm-display* tmp/\* */__MACOSX\* - zip -uR ../deploy/$LAMBDA_NAME.zip *-null.so And everything seems to run clean. (Would be useful to get some feedback from those in the know - does just leaving out soâs incurred a penalty if you donât recompile the VM? Presumably something would get written to std error or pharodebug if it was an issue). In fact my run times on EC2 are pretty impressive: PharoLambdaMin]$ time ./pharo Pharo.image exec "Lambda processJSON: '{}'" {"outputSpeech":{"text":"Good Morning, it's eleven twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation Successful","title":"Pharo Lambda","type":"Simple"}} real 0m0.039s user 0m0.028s sys 0m0.000s [ec2-user@ip-172-31-44-73 PharoLambdaMin]$ time ./pharo Pharo.image exec "Lambda processJSON: '{}'" {"outputSpeech":{"text":"Good Morning, it's eleven twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation Successful","title":"Pharo Lambda","type":"Simple"}} real 0m0.039s user 0m0.020s sys 0m0.008s Not bad eh? Tim > On 17 Jul 2017, at 07:00, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks again Pavel - I'll try the 6.0 step 4 or possibly step 5 with sunit (as many libraries don't separate out their tests). > > I've also tried leaving out libgit and libsdl2 .so's on my server build and that seems fine too - making me wonder what others I can safely leave out? Sound is a candidate (but small fry in size but do you need the null variant?). > > Libcrypto is big - but I wonder if https routines would use that (and it sounds server processing'y so maybe best left). > > I was hoping to find a list explaining them somewhere - but it remains rather mysterious. > > However, at this point, I think I may have hit the sweet spot in size where AWS seems to load efficiently below a zip of 10mb? > > Tim > > Sent from my iPhone > > On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > >> If you want to stay with Pharo 6 image, you can try the bootstrapped version of the minimal image: >> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… <https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu…> >> >> -- Pavel >> >> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: >> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is already converting to 64bit). There should be no problem with STON because whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal image is done differently (by shrinking) and not so well tested. >> >> For the conversion of 32-bit image to 64-bit image you need a VMMaker image: >> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact… <https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact…> >> and then evaluate: >> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: nil ]" >> >> -- Pavel >> >> >> >> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> Hi Pavel - thanks for getting me to the point where I could even have a minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and run with this as best I can. >> >> Iâd been using the 6.0 image you suggested to me - but maybe I could use a 70 image with Pharo 6 for a while (until the VM diverges) right? >> >> The bit I havenât quite understood however, is how the 64bit image is created - as your reference is to a 32bit version? Is the 64bit one converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I right in thinking the pipeline stage after this one is the one you sent me - and the travis.yml file shows me what it does? But I canât see a trivis.yml in the conversion stage so Iâm not sure how it does that. (Question - how do I see what the pipelines do to answer my own questions?) >> >> I was hoping that there was a basic image that got me up to metacello baseline level to load git file tree packages/baselines in my own repo as well baselines on the internet. The one you sent me is fairly close to that (its just missing STON in the image and seems to have an issue with resolving undeclared classes that get loaded in - should do a fogbugz on that?) >> >> The follow-on from a metacello image is how we can get people to create better baselines that give you more minimal loading options (e.g. conditionally leave out the test cases perhaps) >> >> Tim >> >>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >>> >>> Hi Tim, >>> >>> you can base the your work on the bootstrapped image, see https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ <https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/>, file Pharo7.0-core-*.zip >>> >>> This image does not have a lot of basic components like Monticello or network but it has a compiler so the code can be imported as *.st files. >>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and probably can fit your needs. Monticello and network support are included. But you cannot use baselines nor configurations to load your code. >>> >>> -- Pavel >>> >>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm wondering if I can get even smaller. >>> >>> There are lots of .so's in the vm which wouldn't make sense on a server once deployed - sound, maybe libgit ... >>> >>> Is there a list of the essential ones, or tips on what I can strip out of the Linux deployment? I also recall that i can leave out .sources and .changes as well right? >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> >> >> >>

July 17, 2017

Re: [Pharo-users] Playground and Dr. Geo

by Hilaire

The owner of the menu (DockingBarToogleMenuItemMorph) does not have the right bounds. Therefore its #adjacentTo message returns the wrong information. Le 17/07/2017 Ã 10:50, Hilaire a Ã©crit : >> if b) The real morph position is probably not the same as where >> clicked causing it to open at another place. >> > I guess so too. > -- Dr. Geo http://drgeo.eu

July 17, 2017

Re: [Pharo-users] Playground and Dr. Geo

by Hilaire

Hi, Le 16/07/2017 Ã 22:02, Henrik Nergaard a Ã©crit : > > a)Do you wrap the morph inside the morph tab view? , > I don't understand. > b) Do you use the same code for rendering as in Morph>> > #gtInspectorMorphIn: . > No, as I want a Morph view and not a From: gtInspectorCanvasIn: composite <gtInspectorPresentationOrder: 90> | morphPresentation | morphPresentation := composite morph. morphPresentation title: 'Morph'; display: [self view] > > if a) it is most likely caused by the morph being wrapped within one > or more transform morphs, and the offset of these are not taken into > account when opening the menu. > > > if b) The real morph position is probably not the same as where > clicked causing it to open at another place. > I guess so too. > What method are you using for opening the menu: (#popUpEvent:in: , > #popUpAt:forHand:in: , other)? > The menu are opened with #popUpAdjacentTo:forHand:from: Menu are instantiate as: menuBar := self window newToolDockingBar. menuBar add: 'File' translated font: self theme menuBarFont icon: nil help: 'Load, save or export Dr. Geo figure.' translated subMenu: self fileMenu. > also > see: https://pharo.fogbugz.com/f/cases/15927/Menu-is-broken-when-contained-in-a-… > > Looks to be the same. But issue was closed so it should be ok, may be an unrelated problem. Hilaire -- Dr. Geo http://drgeo.eu

July 17, 2017

Re: [Pharo-users] Mysterious problem in loading Pharo

by Peter Uhnak

With fast boot I had experiences where the restart wasn't enough and I had to restart several times, but since I disabled fast boot restarting once was always enough... so usually the first thing I do when windows boots is to check if Pharo runs ok. In some rare unclear circmustances (now I wonder whether it happened after sleep) it broke after some time... but that happened only two or three times in past ~6 months. Also dual-booting increases the probability it seems... there were some correlated issues regarding time and network card, but nothing conclusive. Peter On Mon, Jul 17, 2017 at 12:01:55AM +0100, PBKResearch wrote: > Peter > > I think the implication of your second para is that your last resort, re-booting the system, is always effective in fixing the problem. If so, while it is obviously a nuisance I think I can live with that. I think I have had this only once before - at least, I have seen the debug console in some context. But yesterday it happened simultaneously on two separate machines. So it all depends on how frequently it happens. > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Peter Uhnak > Sent: 16 July 2017 15:40 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Mysterious problem in loading Pharo > > I had this problem for several months (and still do), and so far I didn't manage to figure out what is the actual cause. > > Sometimes it fixes itself (close Pharo and open again), sometimes opening it with different VM (and then reopen with the original) helps, and sometimes I have to restart system. > > After I disabled Windows Fast Boot it is somewhat more infrequent (or rather it fixes itself without the need to restart). > > But otherwise I might as well wave a magical wand. It is annoying but still better than then spending countless hours digging randomly and aimlessly in the VM Â¯\_(ã)_/Â¯. > > Peter > > > On Sat, Jul 15, 2017 at 10:38:51PM +0800, Ben Coman wrote: > > Maybe revew recent Windows 10 updates... > > http://www.sysprobs.com/how-to-view-installed-updates-on-windows-10-8- > > 1-server-2012 > > > > cheers -ben > > > > On Sat, Jul 15, 2017 at 6:26 PM, PBKResearch <peter(a)pbkresearch.co.uk> > > wrote: > > > > > Hello > > > > > > > > > > > > I have a problem in loading Pharo images which, until yesterday, > > > loaded without difficulty. All the images showing the problem are > > > Pharo 6 with the Cog VM; older images do not seem to be affected. > > > > > > > > > > > > The first sign of a problem is that, as soon as I start the image, > > > the debug console appears, with several repeats of the message: > > > > > > LoadLibrary(FT2Plugin.dll) (998: Invalid access to memory location.) > > > > > > The other strange thing is that the appearance of some opened > > > windows has changed. Most obviously, the three icons at the top left > > > (close, minimise, > > > expand) are very close together. Also, I think the print size has > > > got a bit smaller, though this is not obvious. > > > > > > > > > > > > I have recently reinstalled some components of Pharo and Moose, > > > trying to solve my problems with PunQLite, so I wondered if I had > > > fouled something up. To check, I made a completely new install of > > > Pharo 6 (#60508) from the Pharo download page in a separate folder. > > > When I start the image, both the strange things above are present, > > > plus a debug window with the message; > > > âFT2 Error: Freetype2 primitive failedâ. > > > > > > > > > > > > So it looks as though something has happened to my system which > > > means that any Pharo 6 image will show these oddities. The images I > > > have tried seem able to run some of my functions correctly, so itâs > > > all to do with appearance. > > > > > > > > > > > > I am running on Windows 10 with all recent updates. There was a > > > major update of Windows late yesterday, so it may be that the > > > problems appeared then. Does anyone have any suggestions? > > > > > > > > > > > > Many thanks > > > > > > > > > > > > Peter Kenny > > > > >

July 17, 2017

Re: [Pharo-users] VoyageMongo with Metacello project spec in Pharo 6 on MacOS Sierra

by Esteban Lorenzano

> On 16 Jul 2017, at 15:27, Guillaume Giraud <guillaume.giraud(a)openmailbox.org> wrote: > > Thanks a lot ! > > I used your config and now it works. > > The result of evaluating 'Smalltalk osâ is 'a MacOSPlatformâ, and the VM is 201705310241. > > By the way, I find it difficult to fully grasp the Metacello config process. > I have read Deep into Pharo, but I canât really understand why the modification you suggested works. > Are there other resources available on the subject ? yeah, not really muchâ¦ metacello is hard mostly because dependency management is hard. there are some few cases like this, however, that are mostly âaccidental complexityâ and is because of evolution of the tool. this is the problem you were seeing: configurations (those who starts with âConfigurationOfâ) were made to match older monticello repositories. Then they define versions that points to specific package versions. baselines (those who starts with âBaselineOfâ) are made to match git and âgit likeâ repositories: there you do not need to define versions because the commit contains all the information you need. Thatâs defined in the url "github://pharo-nosql/voyage:1.5/mc <github://pharo-nosql/voyage:1.5/mc>", where the â1.5â part points to the â1.5â release (which is just a git tag). what happened in your project case is that you where downloading âmasterâ version to load ConfigurationOfVoyageMongo which then was downloading another version of voyage (not master) which was then loading from another, incorrect release (1.4). So it was doing double work. Using directly âbaseline:with:â prevents this because downloads just the version you want :) in general, when in your projects, is recommended to use the âbaseline formâ when pointing to git based projects and to use configurations just for those that still resides on smalltalkhub or other of the monticello-based repositories. hope this clarifies :P cheers! Esteban > > Bye. > >> Hi, >> >>> On 15 Jul 2017, at 13:46, Guillaume Giraud <guillaume.giraud(a)openmailbox.org <mailto:guillaume.giraud@openmailbox.org>> wrote: >>> >>> Hello, >>> >>> I placed this code in a baseline of my package: >>> >>> spec >>> project: 'VoyageMongo' >>> with: [ spec >>> className: #ConfigurationOfVoyageMongo; >>> version: #stable; >>> repository: 'github://pharo-nosql/voyage/mc <github://pharo-nosql/voyage/mc>'; >>> loads: #('mongo tests') ]. >>> >>> Unfortunately, when I load my Package from Pharo6 on MacOS Sierra I get the following error: >>> >>> Error: Unsupported OS platform >>> >>> The first lines of the stack are: >>> >>> BaselineOfPunQLite(Object) error: >>> BaselineOfPunQLite platformLibraryName >>> BaselineOfPunQLite preLoad >>> MetacelloMCVersionpec(MetacelloSpec) doItBlock: >>> >>> In detail: >>> >>> platformLibraryName >>> " Answer a name for the compiled version of the library " >>> >>> Smalltalk os isUnix ifTrue: [ ^ 'unqlite.so' ]. >>> Smalltalk os isWin32 ifTrue: [ ^ 'unqlite.dll' ]. >>> Smalltalk os isMacOSX ifTrue: [ ^ 'unqlite.dylib' ]. >>> >>> self error: 'Unsupported OS platform? >>> >>> With Pharo6 on MacOsSierra, ? Smalltalk os isMacOSX ? return ? false ?. But ? Smalltalk os isMacOS ? return ? true ?. >>> >>> What can I do? I just need to load Voyage with the configuration of my package ? >> >> you can just change the Smalltalk os isMacOSX line for Smalltalk os isMacOS for the moment. >> now, that?s very weird :) >> What?s the result of evaluating "Smalltalk os? ? >> and after executing "OSPlatform startUp: true.? ? >> which VM are you using (Smalltalk vm version) ? >> >> >> and btw, is a lot better to make your config as this: >> >> spec >> baseline: 'Voyage' >> with: [ >> spec >> repository: 'github://pharo-nosql/voyage:1.5/mc <github://pharo-nosql/voyage:1.5/mc>'; >> loads: #('mongo tests') ]. >> >> (referring directly the baseline) >> >> >> cheers! >> Esteban >> >>> Thanks.

July 17, 2017

Re: [Pharo-users] Creating the smallest server runtime footprint

by Tim Mackinnon

Thanks again Pavel - I'll try the 6.0 step 4 or possibly step 5 with sunit (as many libraries don't separate out their tests). I've also tried leaving out libgit and libsdl2 .so's on my server build and that seems fine too - making me wonder what others I can safely leave out? Sound is a candidate (but small fry in size but do you need the null variant?). Libcrypto is big - but I wonder if https routines would use that (and it sounds server processing'y so maybe best left). I was hoping to find a list explaining them somewhere - but it remains rather mysterious. However, at this point, I think I may have hit the sweet spot in size where AWS seems to load efficiently below a zip of 10mb? Tim Sent from my iPhone > On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > If you want to stay with Pharo 6 image, you can try the bootstrapped version of the minimal image: > https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-Configu… > > -- Pavel > > 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is already converting to 64bit). There should be no problem with STON because whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal image is done differently (by shrinking) and not so well tested. >> >> For the conversion of 32-bit image to 64-bit image you need a VMMaker image: >> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact… >> and then evaluate: >> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage: 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked: nil ]" >> >> -- Pavel >> >> >> >> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> Hi Pavel - thanks for getting me to the point where I could even have a minimal image. As Iâm on the edge of my Pharo knowledge here, Iâll try and run with this as best I can. >>> >>> Iâd been using the 6.0 image you suggested to me - but maybe I could use a 70 image with Pharo 6 for a while (until the VM diverges) right? >>> >>> The bit I havenât quite understood however, is how the 64bit image is created - as your reference is to a 32bit version? Is the 64bit one converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I right in thinking the pipeline stage after this one is the one you sent me - and the travis.yml file shows me what it does? But I canât see a trivis.yml in the conversion stage so Iâm not sure how it does that. (Question - how do I see what the pipelines do to answer my own questions?) >>> >>> I was hoping that there was a basic image that got me up to metacello baseline level to load git file tree packages/baselines in my own repo as well baselines on the internet. The one you sent me is fairly close to that (its just missing STON in the image and seems to have an issue with resolving undeclared classes that get loaded in - should do a fogbugz on that?) >>> >>> The follow-on from a metacello image is how we can get people to create better baselines that give you more minimal loading options (e.g. conditionally leave out the test cases perhaps) >>> >>> Tim >>> >>>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> >>>> Hi Tim, >>>> >>>> you can base the your work on the bootstrapped image, see https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file Pharo7.0-core-*.zip >>>> >>>> This image does not have a lot of basic components like Monticello or network but it has a compiler so the code can be imported as *.st files. >>>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and probably can fit your needs. Monticello and network support are included. But you cannot use baselines nor configurations to load your code. >>>> >>>> -- Pavel >>>> >>>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>>>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm wondering if I can get even smaller. >>>>> >>>>> There are lots of .so's in the vm which wouldn't make sense on a server once deployed - sound, maybe libgit ... >>>>> >>>>> Is there a list of the essential ones, or tips on what I can strip out of the Linux deployment? I also recall that i can leave out .sources and .changes as well right? >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>> >>> >> >

July 17, 2017

Re: [Pharo-users] Mysterious problem in loading Pharo

by PBKResearch

Peter I think the implication of your second para is that your last resort, re-booting the system, is always effective in fixing the problem. If so, while it is obviously a nuisance I think I can live with that. I think I have had this only once before - at least, I have seen the debug console in some context. But yesterday it happened simultaneously on two separate machines. So it all depends on how frequently it happens. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Peter Uhnak Sent: 16 July 2017 15:40 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Mysterious problem in loading Pharo I had this problem for several months (and still do), and so far I didn't manage to figure out what is the actual cause. Sometimes it fixes itself (close Pharo and open again), sometimes opening it with different VM (and then reopen with the original) helps, and sometimes I have to restart system. After I disabled Windows Fast Boot it is somewhat more infrequent (or rather it fixes itself without the need to restart). But otherwise I might as well wave a magical wand. It is annoying but still better than then spending countless hours digging randomly and aimlessly in the VM Â¯\_(ã)_/Â¯. Peter On Sat, Jul 15, 2017 at 10:38:51PM +0800, Ben Coman wrote: > Maybe revew recent Windows 10 updates... > http://www.sysprobs.com/how-to-view-installed-updates-on-windows-10-8- > 1-server-2012 > > cheers -ben > > On Sat, Jul 15, 2017 at 6:26 PM, PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > > > Hello > > > > > > > > I have a problem in loading Pharo images which, until yesterday, > > loaded without difficulty. All the images showing the problem are > > Pharo 6 with the Cog VM; older images do not seem to be affected. > > > > > > > > The first sign of a problem is that, as soon as I start the image, > > the debug console appears, with several repeats of the message: > > > > LoadLibrary(FT2Plugin.dll) (998: Invalid access to memory location.) > > > > The other strange thing is that the appearance of some opened > > windows has changed. Most obviously, the three icons at the top left > > (close, minimise, > > expand) are very close together. Also, I think the print size has > > got a bit smaller, though this is not obvious. > > > > > > > > I have recently reinstalled some components of Pharo and Moose, > > trying to solve my problems with PunQLite, so I wondered if I had > > fouled something up. To check, I made a completely new install of > > Pharo 6 (#60508) from the Pharo download page in a separate folder. > > When I start the image, both the strange things above are present, > > plus a debug window with the message; > > âFT2 Error: Freetype2 primitive failedâ. > > > > > > > > So it looks as though something has happened to my system which > > means that any Pharo 6 image will show these oddities. The images I > > have tried seem able to run some of my functions correctly, so itâs > > all to do with appearance. > > > > > > > > I am running on Windows 10 with all recent updates. There was a > > major update of Windows late yesterday, so it may be that the > > problems appeared then. Does anyone have any suggestions? > > > > > > > > Many thanks > > > > > > > > Peter Kenny > >

July 16, 2017