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

Re: [Pharo-dev] Release deferred to next Tuesday :(

by Ben Coman

On Thu, Jun 1, 2017 at 9:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi list, > > yes, this release is being a pain. > anyway, yesterday after asking for testI found two blocking issues and one > ânice to haveâ and I needed to work on them. > Blocking issues were: > > 1) Athens (with Fonts ) was not working on 64bits and because of that, > Roassal was not either. > 2) There is a problem in VM packaging which packages as files what should > be symlinks.\ > > The nice to have: > > It seems there are english problems in the welcome browser (and in the > STAGE pages). It would be nice if some native speaker takes a look :) > I'll do this tomorrow. cheers -ben > > I already fixed (1) and Iâm working on (2), but the release is deferred to > Tuesday because: a) we want to test. b) you never release on friday c) > monday is holiday here :) > > So well, that. > > Iâm sorry. > > Esteban > > > > >

June 1, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by Esteban Lorenzano

This is because you need to put the vm in /Applications (because is not signed) We will fix that, but not just now :) > On 1 Jun 2017, at 18:29, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> http://files.pharo.org/platform/Pharo6.0-mac.zip >> http://files.pharo.org/platform/Pharo6.0-64-mac.zip > > Both above give the same result I described in > http://forum.world.st/Launcher-and-Pharo-6-Errors-on-Mac-td4947652.html > > Namely: On image start, I get "PrimitiveFailed: primitive #createDirectory: > in MacStore failed" for > /private/var/folders/fv/8j408sn92bb59k5ggw8cd3kc0000gn/T/AppTranslocation/4EF86F92-66D6-4944-8B30-FBCD96118FCC/d/Pharo.app/Contents/Resources/pharo-local > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/please-test-download-for-Pharo-6-0-tp4948720p4948852.… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 1, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Esteban Lorenzano

What is in bintray now is the same as vm latest :) > On 1 Jun 2017, at 18:30, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Tobias has commited a fix in cog branch a few days ago. > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… > So could you try latest Vm from bintray and report? > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… > > > 2017-06-01 16:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> I am not sure what is the status with this issue, but it seems clear that there exists a problem, so I opened an issue to accumulate the different opinions: >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >> >> Cheers, >> Doru >> >> >> >> > On May 29, 2017, at 9:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > ---------- Forwarded message ---------- >> > From: Tobias Pape <Das.Linux(a)gmx.de> >> > Date: Mon, May 29, 2017 at 12:09 AM >> > Subject: Re: [Vm-dev] multiple crashes on macOS Sierra >> > To: John McIntosh <johnmci(a)smalltalkconsulting.com> >> > Cc: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> > >> > >> > >> > Hi John, all >> > >> > >> > > On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: >> > > >> > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added >> > > >> > > >> > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) >> > > location:[theEvent locationInWindow] >> > > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) >> > > timestamp:[theEvent timestamp] >> > > windowNumber:[theEvent windowNumber] >> > > context:nil >> > > characters:@"" >> > > charactersIgnoringModifiers:@"" >> > > isARepeat:NO >> > > keyCode:[theEvent keyCode]]); >> > > >> > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent >> > >> > That's correct. >> > >> > > >> > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/… >> > > >> > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; >> > >> > Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() >> > I read this https://developer.apple.com/reference/appkit/nsevent/1533943-keyeventwithty… >> > and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. >> > I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. >> > >> > >> > I now understand that I should only autorelease alloc/inited stuff. >> > >> > So you may be right here. >> > >> > Fixed in 0f07ffbed >> > >> > Best regards >> > -Tobias >> > >> > > >> > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. >> > >> > [snip] >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> >

June 1, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Nicolas Cellier

