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

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

by Eliot Miranda

Hi Marcus, > On Jun 1, 2017, at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 31 May 2017, at 17:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> OK, I quickly tested the Mac 32 and 64 bit versions, installing some code, running unit tests, clicking around. Both are working perfectly. >> >> The Pharo Welcome window with the clickable coloured links and the tabs is particularly nice. >> >> The need to move to /Applications is just one thing, you also have to allow the app to actually run (with my settings, by right clicking on it, and giving permission; but even then it stops the first time and only runs the second time; no big deal for me but it might be confusing for others). >> > > I am looking into signingâ¦ but as we did not have it for Pharo5, it should not hold up the release. > > The /Applications thing is related to signing, too. (the container, we should ship it with a signed .dmg). If possible please include the code in opensmalltalk/vm. There are good starting points: In {build.macos32x86,build.macos64x64}/newspeak.cog.spur/installer is code that builds the newspeak .dmg, but does not sign it. There's a Makefile. In {build.macos32x86,build.macos64x64}/common/Makefile.app is code to sign an .app bundle using codesign. The certificate to use is indicated via an environment variable as described in {build.macos32x86,build.macos64x64}/HowToBuild. > > I will look into it for next week, but this is a bit independend of the release.. > > Marcus HTH Eliot

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 can confirm that this fixes the problems that I reported. I guess we should include this patch ? 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 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. OK, I understand better now. Thank you both. > Cheers, > Henry > > > > -- > View this message in context: http://forum.world.st/Confused-about-Floats-on-64-bit-Pharo-6-tp4948805p494… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 1, 2017

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

by Esteban Lorenzano

> 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). 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." > > > > >

June 1, 2017

[pharo-project/pharo-core]

by GitHub

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

June 1, 2017

[pharo-project/pharo-core] 31c6d3: 60498

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 31c6d36f15cca1e4e94006975def2ed3dec3e8ab https://github.com/pharo-project/pharo-core/commit/31c6d36f15cca1e4e9400697… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-01 (Thu, 01 Jun 2017) Changed paths: M Athens-Cairo.package/AthensCairoMatrix.class/class/field definition/fieldsDesc.st M Athens-Cairo.package/CairoFontFace.class/class/instance creation/fromFreetypeFace_.st M Athens-Cairo.package/CairoFontFace.class/class/instance creation/primFtFace_loadFlags_.st M Athens-Cairo.package/CairoScaledFont.class/class/instance creation/fromFreetypeFont_.st M Morphic-Base.package/SystemProgressItemMorph.class/instance/private/refresh.st M Morphic-Base.package/SystemProgressMorph.class/instance/updating/refresh.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60497.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60498.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60497.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60498.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60498 20095 SystemProgressMorph should call doOneCycleNow on refresh only when active process is UIProcess https://pharo.fogbugz.com/f/cases/20095 20099 Cairo fonts crashing on 64bits https://pharo.fogbugz.com/f/cases/20099 http://files.pharo.org/image/60/60498.zip

June 1, 2017

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

by Tudor Girba

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? 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."

June 1, 2017

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

by Tudor Girba

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] Confused about Floats on 64-bit Pharo 6

by Henrik Sperre Johansen

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! -- View this message in context: http://forum.world.st/Confused-about-Floats-on-64-bit-Pharo-6-tp4948805p494… 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 Henrik Sperre Johansen

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 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 -- View this message in context: http://forum.world.st/Confused-about-Floats-on-64-bit-Pharo-6-tp4948805p494… 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 Nicolas Cellier

2017-06-01 15:37 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 1 Jun 2017, at 15:29, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > Hi Sven, > > SmallFloat64 consumes 3bits taken from exponent for tagging immediate > value. > > So very small values and very large values don't fit in SmallFloat64 and > require a BoxedFloat64. > > > > I don't think we should change emin and emax though. > > The reason is that emin and emax are public methods for accessing the > underlying floating point model. > > Small/Boxed Float are implementation details, they both implement the > same float model with different levels of optimization. > > If I am on 64-bit and SmallFloat64 is used (the default, right ?), then I > have a smaller exponent range (right ?), so I should be able to access meta > info about the currently applying limits, no ? > Yes and no. Yes if you care about implementation details. No if you delegate to abstract class Float, ignore the details and let the VM entirely deal with those. My opinion is that most applications should not care of those details and should avoid duplicating the VM job. Except maybe very optimized or low level libraries (Fuel?) > > I recently added that to NeoJSON to protect against overly large/small > exponents when reading floats, like 1e1231231231. > Good thing! This should be backported to number parsers, See https://codegolf.stackexchange.com/questions/7197/crash-your-favorite-compi… > > I understand about this being an implementation detail, but if the choice > of implementation changes the range, it seems important to be able to know > this, one way or another. > > It does not change the range of the underlying abstract Float model. If those meta-data are really needed, you must find another accessor than emin and emax or you will break the model. (2.0 timesTwoPower: Float emax // 8 + 1) is a BoxedFloat64. It's predecessor is Small. I let you find the ones near emin by yourself. > For the rest of the report, it's a bug we will have to track catch and > fix ASAP > > Thanks! > > > 2017-06-01 14:53 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > I am working in Pharo 6 RC, 64-bit on macOS 10.12.5 > > > > One of the tests of STON fails, #testFloat and I got confused about > Floats on 64-bit Pharo 6. > > > > Is there a write-up that explains the new/changed situation ? > > > > Because, what I see is the following: > > > > Float pi. > > 1.3. > > > > Both the above give me SmallFloat64 instances. > > > > (10 raisedTo: 100) asFloat. > > 1.0e100. > > 10.0 raisedTo: 100. > > > > All 3 above give me BoxedFloat64 instance. > > But the first 2 give wrong results (correct answer is 1.0e100) ! > > > > (10 raisedTo: 100) asFloat. > > "5.15323791002091e91" > > > > 1.0e100. > > "5.15323791002091e91" > > > > Why ? > > > > BoxedFloat64 allInstances. > > SmallFloat64 allInstances. > > > > The first is not-empty, the second is (logical since these are immediate > values). > > I thought BoxedFloat64 should not be used in 64-bit ? > > > > Also, should #emin, #emax and friends not be different for SmallFloat64 ? > > > > Sven > > > > >

June 1, 2017