- Pharo-dev - lists.pharo.org

Meanwhile in FogBugz: issue 20000

by Torsten Bergmann

Hi, our community today hit the 20000 issues mark in FogBugz. https://pharo.fogbugz.com/f/cases/20000 And a good change to once again say THANK YOU, especially to the ones who care most on - updating the bug tracker - fixing issues - reviewing issues - integrating issues - doing also the boring tasks in caring about the bugtracker - pushing Pharo in the right direction Just wow and impressive! Pharo 6 will be another nice milestone in a lively open source Smalltalk system that we all wanted to see becoming a reality! Thx T. BTW: The issue 20000 is about clickable URLs in Help Browser. Currently we copy them to clipboard - as we do not have web browser support in the default image. I guess it is too late to push this package into the image due to the freeze. So this slices nonetheless tries to improve the situation by checking if the unified WebBrowser support package (which is available since a year [1]) is loaded or not. If it is loaded it opens a real web browser. So when Pharo 6 is released and someone may lament about not being able for the URLs to really work we can point him to load the "WebBrowser" package and he should be fine. [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-April/12072…

April 27, 2017

[pharo-project/pharo-core]

by GitHub

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

April 27, 2017

[pharo-project/pharo-core] 7d63a4: 60473

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7d63a4ad238ecb55853f9a495424b126aa0dd0ef https://github.com/pharo-project/pharo-core/commit/7d63a4ad238ecb55853f9a49… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-27 (Thu, 27 Apr 2017) Changed paths: M FFI-Pools.package/FFIConstants.class/README.md M FFI-Pools.package/FFIConstants.class/class/pool initialization/initialize.st R FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeCallingConventions.st R FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeErrorConstants.st R FFI-Pools.package/FFIConstants.class/class/pool initialization/initializeTypeConstants.st A FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeCallingConventions.st A FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeErrorConstants.st A FFI-Pools.package/FFIConstants.class/class/private - initialization/initializeTypeConstants.st M Monticello.package/MCPackageManager.class/class/event registration/registerInterestOnSystemChangesOnAnnouncer_.st A Monticello.package/MCPackageManager.class/class/system changes/classRenamed_.st M Rubric.package/RubOpeningClosingDelimiterDecorator.class/instance/drawing/drawOn_.st M Rubric.package/RubTextSelectionColor.class/class/default accessing/oppositeDelimiterSelection.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60472.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60473.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60472.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60473.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Zodiac-Tests.package/ZdcSecureSocketStreamTests.class/instance/tests/testIsNativeSSLPluginPresent.st Log Message: ----------- 60473 19968 Class rename do not mark extending packages dirty https://pharo.fogbugz.com/f/cases/19968 19987 Bad highlight for matching parentheses with dark theme https://pharo.fogbugz.com/f/cases/19987 19995 Fix typo in testIsNativeSSLPluginPresent https://pharo.fogbugz.com/f/cases/19995 19996 Cleanup FFIConstants https://pharo.fogbugz.com/f/cases/19996 http://files.pharo.org/image/60/60473.zip

April 27, 2017

Re: [Pharo-dev] OmSessionStore and SnapshotDone event (was: saving an image on windows and opening it on mac problems)

by Martin Dias

