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

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

by phil＠highoctane.be

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 Ben Coman

On Wed, Mar 29, 2017 at 8:02 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 29 March 2017 at 13:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> problem is this part: '../eâ >> it has to be any of this: >> >> ('/a/b/c/d' asFileReference / '..' / 'e') path. "Path / 'a' / 'b' / 'c' / 'd' / '..' / 'e'" >> ('/a/b/c/d' asFileReference parent / 'e') path. "Path / 'a' / 'b' / 'c' / 'e'" >> >> the rationale is that â..â is not modelled as a special kind of node, just a string. >> and the reason is that thatâs commonly like that, but it doesnât *has >> to* be like thatâ¦ there could be file systems that interprets .. as a >> simple string. > > 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 :-)). > > While I agree that a more general solution is mostly a better solution, > I'm not aware of any file system at the moment that doesn't treat .. as > the parent directory, and Pharo already treats .. as a special case. Perhaps Pharo should adopts ".." as *its* platform independent "go-up" token. So the (relatively uncommon) platforms that don't conform will need an adapter. cheers -ben > > 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. > > >> and everything can be improved :) > > I still think this would be an improvement. :-) > > >> Esteban > > Thanks! > Alistair > > >>> 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) >>> ! ! >

March 29, 2017

Re: [Pharo-dev] NumberParser and exponent

by Ben Coman

On Wed, Mar 29, 2017 at 7:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > It is all a question of definition, I guess. > > (STON fromString: '2e2') = (STON fromString: '2E+2'). => true > > (STONJSON fromString: '2e2') = (STONJSON fromString: '2E+2'). => true > > (NeoNumberParser parse: '2e2') = (NeoNumberParser parse: '2E+2'). => true > > I believe the 'old school' Smalltalk syntax was limited on purpose, to avoid certain ambiguities maybe related to the IDE/tools. It is an open question whether that assumption is still valid. What was the original assumption/question? Or do we need to build a planet and wait ten million years for the white mice to discover this? > "Be clean & strict in what you produce, be flexible & liberal in what you accept." is a good motto. So we should allow 2E+2 ? Its a natural expectation that I think a few people get hit by. We have a new compiler which may bypasses the original issue. One consideration though would be cross-dialect compatibility. Squeak/Cuis are presumably lowercase only. Anyone know about VW, Dolphin? cheers -ben > >> On 29 Mar 2017, at 13:31, Henrik Nergaard <draagren(a)outlook.com> wrote: >> >> Hi, >> >> Apperently the number parser cannot parse '2E+2' correctly, is this a bug or a feature. >> ('2E+2' asNumber = '2e2' asNumber) >> >> Is there any reason to why parsing numbers with uppercase exponent letter is not allowed? >> (see NumberParser >> #exponentLetters) >> >> The parser has a method named #allowPlusSignInExponent sending self >> #allowPlusSign which just returns false. >> Is there any reason for not allowing the pluss sign / having it as true instead? >> (I guess it should at least be an ivar so it can be configured?). >> >> Best regards, >> Henrik > >

March 29, 2017

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

by Ben Coman

On Wed, Mar 29, 2017 at 6:39 PM, Stan Krupoderov <pashelper(a)gmail.com> wrote: > Hi Esteban, > >> we moved the paradigm a couple of years ago: each Pharo version comes with >> his own VM version > Thanks for clarification. I see your point. Will it be always the same way > or it should be changed once VM and Pharo 6 are stabilized? I would imagine.... it would be good for some engineering time to be allocated (if its feasible) to backport a small number of critical things like Athens fix to Pharo 5. We don't want to show we abandon it completely. Did it get a spring update? But resources are limited and Pharo 7 will have a completely new development process with git, which may need some priority care to iron out any issue arising out of its public use. > > How update scenario should be handled in this case on the user side? > Will it be File-out and File-in for all user changes? This would always be the same to move your code from a Pharo 5 image to a Pharo 6 image, unrelated to the VM. > > And unfortunately this doesn't add clarity on why Pharo 5 is so unstable out > of the box and if > there any plans to fix existing issues in Pharo 5. Do you have any thoughts > on this matter? > Can we help with this? Which specific issues? Do you have reproducible cases? > > On Wed, Mar 29, 2017 at 1: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, One thing I never quite get is this fluid alpha/beta/release status. So Pharo 6 is alpha now? and releases is two/three weeks? Thats a fairly narrow beta window ;) (but anyway I'm overall happy with the process & progress) >> >> >> >> 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... Not always feasible, but in reality you may get better support using the bleeding edge. Sure occasionally something blows up, but when that happens generally you can personally hang back a few builds. The bleeding edge is where most of the "Pharo" devs work, and if you can show a problem that affect where they are working, it is sometimes dealt with quite quickly. Now Pharo 5 I think may be a special case. The change to Spur and UFFI were *really*big* changes. So perhaps some problem remained to be ironed out. Pharo 6 has had another 12 months with Spur and UFFI. (but personally I don't remember major problems near Pharo 5 release) >> > >> > Also I was under the impression that newer VM should work with older >> > images, with the only exception being Cog/Spur change. I think this still remains Squeak policy. Pharo's policy is to push ahead more, and with limited resources that means we can't carry too much baggage. cheers -ben >> > 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) >> >>> >> >> >> >> >> > >> >> > > > > -- > Regards, > Stanislav S. Krupoderov