Tobias has commited a fix in cog branch a few days ago. https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… So could you try latest Vm from bintray and report? https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… 2017-06-01 16:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I am not sure what is the status with this issue, but it seems clear that > there exists a problem, so I opened an issue to accumulate the different > opinions: > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 > > Cheers, > Doru > > > > > On May 29, 2017, at 9:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > ---------- Forwarded message ---------- > > From: Tobias Pape <Das.Linux(a)gmx.de> > > Date: Mon, May 29, 2017 at 12:09 AM > > Subject: Re: [Vm-dev] multiple crashes on macOS Sierra > > To: John McIntosh <johnmci(a)smalltalkconsulting.com> > > Cc: Squeak Virtual Machine Development Discussion <vm-dev@lists. > squeakfoundation.org> > > > > > > > > Hi John, all > > > > > > > On 28.05.2017, at 22:12, John McIntosh <johnmci@smalltalkconsulting. > com> wrote: > > > > > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) > Tobias added > > > > > > > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent > keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > > > > location:[theEvent locationInWindow] > > > > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > > > > timestamp:[theEvent timestamp] > > > > windowNumber:[theEvent windowNumber] > > > > context:nil > > > > characters:@"" > > > > charactersIgnoringModifiers:@"" > > > > isARepeat:NO > > > > keyCode:[theEvent keyCode]]); > > > > > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent > > > > That's correct. > > > > > > > > However I believe this is incorrect as the NSEvent class side method > is by the old non-arc memory rules implicitly an autoreleased object, so > doing the AUTORELEASEOBJ() might cause side effects. > https://developer.apple.com/library/content/documentation/ > Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html > > > > > > + (NSEvent *)keyEventWithType:(NSEventType)type > location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags > timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum > context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys > charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag > keyCode:(unsigned short)code; > > > > Well, I have not found a reference to how this relates to autorelease > (the Apple docs are becoming increasingly useless these days :() > > I read this https://developer.apple.com/reference/appkit/nsevent/ > 1533943-keyeventwithtype?language=objc > > and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h > and although autorelase pops up somewhere in the file, it does not > somewhere near the declaration. > > I read through the code an found quite a few AUTORELEASEOBJ() around > object creation and (apparently wrongly) thought I would need that here. > > > > > > I now understand that I should only autorelease alloc/inited stuff. > > > > So you may be right here. > > > > Fixed in 0f07ffbed > > > > Best regards > > -Tobias > > > > > > > > If Tobias can verify and submit a change we can see if that affects > the behaviour we have been observing. Note that I"ve not been able to > recreate the problem, but in eyeballing the code this leaps out as suspect. > > > > [snip] > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

June 1, 2017

Re: [Pharo-dev] please test download for Pharo 6.0

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > http://files.pharo.org/platform/Pharo6.0-mac.zip > http://files.pharo.org/platform/Pharo6.0-64-mac.zip Both above give the same result I described in http://forum.world.st/Launcher-and-Pharo-6-Errors-on-Mac-td4947652.html Namely: On image start, I get "PrimitiveFailed: primitive #createDirectory: in MacStore failed" for /private/var/folders/fv/8j408sn92bb59k5ggw8cd3kc0000gn/T/AppTranslocation/4EF86F92-66D6-4944-8B30-FBCD96118FCC/d/Pharo.app/Contents/Resources/pharo-local ----- Cheers, Sean -- View this message in context: http://forum.world.st/please-test-download-for-Pharo-6-0-tp4948720p4948852.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Sven Van Caekenberghe

> On 1 Jun 2017, at 16:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I can confirm that this fixes the problems that I reported. I guess we should include this patch ? I'll try to make an issue and patch later tonight > This fixes some of the failing tests in Kernel-Tests-Numbers but not all of them (some others are really hardcoded constants in the tests). I think that I can fix most tests by adding some #wordSize tests

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Sven Van Caekenberghe

