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

can someone explain me this?

by Esteban Lorenzano

Smalltalk allClassesAndTraits size. "5057" Object withAllSubclasses size. â9900" I really do not understand :) Esteban

May 21, 2015

Re: [Pharo-dev] Morphic menus

by Nicolai Hess

2015-05-21 16:50 GMT+02:00 Matthieu Lacaton <matthieu.lacaton(a)gmail.com>: > Hello everyone, > > I had to understand how menus work in Morphic lately and I noticed some > things : > > 1) When a menu has strictly more than 1 submenu active it cannot regain > the focus if the mouse doesn't pass over the submenus first. It is a bit > hard for me to explain so I will give you an example : > Open a Nautilus browser on any package and right click on a class. Now > browse "Refactoring => Code Rewriting => Rewrite Code but don't click on > any of these items. You will have 3 menus. Now if you exit the last menu > without returning to the previous one (make a loop from the right for > example if you have enough place) and go back directly to the first one > you'll see that it doesn't respond (it is like frozen). > > I don't know if it is a bug or if it is intended but I find it strange as > it is not how it is working on Windows nor Ubuntu for example. > > So if it is indeed a bug, what I propose as a "fix" would be this: > > Replace > > *:* >> >> *MenuItemMorph >>* *activateOwner Menu: evt* >> "Activate our owner menu; e.g., pass control to it" >> owner ifNil:[^false]. "not applicable" >> (owner fullContainsPoint: evt position) ifFalse:[^false]. >> owner activate: evt. >> ^true >> > > by: > > *MenuItemMorph >>* *activateOwner Menu: evt* >> > > >> >> * | popUpOwner |* >> >> * owner ifNil: [^false].* >> >> * (owner fullContainsPoint: evt position) ifTrue: [* >> >> * owner activate: evt.* >> >> >> >> * ^true. ].* >> >> * popUpOwner := owner popUpOwner.* >> >> * [ popUpOwner ] whileNotNil: [* >> >> * (popUpOwner owner fullContainsPoint: evt position) ifTrue: [* >> >> * popUpOwner owner activate: evt.* >> >> >> * ^true. ]* >> >> * ifFalse: [* >> >> >> >> * popUpOwner := popUpOwner owner popUpOwner. ]. ].* >> >> * ^false.* >> > > It should work with any number of submenus but i couldn't find anywhere in > Pharo with more than 3 menus so i couldn't test it further. > Works good. > > 2) When you leave a submenu and quickly come back to its popUpOwner, the > item in the submenu won't be deselected. So if you navigate a bit in the > menu and then want to come back to this submenu, you won't be able to > select the item by passing your mouse over it. It is not a big deal in > 99.9% of the time as you will still be able to click on it but when this > item is supposed to open a submenu it won't. You need to go to another item > in the submenu and to come back. > > I noticed that it happened because if you are leaving the submenu too > quickly there is no "mouseLeave" event generated so the itemMenu is not > deselected. Thus, as it is considered as selected, if you come back to it > later a "mouseEnter" event will not trigger anything. > > It is quite easy to reproduce with the same menu than for the 1) : > Right click on a class in a Nautilus browser then browse Refactoring => > Code Rewriting. > Now if you quickly come back to Refactoring sometimes you'll see that Code > Rewriting won't be deselected (it will still be blue after the 500ms time > out). If it is the case you can go back on "Rename..." and then if you > quickly come back to Refactoring => Code Rewriting, you won't be able to > get the 3rd submenu. > > I can reproduce this very easily but it is not really a problem because it > only happens if you are fast with your mouse. > > I did not try to fix it but I guess that reinitializing all the itemMenus > to unselected when poping a menu could do the trick. > > 3) This one is mostly insignificant because it is quite hard to reproduce > and doesn't trigger often at all. But sometimes when you quickly navigate > between 3 menus (I have not been able to reproduce it with only 2 menus) > when you want to go back to the first one it freezes and it doesn't handle > the mouseOver events anymore (you can still click though). > This is not the same thing than the first point because here you correctly > pass through the previous submenus to go to the first one. > I don't really know why this happens sometimes but I think it may be > because the focus was not passed quickly enough between windows and one on > the submenus gets deactivated and removed from the world wheras it still > had the focus on him. > > Anyway these 3 things are not really important but I just wanted to share > what i found with you in case you think it is valid. > I find both difficult to reproduce, I can, but only on every ~ 10th attempt. And you can always click on the menu or open a new one. > > Cheers, > > Matthieu > > >

