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

Re: [Pharo-dev] Is Moz2D ready for Android?

by ClÃ©ment Bera

Hey Denis. Basically, does firefox work in Android ? Yes. Therefore, Moz2D can be built for Android. Moz2D uses internally one of these 2 libraries: Cairo or Skia. Cairo is supposed to be working on Android. Skia works for sure on Android as it has been the default graphic framework there since the beginning. I don't see builds online for Moz2D and Android, Moz2D is used both in Firefox and Servo, and both work in Android. Anyway it's not clear anyone is checking builds of Moz2D are passing any tests outside of Firefox and Servo. On Tue, Feb 21, 2017 at 4:00 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > It is just theoretical question to know. > Is Android supported by Moz2D library? > And how difficult would be compile necessary plugins for Bloc on Android? > > Best regards, > Denis >

Feb. 21, 2017

Is Moz2D ready for Android?

by Denis Kudriashov

Hi. It is just theoretical question to know. Is Android supported by Moz2D library? And how difficult would be compile necessary plugins for Bloc on Android? Best regards, Denis

Feb. 21, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 21, 2017

[pharo-project/pharo-core] 54984d: 60406

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 54984d819f4c7d14b63fdf7dd0f9927c8c013a63 https://github.com/pharo-project/pharo-core/commit/54984d819f4c7d14b63fdf7d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-21 (Tue, 21 Feb 2017) Changed paths: A Kernel.package/CombinedChar.class/class/initialization/parseCompositionMappingFrom_.st M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/accessing colors/secondarySelectionColor.st M Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/computeSecondarySelectionShapesFrom_to_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60405.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60406.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60405.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60406.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TClassDescription.class/instance/private/newInstanceFrom_variable_size_.st R Unicode-Initialization.package/extension/CombinedChar/class/parseCompositionMappingFrom_.st Log Message: ----------- 60406 19731 secondary selection color should be not modified https://pharo.fogbugz.com/f/cases/19731 19538 When replacing a slot in class by WeakSlot, it fails to migrate existing instances https://pharo.fogbugz.com/f/cases/19538 19603 composition mapping should be initialized on bootstrapped image https://pharo.fogbugz.com/f/cases/19603 http://files.pharo.org/image/60/60406.zip

Feb. 21, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 21, 2017

[pharo-project/pharo-core] 663230: 60405

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 66323053a8e12e95372e9602cc1ee41ccabd9a64 https://github.com/pharo-project/pharo-core/commit/66323053a8e12e95372e9602… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-21 (Tue, 21 Feb 2017) Changed paths: M BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/postload_package_.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/accessing colors/lessConspicuousColorFrom_.st M Polymorph-Widgets.package/UITheme.class/class/accessing/current_.st A Polymorph-Widgets.package/UITheme.class/instance/accessing/lessConspicuousColorFrom_.st M Rubric.package/RubPrimarySelectionMorph.class/instance/accessing/selectionColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60404.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60405.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60404.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60405.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHTextStylerST80.class/class/style table/darkStyleTable.st M SublimishTheme.package/SublimishTheme.class/class/settings/newDefaultSettings.st Log Message: ----------- 60405 19730 RubPrimarySelectionMorph>>#selectionColor does not respect theme style https://pharo.fogbugz.com/f/cases/19730 19735 Desktop color issue in the bootstrapped image https://pharo.fogbugz.com/f/cases/19735 19658 Red in Dark Theme is plain bad https://pharo.fogbugz.com/f/cases/19658 19734 Sublimish theme menu text selection should be not black https://pharo.fogbugz.com/f/cases/19734 http://files.pharo.org/image/60/60405.zip

Feb. 21, 2017

Re: [Pharo-dev] ***Important*** Snapcraft pharo package for Pharo 50

by Holger Freyther

> On 19 Jan 2017, at 00:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi! > wowâ¦ this is super good, Holger, I want this since ages ! Great. The obs people will create a pharo organization for us. > merge is done. > there are 5 failing tests (and I still do not configure the tests for 64bits)â¦ I will work a bit on this this week, but Iâm finishing 3 things at the same time now (FFI 64bits, iceberg multi-remotes and this) so it will arriveâ¦ anytime soon. What is the state of the unit tests and which tests fail? Are these genuine regressions compared to the Pharo5 VM? > I wouldnât wait until the tests are running :) I am struggling with the squeak-vm build system right now. It is doing so many things in a non-standard way and it is getting more and not less. I am currently struggling with the install part. To illustrate the challenge: * Standard systems would use DESTDIR as variable to not directly install to /usr/bin/foo but $(DESTDIR)/usr/bin/foo. Squeakvm has only "prefix" * There is a script to rename "squeak" to "pharo" after things were installed * It creates a "squeak" shell script that tries to find the real squeak, this will make dual (64bit, 32bit) installation more hard as well... let's see how far I get today holger

Feb. 21, 2017

Re: [Pharo-dev] WeakValueDictionary: shouldn't be "absent" after GC?

by Denis Kudriashov

Ok. Question was from Martin. What behaviour we want from WeakValueDictionary for garbaged values? dictionary := WeakValueDictionary with: 'hello' -> 'world' copy. > Smalltalk garbageCollect. > { > dictionary values includes: nil. > dictionary at: 'hello'. > dictionary at: 'hello' ifAbsent: [ 'absent' ]. > dictionary at: 'hello' ifAbsentPut: [ 'put' ]. > } > is: > #(true nil nil nil) My opinion is: it should work in same way when 'hello' item is absent. It is intuitive for me and It would be consistent to WeakSet behaviour: set := WeakSet with: Object new. Smalltalk garbageCollect. set includes: nil "=>false" But after writing it I realized how much WeakSet is inconsistent: set := WeakSet with: Object new. Smalltalk garbageCollect. set isEmpty. "=>false" set size. "=>1". set anyOne. "=> nil" set includes: nil. "=>false" set collect: #yourself. "=>a WeakSet()" We definitely have something to improve here. 2017-02-21 13:36 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Everything has a tradeoff. I do not understand the question. > > On Tue, Feb 21, 2017 at 1:19 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-02-21 13:07 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> But in any case, whatever the alternative you give users, they must >>> understand the tradeoff. If all Weak*Dictionaries were subscribed by >>> default to the weak registry for cleanup, that would provoke a lot of >>> overhead during garbage collection. >>> >> >> So you think my suggestion for implementation will lead to some tradeoff? >> What exactly? (if yes). >> > >

Feb. 21, 2017

Re: [Pharo-dev] WeakValueDictionary: shouldn't be "absent" after GC?

by Guillermo Polito

Everything has a tradeoff. I do not understand the question. On Tue, Feb 21, 2017 at 1:19 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-21 13:07 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> But in any case, whatever the alternative you give users, they must >> understand the tradeoff. If all Weak*Dictionaries were subscribed by >> default to the weak registry for cleanup, that would provoke a lot of >> overhead during garbage collection. >> > > So you think my suggestion for implementation will lead to some tradeoff? > What exactly? (if yes). >

Feb. 21, 2017

Re: [Pharo-dev] WeakValueDictionary: shouldn't be "absent" after GC?

by Denis Kudriashov

2017-02-21 13:07 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But in any case, whatever the alternative you give users, they must > understand the tradeoff. If all Weak*Dictionaries were subscribed by > default to the weak registry for cleanup, that would provoke a lot of > overhead during garbage collection. > So you think my suggestion for implementation will lead to some tradeoff? What exactly? (if yes).

Feb. 21, 2017