> On 1 Jun 2017, at 15:59, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > SmallInteger >> digitAt: has an n > 4 ifTrue: [^0] check, in 64bit this needs > to check against 8. > (The value represents max number of 8-bit digits in a SmallInteger) I guess that the special case in there should also be adapted to: self = SmallInteger minVal ifTrue: ["Can't negate minVal -- treat specially" ^ #(0 0 0 0 0 0 0 16) at: n]. Correct ?

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Eliot Miranda

Hi Henrik, > On Jun 1, 2017, at 7:10 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > For a solution that works without change in 32/64 migration, one could use > self class maxVal digitLength > > ... but there's quite a bit of calculation in digitLength. > > Speaking of excessive calculation; > SmallInteger class >> startUp: isImageStarting > "The image is either being newly started (isImageStarting is true), or it's > just been snapshotted. > If this has just been a snapshot, skip all the startup stuff." > | next val | > isImageStarting ifFalse: [^self]. > val := -32768. "Assume at least 16 bits" > [next := val + val. > next class == self] whileTrue: > [val := next]. > minVal := val. > maxVal := -1 - val > > ... really? If this actually runs on 64bit image startup, that's quite > impressive! This is hardly excessive :-). It only takes 45 or 46 iterations to discover the max 64-bit integer. The code is modeled on the Smalltalk-80 v 2 code that was on the original PARC Smalltalk tape which was there for 32-bit systems; the PARC Smalltalks were 16-bit. Squeak, and hence Pharo, derived from Smalltalk-80 v 1 and so didn't have this code. Cheers, Eliot

June 1, 2017

Re: [Pharo-dev] Confused about Floats on 64-bit Pharo 6

by Eliot Miranda

Hi Henrik, Hi Esteban, Hi Marcus, > On Jun 1, 2017, at 6:59 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > SmallInteger >> digitAt: has an n > 4 ifTrue: [^0] check, in 64bit this needs > to check against 8. > (The value represents max number of 8-bit digits in a SmallInteger) In general you need to take a careful look at the differences between Squeak 4.6 and Squeak trunk in SmallInteger and Float to harvest all the fixes for 64-bit SmallIntegers and SmallFloat64/BoxedFloat64. > "I thought BoxedFloat64 should not be used in 64-bit ?" > It will be used for some large exponents, search for "immediate float" in > https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ > for a good description. > > "Also, should #emin, #emax and friends not be different for SmallFloat64 ? " > No, it's an implementation detail. > Both float classes represent 64bit floating points with emin/emax as listed. > When one is insufficient; it should be swapped to the other automatically, > in a manner similar to Byte/WideStrings instances. > > Cheers, > Henry

June 1, 2017

Re: [Pharo-dev] Release deferred to next Tuesday :(

by Tudor Girba

Hi, > On Jun 1, 2017, at 4:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 1 Jun 2017, at 16:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Thanks for the update Esteban. >> >> There is also the issue of typing on macOS Sierra: >> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >> >> It is really annoying (at least for me), but I think we can treat this one as something that can be dealt with later and once itâs fixed we change the 6.0 VM. What do you think? > > this is not a pharo bug in general so it should not stop the release. > I will promote a new vm to stable if things are ok, and that one will have a -possible- fix (but no idea, we will need to test). Thatâs what I said as well :) Doru > cheers, > Esteban > >> >> Cheers, >> Doru >> >> >>> On Jun 1, 2017, at 3:27 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> Hi list, >>> >>> yes, this release is being a pain. >>> anyway, yesterday after asking for testI found two blocking issues and one ânice to haveâ and I needed to work on them. >>> Blocking issues were: >>> >>> 1) Athens (with Fonts ) was not working on 64bits and because of that, Roassal was not either. >>> 2) There is a problem in VM packaging which packages as files what should be symlinks.\ >>> >>> The nice to have: >>> >>> It seems there are english problems in the welcome browser (and in the STAGE pages). It would be nice if some native speaker takes a look :) >>> >>> I already fixed (1) and Iâm working on (2), but the release is deferred to Tuesday because: a) we want to test. b) you never release on friday c) monday is holiday here :) >>> >>> So well, that. >>> >>> Iâm sorry. >>> >>> Esteban >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Some battles are better lost than fought." >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

June 1, 2017