March 29, 2017

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

by Esteban Lorenzano

why does rubric checks for maxVal at first instance? > 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 Peter Uhnak

On Wed, Mar 29, 2017 at 12:05:58PM +0200, Esteban Lorenzano wrote: > we moved the paradigm a couple of years ago: each Pharo version comes with his own VM version (Other smalltalks do that too). Ah, I didn't know that; that clarifies the situation to me, so I will not shut up about incompatibility. :) > Being infinite backward compatible is a lot of pain :) Yes, I certainly understand the value in that. > > 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). > Maybe a suggestion... could we have a PharoVM facade that would delegate to the appropriate VM? (And ideally a all-vms.zip), because Pharo Launcher is not the only way Pharo is launched, so having to always think about which pharo to launch is bit annoying; e.g. on linux I use a shell script, but a canonical solution would be nice. Peter > 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

Rubric on 64 bit VM

by Andrei Chis

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] Path>>/ and ..

by Alistair Grant

On 29 March 2017 at 13:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > problem is this part: '../eâ > it has to be any of this: > > ('/a/b/c/d' asFileReference / '..' / 'e') path. "Path / 'a' / 'b' / 'c' / 'd' / '..' / 'e'" > ('/a/b/c/d' asFileReference parent / 'e') path. "Path / 'a' / 'b' / 'c' / 'e'" > > the rationale is that â..â is not modelled as a special kind of node, just a string. > and the reason is that thatâs commonly like that, but it doesnât *has > to* be like thatâ¦ there could be file systems that interprets .. as a > simple string. 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 :-)). While I agree that a more general solution is mostly a better solution, I'm not aware of any file system at the moment that doesn't treat .. as the parent directory, and Pharo already treats .. as a special case. 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. > and everything can be improved :) I still think this would be an improvement. :-) > Esteban Thanks! Alistair >> 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) >> ! !

March 29, 2017

Re: [Pharo-dev] NumberParser and exponent

by Sven Van Caekenberghe

It is all a question of definition, I guess. (STON fromString: '2e2') = (STON fromString: '2E+2'). => true (STONJSON fromString: '2e2') = (STONJSON fromString: '2E+2'). => true (NeoNumberParser parse: '2e2') = (NeoNumberParser parse: '2E+2'). => true I believe the 'old school' Smalltalk syntax was limited on purpose, to avoid certain ambiguities maybe related to the IDE/tools. It is an open question whether that assumption is still valid. "Be clean & strict in what you produce, be flexible & liberal in what you accept." is a good motto. > On 29 Mar 2017, at 13:31, Henrik Nergaard <draagren(a)outlook.com> wrote: > > Hi, > > Apperently the number parser cannot parse '2E+2' correctly, is this a bug or a feature. > ('2E+2' asNumber = '2e2' asNumber) > > Is there any reason to why parsing numbers with uppercase exponent letter is not allowed? > (see NumberParser >> #exponentLetters) > > The parser has a method named #allowPlusSignInExponent sending self >> #allowPlusSign which just returns false. > Is there any reason for not allowing the pluss sign / having it as true instead? > (I guess it should at least be an ivar so it can be configured?). > > Best regards, > Henrik

March 29, 2017

Re: [Pharo-dev] debugger inspector pane different than inspect pane?

by Tudor Girba

Hi Stef, Does the issue relate to the SmaCC tree presentation of an AST node? Cheers, Doru > On Mar 29, 2017, at 10:59 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Not aware of this bug. I tried to debug a few other objects that have custom tree presentations and they seem to work. I'll need a way to reproduce this. Can you paste the code of the custom presentation that is problematic. > > Cheers, > Andrei > > On Wed, Mar 29, 2017 at 9:11 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi andrei > > I'm debugger a node of a tree and in the debugger > the tree pane is empty. Now when I click on the node and inspect > it I get a tree representation. > > I do not know if you are aware of this behavior. > > Stef > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

March 29, 2017