El 26/4/2017 12:22, "Andrei Chis" <chisvasileandrei(a)gmail.com> escribiÃ³: Hi, OmSessionStore registers an action (OmSessionStore>>#store) when the event SnapshotDone is triggered. However this event is triggered immediately when an image is opened after being saved, before the file system was reset. This means that OmSessionStore>>#store is called before the file system is reset. Hence, if you save an image on windows and open it on mac you run into issues as OmSessionStore>>#store performs file operations that will work with a WindowsStore instead of a MacStore. Does OmSessionStore need to register to SnapshotDone events? When the image is opened OmSessionStore>>#store will be called anyway as OmSessionStore registers a start-up action. #store doesn' t need to be done twice. I can see it tonight. MartÃn Cheers, Andrei

April 27, 2017

Re: [Pharo-dev] Code colors with dark theme (out of box)

by Henrik Nergaard

>Looks like changing one color changes back to the default theme coloring ... but I wonder why it changes the theme when I manipulate only the comment color? SHPreferences commentStyle class. "SHStyleElement" Changing any attribue in a ShStyleElement object also sends `SHPreferences applyStyle`. This method creates a new styletable based on the SHStyleElement objects in the Group class variable in SHPreferences. These object get their initial color and emphasis from the the class variable CustomStyleTable also in SHPreferences, which is inited from #defaultStyleTable (blueTheme), and this is why the whole theme changes when you only change one color. >Is this a bug? Probably. Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Torsten Bergmann <astares(a)gmx.de> Sendt: 27. april 2017 11:51:12 Til: pharo-dev(a)lists.pharo.org Emne: Re: [Pharo-dev] Code colors with dark theme (out of box) Thanks Henrik and Cyril. I now tried on a second machine and the default looks fine. I checked and there was a setting left that changes the color for Smalltalk "comments" only: SHPreferences commentStyle color: (Color r: 0.06 g: 0.358 b: 0.06 alpha: 1.0) from grey (Pharo light theme) to greenish (like VisualStudio comments). Because this looks more professional and aligns with Eclipse/VisualStudio/... and others. Looks like changing one color changes back to the default theme coloring ... but I wonder why it changes the theme when I manipulate only the comment color? Is this a bug? Thanks T. Gesendet: Donnerstag, 27. April 2017 um 11:33 Uhr Von: "Henrik Nergaard" <draagren(a)outlook.com> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Code colors with dark theme (out of box) Tested with a clean 60471 and the correct code theme is used for me (primary white text color). What are these values for you: ---------------------- Smalltalk ui theme. "a Pharo3DarkTheme" SHTextStylerST80 styleTable = Smalltalk ui theme shStyleTable. "true" SHRBTextStyler styleTable = Smalltalk ui theme shStyleTable "true" ---------------------- My guess is that you have some theme setting that changed just the code color back to the default theme coloring. Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Torsten Bergmann <astares(a)gmx.de> Sendt: 27. april 2017 10:07:42 Til: Pharo Development List Emne: [Pharo-dev] Code colors with dark theme (out of box) The damn deal might be done to switch Pharo 6 now to the dark theme - but my impression is that the way we provide it now lets say is "not very comfortable". When - opening Pharo 6.0 Latest update: #60471 (as of today) - opening a new Nautilus browser the code color settings are unreadable (see screenshot). I suggest to use black text on black background in the future to improve the situation even further ;) Are there already any bugs to have a better color code scheme for the dark theme? Have fun T.

April 27, 2017

[pharo-project/pharo-core]

by GitHub

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

April 27, 2017

[pharo-project/pharo-core] f71be9: 60472

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f71be96bc15de12d74e339971558b0e77b3e9bda https://github.com/pharo-project/pharo-core/commit/f71be96bc15de12d74e33997… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-27 (Thu, 27 Apr 2017) Changed paths: M BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/postload_package_.st M SUnit-UITesting.package/SimulateKeystrokesSpecification.class/instance/tests/testSimulateKeystroke.st M SUnit-UITesting.package/SimulateKeystrokesSpecification.class/instance/tests/testSimulateKeystrokes.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60471.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60472.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60471.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60472.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-SessionManager.package/SessionManager.class/README.md M Text-Edition.package/TextEditor.class/instance/menu messages/changeStyle.st Log Message: ----------- 60472 19992 Use assert:equals: in simulateKeyStroke tests https://pharo.fogbugz.com/f/cases/19992 19463 Improve SessionManager class comment https://pharo.fogbugz.com/f/cases/19463 19983 activate the Dark theme by default in the bootstrapped image https://pharo.fogbugz.com/f/cases/19983 19991 Use of deprecated name method in TextEditor>>changeStyle https://pharo.fogbugz.com/f/cases/19991 http://files.pharo.org/image/60/60472.zip

April 27, 2017

Re: [Pharo-dev] Code colors with dark theme (out of box)

by Torsten Bergmann

April 27, 2017

Re: [Pharo-dev] Code colors with dark theme (out of box)

by Henrik Nergaard

Tested with a clean 60471 and the correct code theme is used for me (primary white text color). What are these values for you: ---------------------- Smalltalk ui theme. "a Pharo3DarkTheme" SHTextStylerST80 styleTable = Smalltalk ui theme shStyleTable. "true" SHRBTextStyler styleTable = Smalltalk ui theme shStyleTable "true" ---------------------- My guess is that you have some theme setting that changed just the code color back to the default theme coloring. Best regards, Henrik ________________________________ Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Torsten Bergmann <astares(a)gmx.de> Sendt: 27. april 2017 10:07:42 Til: Pharo Development List Emne: [Pharo-dev] Code colors with dark theme (out of box) The damn deal might be done to switch Pharo 6 now to the dark theme - but my impression is that the way we provide it now lets say is "not very comfortable". When - opening Pharo 6.0 Latest update: #60471 (as of today) - opening a new Nautilus browser the code color settings are unreadable (see screenshot). I suggest to use black text on black background in the future to improve the situation even further ;) Are there already any bugs to have a better color code scheme for the dark theme? Have fun T.

April 27, 2017

Re: [Pharo-dev] saving an image on windows and opening it on mac problems

by Andrei Chis

Hi Martin, On Thu, Apr 27, 2017 at 6:14 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi Andrei, > > Could you tell me what's your "EpMonitor current sessionStore baseLocator" > ? > It's 'a FileLocator {localDirectory}\ombu-sessions' > > By default it's a FileLocator, but maybe you personalized it and setted a > FileReference. FileLocators don't have a WindowsStore but FileReference > do. > I started another thread 'OmSessionStore and SnapshotDone event' where I described the error better. > > The OmSessionStore is part of Epicea, and has a startUp: that executes the > #ensureCreateDirectory. Well, maybe it shouldn't be done on start up but > when a change happens... I should try this. > The issue is that #ensureCreateDirectory is called before the file system is initialized. Even if a FileLocator is used for #baseLocator, #ensureCreateDirectory will need to resolve the file and access the file system. Cheers, Andrei > > MartÃn > > On Wed, Apr 26, 2017 at 3:40 PM, H. Hirzel <hannes.hirzel(a)gmail.com> > wrote: > >> What about loading some TTF fonts into the image? >> >> --Hannes >> >> On 4/26/17, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> > I'd say that one should clear all fonts being loaded, refresh the list >> of >> > available fonts because they are on another location (and this should >> > happen even moving from windows to windows), and switch back to a >> default >> > font that is sure to be available. >> > >> > I got an issue with the "hack" font because the new version changed the >> > file names of the fonts and the system died. >> > >> > That should already solve some problems. >> > >> > Phil >> > >> > On Wed, Apr 26, 2017 at 5:10 PM, Andrei Chis < >> chisvasileandrei(a)gmail.com> >> > wrote: >> > >> >> Any hints about how to handle Freetype fonts? >> >> Right now I'm getting also some segmentation faults when opening on mac >> >> an >> >> image saved on windows, that seem related to Freetype fonts. >> >> >> >> On Wed, Apr 26, 2017 at 5:04 PM, phil(a)highoctane.be < >> phil(a)highoctane.be> >> >> wrote: >> >> >> >>> You will also face serious fun with Freetype fonts. >> >>> >> >>> Phil >> >>> >> >>> On Wed, Apr 26, 2017 at 3:06 PM, Andrei Chis >> >>> <chisvasileandrei(a)gmail.com> >> >>> wrote: >> >>> >> >>>> Hi all, >> >>>> >> >>>> I saw that there are a few issues about images saved on an operating >> >>>> system not working when opened on other operating systems: >> >>>> - https://pharo.fogbugz.com/f/cases/19852/Unable-to-open-ima >> >>>> ge-in-OSX-after-it-has-been-updated-in-Windows >> >>>> - https://pharo.fogbugz.com/f/cases/19869/Infinite-loop-on-m >> >>>> ac-when-opening-an-image-saved-on-windows >> >>>> - https://pharo.fogbugz.com/f/cases/19272/Image-freezes-on-L >> >>>> inux-if-it-was-previously-saved-on-Windows >> >>>> - http://forum.world.st/Image-freezes-on-Linux-if-it-was-pre >> >>>> viously-saved-on-Windows-td4903258.html >> >>>> >> >>>> I gave the fix in case 19869 a try and with it I can save an image on >> >>>> windows and open it on mac, however, there are some side effects. >> >>>> First several folders having the following name are created in the >> >>>> image >> >>>> folder: >> >>>> >> >>>> '\Users\andrei\test-image' >> >>>> '\Users\andrei\test-image\pharo-local\' >> >>>> '\Users\andrei\test-image\pharo-local\ombu-sessions' >> >>>> >> >>>> Second, I can only open the image on man once. The second time I get >> >>>> the >> >>>> following stack: >> >>>> >> >>>> [31mPrimitiveFailed: primitive #createDirectory: in WindowsStore >> failed >> >>>> [0mWindowsStore(Object)>>primitiveFailed: >> >>>> WindowsStore(Object)>>primitiveFailed >> >>>> WindowsStore(DiskStore)>>createDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> WindowsStore(FileSystemStore)>>ensureCreateDirectory: >> >>>> FileSystem>>ensureCreateDirectory: >> >>>> FileReference>>ensureCreateDirectory >> >>>> OmSessionStore>>resetWithStoreNamed: >> >>>> OmSessionStore>>resetWithNextStoreName >> >>>> OmSessionStore>>store >> >>>> WeakMessageSend>>value >> >>>> WeakMessageSend>>cull: >> >>>> WeakMessageSend>>cull:cull: >> >>>> [ action cull: arg1 cull: announcer ] in >> LegacyWeakSubscription(WeakAnn >> >>>> ouncementSubscription)>>deliver: in Block: [ action cull: arg1 cull: >> >>>> announcer ] >> >>>> BlockClosure>>on:do: >> >>>> BlockClosure>>on:fork: >> >>>> LegacyWeakSubscription(WeakAnnouncementSubscription)>>deliver: >> >>>> [ tmp4 deliver: arg1 ] in SubscriptionRegistry>>deliver: >> to:startingAt: >> >>>> in Block: [ tmp4 deliver: arg1 ] >> >>>> BlockClosure>>ifCurtailed: >> >>>> SubscriptionRegistry>>deliver:to:startingAt: >> >>>> SubscriptionRegistry>>deliver:to: >> >>>> SubscriptionRegistry>>deliver: >> >>>> SystemAnnouncer(Announcer)>>announce: >> >>>> SystemAnnouncer>>announce: >> >>>> SystemAnnouncer>>snapshotDone: >> >>>> SessionManager>>snapshot:andQuit: >> >>>> [0m >> >>>> >> >>>> So it seems that OmSessionStore is not reset and holds a reference >> to a >> >>>> the windows path which it tries to create. >> >>>> >> >>>> Cheers, >> >>>> Andrei >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> > >> >> >

April 27, 2017