May 21, 2015

Re: [Pharo-dev] "missing" exports on the windows vm

by Nicolai Hess

2015-05-06 0:11 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > We have a failing test case for NB > NBInterpreterProxyTest>>#testStackPointer > it fails because > NativeBoost loadSymbol: 'stackPointerAddress' fromModule: NativeBoost > VMModule > returns nil > > This works for the linux vm! > > There are other methods that can be loaded, for example: > (NativeBoost loadSymbol: 'primitiveAllObjects' fromModule: NativeBoost > VMModule) > -> returns an address. > > This stopped working for the windows pharo vm around june 2014. The source > that > changed is cointerp.h, the prior version had EXPORT(...) declarations > around all > functions in cointerp.h, the current version not. > > Three questions: > > 1. Why does this still work on linux? Does it export all functions > declared in > a header? > 2. why was it changed? (I could not found the change in the code > generator, maybe we > exported all functions with pragma #api and now only those with pragma > #export ? > 3. do we need this function to be exported? Apart from this testcases, > this method is > called the on image startup, but the nil return does not harm. > It seems it is not part of the main vm api (like the interpreter proxy > functions callable from external modules) and I didn't see code thet depend > on this. > > There are similiar functions for which we load the function address on > startup: > cStackPointerAddress and cFramePointerAddress, this seems to work, but I > don't know if the expected result is different. > > In NBInterpreterProxy>>#initialize, we try to load all fourmethods: > stackPointerAddress/framePointerAddress -> nil > cStackPointerAddress / cFramePointerAddress -> not nil > > > > nicolai > > Anyone knows why the exports changed on windows? Or if we need the stackPointerAddress/framePointerAddress methods? nicolai

May 21, 2015

Re: [Pharo-dev] [Pharo-users] Next Pharo sprint & Moose dojo

by Jean-Christophe Bach

* Tudor Girba <tudor(a)tudorgirba.com> [21.05.2015. @13:04:19 +0200]: > Great! > > It would be great if you could test Moose 5.1 (stable) and let us know if > you encounter problems or if you commit new changes so that we can finally > release it. Do you think this would fit in your sprint/dojo? > > Cheers, > Doru OK, I note it. I think it is possible: it will depend on the available people but I think it can be the focus for Moose sprinters. JC

May 21, 2015

Re: [Pharo-dev] [Review]: Issue 15567 - TxText Cleanup for Pharo 5.0 #4

by Nicolai Hess

Am 21.05.2015 5:29 nachm. schrieb "Sean P. DeNigris" <sean(a)clipperadams.com >: > > Nicolai Hess wrote > > There is still one change in a class that does not belong to this package: > > OCAbstractMethodScope > > But that method is in the "*TxText-Styler" protocol! > > Ah, sorry, didnt saw that. > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Review-Issue-15567-TxText-Cleanup-for-Pharo-5-0-4-tp4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

May 21, 2015

