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

Re: [Pharo-dev] Rubric on 64 bit VM

by Esteban Lorenzano

> On 29 Mar 2017, at 17:01, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > > On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > why does rubric checks for maxVal at first instance? > > This is the problematic code for Spotter: > > RubAbstractTextArea>>#drawingBounds > ^ (self scrollPane isNil or: [ self wrapped ]) > ifTrue: [self innerBounds] > ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @ SmallInteger maxVal ] looks like heâs trying to get an incredible huge drawing area. I would just extract that to a RubAbstractTextArea class>>#maxExtent class method, and with constant numbers, as Eliot suggested. Esteban > > > > On 29 Mar 2017, at 14:07, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > > Hi, > > > > Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments? > > > > Cheers, > > Andrei > > >

March 29, 2017

Re: [Pharo-dev] Rubric on 64 bit VM

by Andrei Chis

On Wed, Mar 29, 2017 at 2:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > why does rubric checks for maxVal at first instance? > This is the problematic code for Spotter: RubAbstractTextArea>>#drawingBounds ^ (self scrollPane isNil or: [ self wrapped ]) ifTrue: [self innerBounds] ifFalse: [ self innerBounds topLeft extent: SmallInteger maxVal @ SmallInteger maxVal ] > > > On 29 Mar 2017, at 14:07, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > Hi, > > > > Right now rubric relies on 'SmallInteger maxVal' to set the drawing > bounds when a size is not set for the editor. This has some side-effects, > like the text in Spotter not appearing on 64 bit given that some drawing > methods from the graphical backend seem to expect 32 bit ranges. We can fix > this by introducing #maxVal32 or maybe there could be some range checks in > the canvas. Comments? > > > > Cheers, > > Andrei > > >

March 29, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by phil＠highoctane.be

I am using Pharo5 on a VM that indeed gives me nice FT fonts. No crash. Yay! Phil On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT > CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I > cannot be sure it will remain like that, but I can tell you: FT2 fonts are > working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. > > So, all this discussion is informative, but the mail that originates it > can be reviewed :) > > Esteban > > On 29 Mar 2017, at 14:43, phil(a)highoctane.be wrote: > > We cannot work in 5.0 professionally with the VM released at the time. > I am also using an intermediate VM thing to do the job. > > That is a pain. And not helping me push more Pharo to sysadmin people > because they cannot have a stable reference point. > > Phil > > On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> > >> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: >> >> wellâ¦ >> >> >> >> Latest VM is intended to work with latest Pharo, not with older >> versions. >> >> Latest VM is *always* an experimental/unstable VM that needs to be >> consideredâ¦ that, experimental and unstable. Otherwise there would not be >> point on having the distinction between stable/latest, isnât? >> >> >> > >> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not >> broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 >> Alphaâ). >> >> >> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo >> 5â. >> >> >> >> Of course, you can live at the edge, but that doesnât means something >> is broken when something fails if premises are not fulfilled :) >> > >> > Well considering VM for Pharo 5 never worked for me properly, whether >> it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have >> a choice but to use the latest. If there is a better way then I am all >> ears, constantly dealing with crashing VM when I need to get work done is >> extremely frustrating... >> > >> > Also I was under the impression that newer VM should work with older >> images, with the only exception being Cog/Spur change. Or should I have six >> different VMs and Pharo Launcher with six different VM configurations? >> >> we moved the paradigm a couple of years ago: each Pharo version comes >> with his own VM version (Other smalltalks do that too). >> Being infinite backward compatible is a lot of pain :) >> >> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for >> PharoLauncher: you ship with latest stable but you can always download >> newers or olders (this is not yet implemented, is just a requirement I >> addedâ¦ well, couple of years ago when we changed the way we wanted VMs to >> work). >> >> Esteban >> >> > >> > Peter >> > >> >> >> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may >> happen, since this is all alfa :P) >> >> >> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will >> work, but if that works, ONCE we move latest vm to stable status we can >> consider backporting it to Pharo 5. >> >> >> >> Esteban >> >> >> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> >> >>> 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) >> >>> >> >> >> >> >> > >> >> >> > >

March 29, 2017

Re: [Pharo-dev] Path>>/ and ..

by Damien Pollet

