May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FogBugz (Case [Issue]13315) Morphic - NewList without icons

by Aliaksei Syrel

No, I don't have both of them. It would be great to have a Jenkins job. With increasing amount of tests it already becomes complicated to check stability. Cheers, Alex On May 30, 2015 7:41 AM, "stepharo" <stepharo(a)free.fr> wrote: > Aliaksei > > do you have a configuration of Brick? > I can do one and do you have a jenkins job? > Because we can do it. > Stef > > Le 29/5/15 21:24, Aliaksei Syrel a Ã©crit : > > Hi, > > We do some kind of a List for Bloc: > > [image: Inline image 1] > > Main features: > > - List doesn't care what kind of morphs to contain. > - Flexible height of elements. Any will do. > - Items can resize. > - Elements can be partially visible. > - Different kind of caches. > - Selection strategies. > > Short demo video: > â > Bloc-Brick-List.mov > <https://docs.google.com/file/d/0B-bMBVDOi3oTMnNKVHhCQUJ2UlU/edit?usp=drive_…> > â > If you want to play load: http://ws.stfx.eu/F4DRC0CVSDII > Examples included. > > Cheers, > Alex > > >

May 30, 2015

Re: [Pharo-dev] About "compileSilently"

by Nicolai Hess

2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 28/05/2015 20:40, Nicolai Hess a Ã©crit : > >> >> >> 2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> >> >> 2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> How silent should "compileSilently" be? >> >> no trace in the system : >> 15314 <https://pharo.fogbugz.com/default.asp?15314> >> compileSilently and method history / changes file >> >> not half silenlty >> 13023 <https://pharo.fogbugz.com/default.asp?13023> >> Test Cases should not do things half silently >> >> not "SystemAnnouncer-silent" >> 10560 <https://pharo.fogbugz.com/default.asp?10560> >> SystemAnnouncer and compileSilently >> >> >> ? >> >> What do you think, what granularity of "silent" do we need. >> I see at least three different use cases: >> >> - just an ordinary compile >> >> >> ? Silent means that: Core infrastructure is not updated properly >> (i.e. RPackage) and tools (Browsers) can end desynchronised with the >> methods. >> >> - compile for tests >> >> >> Probably the one... But I wonder if this is a good idea anyway. I'd >> believe most tests using silently are using it wrongly and shouldn't >> be using it in the first place. >> >> - compile autogenerated methods. >> >> >> This one may not be silent. If the auto-generated method will be >> visible (saved in a package, can be browsed, etc...) then it >> shouldn't be silent. >> >> >> >> What about compiled method for which the source did not change? >> > > Hum. I see what you mean. > > I do silent compilation when I install tracing probes inside methods, to > make sure they don't appear as changed in browsers... But I don't create > new methods. I guess this will be the same with the MetaLinks Marcus is > preparing. > > But, yes, as I said: methods or changes that are not visible then you can > make them silent. > > But in a different case, such as compiling a SmaCC parser, you want that > code to be visible. > For NativeBoost generated methods, I may want to have that code visible too. I just don't want the code to be marked as "changed" after a recompilation. For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure changed. The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it will be recompiled anyway. > > I am interested on this for issue 15315, everytime you open spotter, >> you'll get a new >> >> "method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 >> 20:34" >> >> in you changes file. >> > > This one makes for some annoying noise in the changes. But as I say below, > maybe it doesn't matter. > > Another case are autogenerated methods from NativeBoost. >> For example, open a fresh image and execute code that triggers >> NativeBoost to install native functions for this session. >> (EllipseMorph new openInSceneView) >> >> And now look at your list of recent changes. >> I get about 30 entries for athens/cairo methods. >> > > One of the thing to consider is what you use the changes for. If it is to > recover from crashes, then what you just need to make sure is that > replaying all since the last save is ok... even if you have multiple times > the same method source saved in it. > Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there). > > True changes management is happening in the packages these days, and most > code written in the changes shouldn't be recorded there imho (oh, well, > apart for the source pointer, of course). > > And other uses it could have (recording all do its, for example) is > reimplemented / duplicated elsewhere in the system anyway. > > Thierry >

May 30, 2015

[pharo-project/pharo-core]

by GitHub

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

May 30, 2015

[pharo-project/pharo-core] f8ff5e: 50076

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f8ff5e61c8a5e137104b0f30c77857acdb644863 https://github.com/pharo-project/pharo-core/commit/f8ff5e61c8a5e137104b0f30… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-30 (Sat, 30 May 2015) Changed paths: M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline32_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version314_.st M Glamour-Core.package/extension/UnixPlatform/instance/menuShortcutModifierString.st M Glamour-Core.package/extension/Win32Platform/instance/menuShortcutModifierString.st M Morphic-Base.package/MenuItemMorph.class/instance/events/activateOwnerMenu_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50076.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50076.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50076 15627 menuShortcutModifierString needs to answer ctrl for windows and linux https://pharo.fogbugz.com/f/cases/15627 15598 Morphic - Cant go back directly to the first menu when more than 2 submenus are opened. https://pharo.fogbugz.com/f/cases/15598 http://files.pharo.org/image/50/50076.zip