[pharo-project/pharo-core] 7bc238: 50057

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7bc23816ad1b6dd5a13c64eb09b018b3865b4142 https://github.com/pharo-project/pharo-core/commit/7bc23816ad1b6dd5a13c64eb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-21 (Thu, 21 May 2015) Changed paths: A Reflectivity-Tests.package/HookGeneratorTest.class/README.md A Reflectivity-Tests.package/HookGeneratorTest.class/definition.st A Reflectivity-Tests.package/HookGeneratorTest.class/instance/tests - hooks/testHaltHook.st A Reflectivity-Tests.package/HookGeneratorTest.class/instance/tests - hooks/testHookWithArguments.st A Reflectivity-Tests.package/HookGeneratorTest.class/instance/tests - hooks/testHookWithVirtualMeta.st R Reflectivity-Tests.package/MetaLinkTest.class/instance/tests - hooks/testHaltHook.st A Reflectivity.package/HookGenerator.class/instance/accessing/plugins.st A Reflectivity.package/HookGenerator.class/instance/accessing/table.st A Reflectivity.package/HookGenerator.class/instance/ast manipulation/reificationsFor_.st M Reflectivity.package/HookGenerator.class/instance/initialize/setupTable.st M Reflectivity.package/HookGenerator.class/instance/result/hook.st A Reflectivity.package/RFCondition.class/instance/accessing/reifications.st A Reflectivity.package/RFReification.class/instance/acccessing/optimize.st A Reflectivity.package/RFReification.class/instance/generate/genForRBMethodNode.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50056.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50057.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50056.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50057.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50057 15581 add support for reifying information + pass it to the meta object https://pharo.fogbugz.com/f/cases/15581 http://files.pharo.org/image/50/50057.zip

May 21, 2015

[pharo-project/pharo-core]

by GitHub

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

May 21, 2015

Re: [Pharo-dev] Null Coalesce Operator?

by Richard Sargent

abergel wrote > Hi! > > I perfectly understand the purpose of this method "??â > Although I do not think this will seriously impact the quality of the code > being produced, ... Actually, I would argue it that it would degrade the quality of code. There is less clarity conveyed by infix operators than by keyword messages, unless the infix operator is already well known (such as common arithmetic operators) or somewhat easily guessed (such as #~=). #?? only has meaning if you already know it from other languages. > ... I still believe it will not help making code of a better quality. > Check for the nil value should be banned in my opinion. There are > well-known techniques to not have to use it (e.g., Null-object pattern). > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On May 20, 2015, at 3:19 PM, Aliaksei Syrel < > alex.syrel@ > > wrote: >> >> Hi, >> >> Null coalesce operator - returns the first not nil operand. >> http://en.wikipedia.org/wiki/Null_coalescing_operator >> <http://en.wikipedia.org/wiki/Null_coalescing_operator> >> >> Adding one simple method to an Object: >> >> ?? anObject >> ^ self >> >> and to UndefinedObject: >> >> ?? anObject >> ^ anObject >> >> could allow us to write: >> >> default1 := nil. >> default2 := nil. >> default3 := 'foo'. >> default4 := 'don''t care'. >> config := default1 ?? default2 ?? default3 ?? default4. >> >> => 'foo' >> >> I know you don't like to add new methods to an object, but still :) >> -- View this message in context: http://forum.world.st/Null-Coalesce-Operator-tp4827707p4827911.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 21, 2015

Re: [Pharo-dev] [Moose-dev] Re: Fwd: Magritte = Auto-GT Presentation

by Sean P. DeNigris

Tudor Girba-2 wrote > Hi Sean, > > Sorry for the slow response. > ... > gtInspectorMagritteIn: composite > > <gtInspectorPresentationOrder: 40> > composite magritte > title: 'Form'; > display: [ self ] Bravo! Well done! This is *so* useful. Thank you and keep it up :) You just saved me time, and more importantly a context switch in a project with a very tight deadline. There is definitely a beer (or several) in your future ;) BTW: To get this in Pharo 5.0, load the Glamour-Magritte-Presentations package from the Moose repo ----- Cheers, Sean -- View this message in context: http://forum.world.st/Re-Moose-dev-Re-Fwd-Magritte-Auto-GT-Presentation-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 21, 2015

Re: [Pharo-dev] [Review]: Issue 15567 - TxText Cleanup for Pharo 5.0 #4

by Sean P. DeNigris

Nicolai Hess wrote > There is still one change in a class that does not belong to this package: > OCAbstractMethodScope But that method is in the "*TxText-Styler" protocol! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Issue-15567-TxText-Cleanup-for-Pharo-5-0-4-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 21, 2015