On 29 March 2017 at 14:02, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Except that ".." is treated as a special case at the moment in > Path class>>addParentElementTo:, which is why #resolve: does the right > thing (well, at least in my opinion :-)). > Well, not according to shell commands : ls ./nonexistentdirectory/.. â cannot access, no such file or directory So we have a divergence between FileSystem, where .. means "cancel the last path segment, syntactically, without even checking the actual files and directories" and the behavior of the shell command (and thus of the underlying system call, I guess) which attempts to actually resolve each segment and fails because it cannot go and look inside nonexistentdirectory for the entry named '..' This becomes important with symbolic links : try ls ./somesymlink/.. and you'll see that you don't get the contents of $PWD but of the parent of the symlink's destination. > I'm having trouble understanding the Path class comments, however: > > "#* and #/ are mnemonic to . and / > whose arguments should be string file- or directory names, not > fragments of Unix path notation intended to be parsed." > > seems to imply that segments should not contain the delimiter (/), and > the current implementation leaves the delimiter in the segment. > Yes. The point is, if you have an API that tries to be clever and guesses what you meant (e.g. you could pass '../foo/bar' as a path element, it might be convenient most of the time, but you lose control of what you mean: the API, because it interprets the strings you pass, will make it difficult or impossible to express some paths. For instance, on my current filesystem, I can create a file named foo\bar. I'm guessing that's impossible on Windowsâ¦ It also leads to quoting, escaping, case sensitivity and such problems (try writing shell scripts that are robust to file names with spacesâ¦) The alternative is to have an API that does what you tell it to, no more, no less. It should consider that if you pass a string with special characters, you meant to have those characters in the result. Maybe that's impossible on some filesystems, and raises an error, but the API will not decide to do something different than you asked. > >> On 29 Mar 2017, at 12:21, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > >> Hi All, > >> > >> The current implementation of Path>>/, while functional, seems to me to > >> create poorly formed paths, e.g.: > >> > >> ('/a/b/c/d' asFileReference / '../e') path ==> "Path / 'a' / 'b' / 'c' > >> / 'd' / '../e'" > >> > >> As can be seen above, the last segment is '../e'. > >> > >> I would expect the result to be: > >> > >> "Path / 'a' / 'b' / 'c' / 'e'" > >> > >> Is there a reason for the current behaviour? If not, are people open to > >> modifying Path>>/ to produce the suggested result above (in Pharo 7)? > >> > >> The method below produces the modified result above and doesn't change > >> the result of running all automated tests. If this is going to be added > >> to Pharo 7 I'll create an additional automated test to check that it is > >> working properly. > >> > >> Cheers, > >> Alistair > >> > >> 'From Pharo6.0 of 13 May 2016 [Latest update: #60451] on 29 March 2017 > >> at 9:40:41.681228 am'! > >> > >> !Path methodsFor: 'navigating' stamp: 'AlistairGrant 3/29/2017 09:39'! > >> / aString > >> | path | > >> > >> aString isEmptyOrNil > >> ifTrue: [ Error signal: 'Path element cannot be empty or nil']. > >> > >> ^self resolve: (Path from: aString) > >> ! ! > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 29, 2017