May 30, 2015

Re: [Pharo-dev] untypeable key combination

by Nicolai Hess

2015-05-30 9:49 GMT+02:00 stepharo <stepharo(a)free.fr>: > For now could not we use > > when: send: to: instead of a block in key registration? > I will check. Thank you for your response. > > Stef >

May 30, 2015

Re: [Pharo-dev] untypeable key combination

by Nicolai Hess

2015-05-30 2:20 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Mon, May 18, 2015 at 12:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-05-15 9:55 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> We now use a new class for the space-key as key combination. fixed and >>> included in 50045 (https://pharo.fogbugz.com/default.asp?15529) >>> This way we don't end up with hundreds of obsolete class instances. >>> >>> But the problem with circular references still exist. >>> 15535 <https://pharo.fogbugz.com/default.asp?15535> >>> break circular reference for keymappings >>> >>> I could need some help here, any idea how to work with the key mapping >>> registration without holding (or how to release) strong references? >>> >>> >>> thanks in advance >>> nicolai >>> >>> >> Can anyone help me with this. I need a way to break the circular >> references. >> >> a class is referenced by its compiled method >> the compiled method is referenced by the method context >> the method context is reference by a block context (the keymapping action) >> the block context is referenced by the registration item >> the registration item is referenced by the pragma registration builder >> the builder is reference by the method context (it is the method >> argument) and here the >> circle closes. >> > > Are there any dictionaries in the above? If there are then we can > probably use ephemerons to break the circularity. This will require Spur > and Pharo 5 or ^ (which ever is going to be based on Spur; I can't remember > which). This may seem like a ways off but it isn't. > Hi Eliot, yes, we use an OrderedCollection. I hoped one of our weak collections can solve this issue. But I don't know exaclty how. > > > >> 2015-02-20 9:26 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> >>>> > On 19 Feb 2015, at 10:19, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> > >>>> > Fogbugz issue 14936 >>>> > and slice in inbox >>>> > >>>> > After loading this slice, there are still many references to the >>>> (now) obsolete class KMUntypeableSingleKeyCombination. >>>> > I tried to remove these references with the following code : >>>> > >>>> > NECPreferences popupShowWithShortcut: nil. >>>> > KMSingleKeyCombination reset. >>>> > KMSpecialCharSingleKeyCombination reset. >>>> > KMRepository reset. >>>> > >>>> > >>>> > But they arent removed. >>>> > >>>> > Anyone knows how to re-init all users of >>>> KMUntypeableSingleKeyCombination ? >>>> > >>>> > >>>> >>>> Very strangeâ¦ using âexplore pointersâ with the old inspector, it shows >>>> lots of instancesâ¦ I sadly have no >>>> time to now look deeper, but the pointer explorer should be a way to >>>> find who holds onto themâ¦ >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>> >> > > > -- > best, > Eliot >

May 30, 2015

Re: [Pharo-dev] System Morphs in OSWindows

by Matthieu Lacaton

Oh by the way for some reasons, the quality of the video is really crappy if you watch it directly from Dropbox but if you download it, it is much better. I don't know why :/ 2015-05-30 10:16 GMT+02:00 Matthieu Lacaton <matthieu.lacaton(a)gmail.com>: > I think it would be better to name these for their function rather >> than the package: >> Nautilus openInExternalWindowOnPackage: nil. >> GTPlayground external openInExternalWindow. >> ThreadSafeTranscript external openInExternalWindow. >> >> I don't know if its a workable idea, but maybe something like >> Nautilus external openInOSWindowOnPackage: nil. >> GTPlayground external openInOSWindow. >> ThreadSafeTranscript external openInOSWindow. > > > It is a workable idea, we just need to agree on a syntax. > > > Also good would be if an existing Morph could be moved to an external >> window. From a menu choice would be entirely sufficient, but >> super-bonus points for being able to drag it. This might also >> facilitate a usage like this (but again not sure if thats a desirable >> paradigm)... >> > > > >> (Nautilus external openInOnPackage: nil) moveToExternalWindow. >> (GTPlayground external openInOSWindow) moveToExternalWindow. >> (ThreadSafeTranscript external openInOSWindow) moveToExternalWindow. >> > > This should be possible but I see two different ways of doing so : > > - First we could keep the same Morph and dynamically change some of its > features to match the requirements of an external window ( for example the > action done when clicking on the close / expand / reduce boxes are not the > same but there are other differences). Then we remove it from the World and > open it in an OSWindow. > - Or we could "save the state of the Morph" then delete it and directly > open a new one suited for external window. I've quoted "save the state of > the Morph" because if this option is chosen it will need to be refined. > > As for the "drag it outside part" I am sure it could be done. Currently > when you are dragging a Morph, as soon as the HandMorph goes out of the > World, when you release the mouse button the Morph goes back at its initial > place so we could just change this behavior to make it move to an external > window instead. But to be more flexible,maybe we could just keep both > behavior and chose between one and the other by pressing a hotkey while > dragging the Morph. > > BTW, I've recorded a short video to show you what it is possible to do > with the new SDL version (it should also illustrate what I told Nicolai > earlier) : > > https://www.dropbox.com/s/m27aa0flanocnlr/OSWindowMorph.mkv?dl=0 > > As you can see if you put the Morph inside the boundaries of the World, it > seems as if it was actually opened in the world (put aside some differences > like the fonts etc. but this is only due to the Athens rendering of Morphs > and it won't matter in Bloc). > For now it is heavily buggued (you can't opened two windows like that > without crashing the VM :/) but SDL 2.0.4 is still in developement so I > won't work more on it until it is released. > > > Where we have for example Meta-O-O to open a browser, it could be >> Meta-E-O to open in an external window. >> Also, a hotkey could be held down when opening from a menu - similar >> paradigm to web browsers between opening a new tab or opening a new >> window. >> > > Yeah that's a good idea. For the moment when opening from a menu the left > and right clicks have the same behavior so it could even be something like > left click => world and right click => external window. > > > As well a Preference so that this can be set globally. A multitude of >> open windows could be handled with a menu item in the task bar "Close >> all > external windows". >> >> btw, I presume Morphs in these windows would still appear in the task >> bar as usual. >> > > I am not sure about that because as OS - Windows they appear in the > taskbar of your OS and you can already manage them from here. > > > How will the existing World paradigm play into this? Will external >> windows be part of the same World? Or maybe the existing World can >> have another level below it called like World-Screen? >> > > The existing World paradigm will probably change with Bloc I guess. At > first I thought that all these windows could be part of the same Bloc-space > and that this Bloc-space would be dedicated to held external windows but I > really need to speak with Alain about that. > > Many thanks for your feedback and ideas ! > > Cheers, > > Matthieu > > 2015-05-30 8:16 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> - If possible I'd like not to have to modify any Bloc code. If it is not >> possible then as little as possible. >> >> What is the aversion here? Bloc is still developing and since its >>> semantics are based on old-Morphic maybe this use-case is not >>> considered. Adding this use-case may be an opportunity to make the >>> overall system architecture simpler instead of needing workarounds. >>> To what degree would Bloc already support this? >>> >> >> What matthieu wants to say is that opening a window in an external >> sufrace should >> not impose to have some hacks into bloc and alain agrees with that and >> will modify the >> bloc architecture to handle separate native windows. >> >>> - These windows should be persistent but maybe not exactly like morphs. >>>> It >>>> could be a button that the user needs to press in the window to toggle >>>> the >>>> persistence on and off (a bit like in the world menu to stick it to the >>>> world if you see what I mean). >>>> >>> >> I'm not sure that you want to have that behavior. Open windows should be >> persisted. >> >> As well a Preference so that this can be set globally. A multitude of >>> open windows could be handled with a menu item in the task bar "Close >>> all > external windows". >>> >>> btw, I presume Morphs in these windows would still appear in the task >>> bar as usual. >>> >>> >>> >> >> >

May 30, 2015

[pharo-project/pharo-core] f6306b: 50075

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f6306b7d4c4b6efe1384e2c455ee4ac70e4e0d28 https://github.com/pharo-project/pharo-core/commit/f6306b7d4c4b6efe1384e2c4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-30 (Sat, 30 May 2015) Changed paths: M FreeType.package/FT2Handle.class/class/class initialization/initialize.st A FreeType.package/FT2Handle.class/class/system startup/shutDown_.st M FreeType.package/FT2Handle.class/class/system startup/startUp_.st M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st M Nautilus.package/AbstractNautilusUI.class/definition.st A Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithCommentOnRight.st A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/newCommentTextModel.st A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/updateCommentWith_.st A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/whenTextUpdatedInCommentPane_.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeCmdKeyShortcuts.st M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeShiftCmdKeyShortcuts.st M Text-Edition.package/SmalltalkEditor.class/class/keyboard shortcut tables/initializeCmdKeyShortcuts.st M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicCmdKeyShortcuts.st M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicShiftCmdKeyShortcuts.st Log Message: ----------- 50075 15630 Remove duplicate shortcut definition (TextEditors actionMap vs KM) https://pharo.fogbugz.com/f/cases/15630 15637 Fixed nautilus tests https://pharo.fogbugz.com/f/cases/15637 15633 FT2Handle needs to cleanUp on exit, not on startup https://pharo.fogbugz.com/f/cases/15633 15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel https://pharo.fogbugz.com/f/cases/15631 http://files.pharo.org/image/50/50075.zip

May 30, 2015

[pharo-project/pharo-core]

by GitHub

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

May 30, 2015

Re: [Pharo-dev] System Morphs in OSWindows

by Matthieu Lacaton

> > I think it would be better to name these for their function rather > than the package: > Nautilus openInExternalWindowOnPackage: nil. > GTPlayground external openInExternalWindow. > ThreadSafeTranscript external openInExternalWindow. > > I don't know if its a workable idea, but maybe something like > Nautilus external openInOSWindowOnPackage: nil. > GTPlayground external openInOSWindow. > ThreadSafeTranscript external openInOSWindow. It is a workable idea, we just need to agree on a syntax. Also good would be if an existing Morph could be moved to an external > window. From a menu choice would be entirely sufficient, but > super-bonus points for being able to drag it. This might also > facilitate a usage like this (but again not sure if thats a desirable > paradigm)... > > (Nautilus external openInOnPackage: nil) moveToExternalWindow. > (GTPlayground external openInOSWindow) moveToExternalWindow. > (ThreadSafeTranscript external openInOSWindow) moveToExternalWindow. > This should be possible but I see two different ways of doing so : - First we could keep the same Morph and dynamically change some of its features to match the requirements of an external window ( for example the action done when clicking on the close / expand / reduce boxes are not the same but there are other differences). Then we remove it from the World and open it in an OSWindow. - Or we could "save the state of the Morph" then delete it and directly open a new one suited for external window. I've quoted "save the state of the Morph" because if this option is chosen it will need to be refined. As for the "drag it outside part" I am sure it could be done. Currently when you are dragging a Morph, as soon as the HandMorph goes out of the World, when you release the mouse button the Morph goes back at its initial place so we could just change this behavior to make it move to an external window instead. But to be more flexible,maybe we could just keep both behavior and chose between one and the other by pressing a hotkey while dragging the Morph. BTW, I've recorded a short video to show you what it is possible to do with the new SDL version (it should also illustrate what I told Nicolai earlier) : https://www.dropbox.com/s/m27aa0flanocnlr/OSWindowMorph.mkv?dl=0 As you can see if you put the Morph inside the boundaries of the World, it seems as if it was actually opened in the world (put aside some differences like the fonts etc. but this is only due to the Athens rendering of Morphs and it won't matter in Bloc). For now it is heavily buggued (you can't opened two windows like that without crashing the VM :/) but SDL 2.0.4 is still in developement so I won't work more on it until it is released. Where we have for example Meta-O-O to open a browser, it could be > Meta-E-O to open in an external window. > Also, a hotkey could be held down when opening from a menu - similar > paradigm to web browsers between opening a new tab or opening a new > window. > Yeah that's a good idea. For the moment when opening from a menu the left and right clicks have the same behavior so it could even be something like left click => world and right click => external window. As well a Preference so that this can be set globally. A multitude of > open windows could be handled with a menu item in the task bar "Close > all > external windows". > > btw, I presume Morphs in these windows would still appear in the task > bar as usual. > I am not sure about that because as OS - Windows they appear in the taskbar of your OS and you can already manage them from here. How will the existing World paradigm play into this? Will external > windows be part of the same World? Or maybe the existing World can > have another level below it called like World-Screen? > The existing World paradigm will probably change with Bloc I guess. At first I thought that all these windows could be part of the same Bloc-space and that this Bloc-space would be dedicated to held external windows but I really need to speak with Alain about that. Many thanks for your feedback and ideas ! Cheers, Matthieu 2015-05-30 8:16 GMT+02:00 stepharo <stepharo(a)free.fr>: > > - If possible I'd like not to have to modify any Bloc code. If it is not > possible then as little as possible. > > What is the aversion here? Bloc is still developing and since its >> semantics are based on old-Morphic maybe this use-case is not >> considered. Adding this use-case may be an opportunity to make the >> overall system architecture simpler instead of needing workarounds. >> To what degree would Bloc already support this? >> > > What matthieu wants to say is that opening a window in an external sufrace > should > not impose to have some hacks into bloc and alain agrees with that and > will modify the > bloc architecture to handle separate native windows. > >> - These windows should be persistent but maybe not exactly like morphs. It >>> could be a button that the user needs to press in the window to toggle >>> the >>> persistence on and off (a bit like in the world menu to stick it to the >>> world if you see what I mean). >>> >> > I'm not sure that you want to have that behavior. Open windows should be > persisted. > > As well a Preference so that this can be set globally. A multitude of >> open windows could be handled with a menu item in the task bar "Close >> all > external windows". >> >> btw, I presume Morphs in these windows would still appear in the task >> bar as usual. >> >> >> > >

May 30, 2015