[pharo-project/pharo-core] e9385a: 60453

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e9385a292f36b669ea545fdfda88177add089cef https://github.com/pharo-project/pharo-core/commit/e9385a292f36b669ea545fdf… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-29 (Wed, 29 Mar 2017) Changed paths: R FuzzyMatcher-Tests.package/FuzzyExample.class/README.md R FuzzyMatcher-Tests.package/FuzzyExample.class/class/examples/exampleClasses.st R FuzzyMatcher-Tests.package/FuzzyExample.class/class/examples/examplePackages.st R FuzzyMatcher-Tests.package/FuzzyExample.class/class/examples/exampleSelectors.st R FuzzyMatcher-Tests.package/FuzzyExample.class/definition.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/defaults/defaultFontFamiliyName.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/event handling/searchStringChanged_.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/event handling/textChanged.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/initialization/initialize.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/opening/buildMorph.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/opening/open.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/opening/openFor_.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/opening/setPattern_.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/private/match_for_.st R FuzzyMatcher-Tests.package/FuzzyExample.class/instance/private/setElements_.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/README.md A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/class/as yet unclassified/exampleAuthors.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/class/examples/exampleClasses.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/class/examples/examplePackages.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/class/examples/exampleSelectors.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/definition.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/accessing/elements_.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/accessing/pattern_.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/event handling/update.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/event handling/updatePattern_.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/initialization/initialize.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/opening/buildMorph.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/opening/open.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/private/aquireFont.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/private/fontName.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/private/match_for_.st A FuzzyMatcher-Tests.package/FuzzyMatcherExample.class/instance/private/setElements_.st M FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/README.md M FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/definition.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/as yet unclassified/testClassSideAPI.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/asserting/assert_scoreFor_equals_.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/initialization/initialize.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/running/newFuzzer.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/running/newMatcher.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testAllMatchingIn.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testAssumptions.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testBasicMatch.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testBasicScore.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testChangePattern.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testClassSideAPI.st M FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testEmptyPattern.st M FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testIsSeperator.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testMatching.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testRobustMatcher.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testScoreValues.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testSillyStuff.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testSimpleScoredMatch1.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testSimpleScoredMatch2.st A FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testSortedByScore.st R FuzzyMatcher-Tests.package/FuzzyMatcherTests.class/instance/tests/testsMorph.st M FuzzyMatcher.package/FuzzyMatcher.class/class/construction/pattern_.st A FuzzyMatcher.package/FuzzyMatcher.class/instance/accessing/pattern_.st M FuzzyMatcher.package/FuzzyMatcher.class/instance/comparing/match_ifScored_.st M FuzzyMatcher.package/FuzzyMatcher.class/instance/initialization/initialize.st R FuzzyMatcher.package/FuzzyMatcher.class/instance/initialization/setPattern_.st M FuzzyMatcher.package/FuzzyMatcher.class/instance/private/isSeperator_.st A Morphic-Widgets-Tabs.package/TabMorph.class/instance/protocol/createAnimationProcess.st M Morphic-Widgets-Tabs.package/TabMorph.class/instance/protocol/softRetrieveMorph.st M Nautilus.package/NautilusUI.class/class/menus behavior/toggleBreakpointIn_.st A Reflectivity.package/extension/RBProgramNode/instance/nodesWithLinks.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60452.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60453.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60452.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60453.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60453 19873 Breakpoint method icon is fail when breakpoint set on ast node https://pharo.fogbugz.com/f/cases/19873 19871 TabMorph could fail if it removed too fast while content is buiding in background https://pharo.fogbugz.com/f/cases/19871 19876 Improve FuzzyMatcher https://pharo.fogbugz.com/f/cases/19876 http://files.pharo.org/image/60/60453.zip

March 29, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60453 Home: https://github.com/pharo-project/pharo-core

March 29, 2017

Re: [Pharo-dev] Rubric on 64 bit VM

by Eliot Miranda

Hi Andrei, > On Mar 29, 2017, at 5:07 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > Right now rubric relies on 'SmallInteger maxVal' to set the drawing bounds when a size is not set for the editor. This has some side-effects, like the text in Spotter not appearing on 64 bit given that some drawing methods from the graphical backend seem to expect 32 bit ranges. We can fix this by introducing #maxVal32 or maybe there could be some range checks in the canvas. Comments? Why not introduce a class variable or a Rubric method that answers a constant? It could be the same as 2^30-1 or something smaller. What is the likely maximum extent of a Rubric drawing surface over the next ten years? > > Cheers, > Andrei

March 29, 2017

Call for PhD candidates in the Software Composition Group, U Bern

by Oscar Nierstrasz

Applications are invited for PhD candidates at the Software Composition Group, University of Bern, Switzerland. The Software Composition Group carries out research in software engineering and programming languages, with a view to enabling software evolution. The SCG is led by Prof. Oscar Nierstrasz and is part of the Institute of Computer Science at the University of Bern. Applicants will contribute to the ongoing SNSF project, âAgile Software Analysisâ, and towards the planned successor project: http://scg.unibe.ch/research/snf16 The candidate must have a MSc in Computer Science (equivalent to a Swiss MSc), should demonstrate strong programming skills, and have research interests in several of the following areas: - software evolution - program understanding - dynamic analysis - static analysis - software modeling - model-driven engineering - secure software engineering - programming language design - domain specific languages - virtual machine technology Female candidates are especially welcome to apply. To apply, please send an email including your research statement and your CV, with at least two references, to Prof. Oscar Nierstrasz (oscar(a)inf.unibe.ch) by June 1, 2017. Kind regards, Oscar Nierstrasz --- Prof. Dr. O. Nierstrasz -- oscar(a)inf.unibe.ch Software Composition Group -- http://scg.unibe.ch University of Bern -- Tel +41 31 631 4618

March 29, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Esteban Lorenzano

and I was seeing and changes to make Athens stable are easily backportable to Pharo 5.0 (is just two methods)â¦ so I do not see why not doing itâ¦ of course, that will require a new stable vm for Pharo 5 Esteban > On 29 Mar 2017, at 15:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. > > So, all this discussion is informative, but the mail that originates it can be reviewed :) > > Esteban > >> On 29 Mar 2017, at 14:43, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> >> We cannot work in 5.0 professionally with the VM released at the time. >> I am also using an intermediate VM thing to do the job. >> >> That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point. >> >> Phil >> >> On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> > >> > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: >> >> wellâ¦ >> >> >> >> Latest VM is intended to work with latest Pharo, not with older versions. >> >> Latest VM is *always* an experimental/unstable VM that needs to be consideredâ¦ that, experimental and unstable. Otherwise there would not be point on having the distinction between stable/latest, isnât? >> >> >> > >> >> So, no, Latest VM (which can also be known as âalpha vmâ) has not broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 Alphaâ). >> >> >> >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo 5â. >> >> >> >> Of course, you can live at the edge, but that doesnât means something is broken when something fails if premises are not fulfilled :) >> > >> > Well considering VM for Pharo 5 never worked for me properly, whether it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have a choice but to use the latest. If there is a better way then I am all ears, constantly dealing with crashing VM when I need to get work done is extremely frustrating... >> > >> > Also I was under the impression that newer VM should work with older images, with the only exception being Cog/Spur change. Or should I have six different VMs and Pharo Launcher with six different VM configurations? >> >> we moved the paradigm a couple of years ago: each Pharo version comes with his own VM version (Other smalltalks do that too). >> Being infinite backward compatible is a lot of pain :) >> >> so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for PharoLauncher: you ship with latest stable but you can always download newers or olders (this is not yet implemented, is just a requirement I addedâ¦ well, couple of years ago when we changed the way we wanted VMs to work). >> >> Esteban >> >> > >> > Peter >> > >> >> >> >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may happen, since this is all alfa :P) >> >> >> >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will work, but if that works, ONCE we move latest vm to stable status we can consider backporting it to Pharo 5. >> >> >> >> Esteban >> >> >> >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> >>> >> >>> 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) >> >>> >> >> >> >> >> > >> >> >> >

March 29, 2017

Re: [Pharo-dev] the new "fixed" compactor VM has FT broken...

by Esteban Lorenzano

BTWâ¦ I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHESâ¦ and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. So, all this discussion is informative, but the mail that originates it can be reviewed :) Esteban > On 29 Mar 2017, at 14:43, phil(a)highoctane.be wrote: > > We cannot work in 5.0 professionally with the VM released at the time. > I am also using an intermediate VM thing to do the job. > > That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point. > > Phil > > On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > > > > On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote: > >> wellâ¦ > >> > >> Latest VM is intended to work with latest Pharo, not with older versions. > >> Latest VM is *always* an experimental/unstable VM that needs to be consideredâ¦ that, experimental and unstable. Otherwise there would not be point on having the distinction between stable/latest, isnât? > >> > > > >> So, no, Latest VM (which can also be known as âalpha vmâ) has not broken FT, it works fine in Pharo 6.0, which can also be know as âPharo 6.0 Alphaâ). > >> > >> BTWâ¦ Thatâs why in zeroconf you cannot download a âlatest vm for Pharo 5â. > >> > >> Of course, you can live at the edge, but that doesnât means something is broken when something fails if premises are not fulfilled :) > > > > Well considering VM for Pharo 5 never worked for me properly, whether it was crashing on BitBlt/Cairo, FT, or who knows what, I don't really have a choice but to use the latest. If there is a better way then I am all ears, constantly dealing with crashing VM when I need to get work done is extremely frustrating... > > > > Also I was under the impression that newer VM should work with older images, with the only exception being Cog/Spur change. Or should I have six different VMs and Pharo Launcher with six different VM configurations? > > we moved the paradigm a couple of years ago: each Pharo version comes with his own VM version (Other smalltalks do that too). > Being infinite backward compatible is a lot of pain :) > > so yes, PharoLauncher needs to adapt to itâ¦ I added that requirement for PharoLauncher: you ship with latest stable but you can always download newers or olders (this is not yet implemented, is just a requirement I addedâ¦ well, couple of years ago when we changed the way we wanted VMs to work). > > Esteban > > > > > Peter > > > >> > >> Said thatâ¦ I had no problems with Latest VM + Pharo 6.0 (and they may happen, since this is all alfa :P) > >> > >> I donât know if âworkarounding the VMâ (by renaming libfreetype) will work, but if that works, ONCE we move latest vm to stable status we can consider backporting it to Pharo 5. > >> > >> Esteban > >> > >>> On 29 Mar 2017, at 10:37, Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > >>> > >>> 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) > >>> > >> > >> > > > > >

March 29, 2017