March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Settings + Menu

by Alain Plantec

Lukas Renggli a Ã©crit : > Looks cool and I would be glad to see this in Pharo. > thanks > >> previous: #wmSystemSettings; >> line: true; >> > > Instead of introducing these hard dependencies (and possiblity > conflicts) to define the order and groups, why not use simple > order/priority number that the items are then sorted along? When using > floats you could even group them along the same integer value. I think > VW does something like that ... > > 1.1 Tools > 1.2 Windows > 1.3 Debug > yes, I suspected there was a problem with the ordering. I make a try. thanks for your review. Cheers alain > Lukas > >

March 26, 2009

Re: [Pharo-project] Settings + Menu

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > thanks alain > > I was a bit on vacation because we have some troubles with our house. Hi Stephane, I think the setting should be ok for integration. Can I upload it to Inbox ? I would like to start changing preference declarations. About menus, it seems ok. The main problem is the ordering of menu items. My solution is, for a menu item, to declare its previous item (see worldmenu example in SettingSandBox1) maybe people here have other solutions ? If the menu feature is not desired, it is quite easy to remove it. anyway, I've improved it a little bit. I've attached the new packages. test setting and menu features with: SystemSettingTree new open "browse/change setting values" SystemMenuTree new open "browse/test world menu items (see item menu)" WorldMenuAssembler new doPopUpMenu "popup the world menu test (TheWorldMenu replacement)" Cheers alain > > Stef > On Mar 26, 2009, at 12:28 AM, Alain Plantec wrote: > >> Hi all, >> >> Here my last setting package version >> with a test package (Tests-System-Settings) :) >> >> I've also added a Menu part which allows the using of >> pragma for menu discovering and assembling on the fly. >> This addon fully reuse what is done for settings. >> The idea is the same: use pragma within particular methods >> which are defining menu items (thanks to Lukas again for the idea ;-) ) >> The menu assembler is able to collect them and to popup the menu >> dynamically. >> >> The consequences are >> - no need for TheWorldMenu class and >> - this would be the end of #registerOpenCommand: and >> #unregisterOpenCommand:. >> >> As for settings, the main benefit is that menu items are brought by >> packages. >> An application specific menu can be added anywhere in the world menu. >> One could also use this feature in order to allow user-defined menu >> entries. >> >> As an example, I've re-defined a part of the world menu. >> it is implemented in MenuSettings class (package SettingSandBox1). >> Such a menu is dynamically assembled and is popup very quickly. >> So I think that there would be no more need for a world menu instance >> kept alive in the system. >> >> you can try it with: >> >> WorldMenuAssembler new doPopUpMenu >> >> You can also use >> >> SystemMenuTree new open >> >> in order to browse all menu entries. >> It is only a very simple version. >> Maybe it could be used in order to implement a 'menu editor' tool: >> define your menus and generate corresponding code. >> >> >> Here are two examples of methods with menu pragma from MenuSettings >> class. >> >> - the Save item : a simple item with one target and one selector >> wmSave >> <worldMenu> >> ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; >> selector: #saveSession; >> previous: #wmSystemSettings; >> description: 'save the current version of the image on disk' >> >> - the ToolsSet item set : a multi node with a collection of menu items >> wmToolSet >> <worldMenu> >> ^ (SettingManager newMenuSiblings name: 'Toolset') >> line: true; >> menus: (ToolSet default mainMenuItems >> collect: [:item | (SettingManager newMenu: item first) >> target: ToolSet default; >> selector: item second]) >> >> Cheers >> >> alain >> >> >> >> >> >> >> >> >> >> <SettingSandBox1-alain_plantec.4.mcz><SettingSandBox2-alain_plantec.2.mcz><System-Settings-alain_plantec.22.mcz><Tests-System-Settings-alain_plantec.4.mcz><Menu.gif>_______________________________________________ >> >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

March 26, 2009

Re: [Pharo-project] Which Squeak problem do you try to solve

by Lukas Renggli

> After reading your interesting project website, I'm still not quite sure > which (Squeak) problem do you try to solve with Pharo? Or is it more an > exploratory project? Did you see <http://www.pharo-project.org>? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 26, 2009

Re: [Pharo-project] Settings + Menu

by Lukas Renggli

Looks cool and I would be glad to see this in Pharo. > Â Â Â Â previous: #wmSystemSettings; > line: true; Instead of introducing these hard dependencies (and possiblity conflicts) to define the order and groups, why not use simple order/priority number that the items are then sorted along? When using floats you could even group them along the same integer value. I think VW does something like that ... 1.1 Tools 1.2 Windows 1.3 Debug 1.4 System 2.1 Save 2.2 Save as.. 2.3 Save as new version 2.4 Quit Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 26, 2009

Re: [Pharo-project] Unicode merge

by StÃ©phane Ducasse

Now I get MacOsClipboard>>primitiveFailed ioReadClipboardData > StÃ©phane Ducasse wrote: >> Loaded without problems > > great :-) > >> shortcut error. debug? > > Please try again with these updated SLICEs > > SLICE-UnicodeRwrite1-michael_rueger.1 (unchanged) > SLICE-UnicodeRewrite2-5.mcm (updated) > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2009

[Pharo-project] Which Squeak problem do you try to solve

by Markus BÃ¶hm

After reading your interesting project website, I'm still not quite sure which (Squeak) problem do you try to solve with Pharo? Or is it more an exploratory project? Thanks in advance for any reply Markus Boehm

March 26, 2009

Re: [Pharo-project] Settings + Menu

by StÃ©phane Ducasse

thanks alain I was a bit on vacation because we have some troubles with our house. Stef On Mar 26, 2009, at 12:28 AM, Alain Plantec wrote: > Hi all, > > Here my last setting package version > with a test package (Tests-System-Settings) :) > > I've also added a Menu part which allows the using of > pragma for menu discovering and assembling on the fly. > This addon fully reuse what is done for settings. > The idea is the same: use pragma within particular methods > which are defining menu items (thanks to Lukas again for the > idea ;-) ) > The menu assembler is able to collect them and to popup the menu > dynamically. > > The consequences are > - no need for TheWorldMenu class and > - this would be the end of #registerOpenCommand: and > #unregisterOpenCommand:. > > As for settings, the main benefit is that menu items are brought by > packages. > An application specific menu can be added anywhere in the world menu. > One could also use this feature in order to allow user-defined menu > entries. > > As an example, I've re-defined a part of the world menu. > it is implemented in MenuSettings class (package SettingSandBox1). > Such a menu is dynamically assembled and is popup very quickly. > So I think that there would be no more need for a world menu instance > kept alive in the system. > > you can try it with: > > WorldMenuAssembler new doPopUpMenu > > You can also use > > SystemMenuTree new open > > in order to browse all menu entries. > It is only a very simple version. > Maybe it could be used in order to implement a 'menu editor' tool: > define your menus and generate corresponding code. > > > Here are two examples of methods with menu pragma from MenuSettings > class. > > - the Save item : a simple item with one target and one selector > wmSave > <worldMenu> > ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; > selector: #saveSession; > previous: #wmSystemSettings; > description: 'save the current version of the image on disk' > > - the ToolsSet item set : a multi node with a collection of menu items > wmToolSet > <worldMenu> > ^ (SettingManager newMenuSiblings name: 'Toolset') > line: true; > menus: (ToolSet default mainMenuItems > collect: [:item | (SettingManager newMenu: item first) > target: ToolSet default; > selector: item second]) > > Cheers > > alain > > > > > > > > > > <SettingSandBox1-alain_plantec.4.mcz><SettingSandBox2-alain_plantec. > 2.mcz><System-Settings-alain_plantec.22.mcz><Tests-System-Settings- > alain_plantec. > 4.mcz><Menu.gif>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

by Igor Stasenko

2009/3/26 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > To call threaded code incomprehensible is to ignore many appropriate uses of them. Â The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up. Â Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence. > > At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me). Â I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job. Â Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section. Â Dirty writes are a bear in any language, but my general approach is "don't make that mistake." Â It works for me. > Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A. This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :) > Bill > > --- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik > Sent: Wednesday, March 25, 2009 4:39 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? > > On 3/26/09, Markus Fritsche <fritsche.markus(a)gmx.net> wrote: >> Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> | array sum1 sum2 | >>> sum1 := 0. sum2 := 0. >>> array := Array new: 10. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: >>> 10) ] ] fork. >>> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. >> >> Something I came across leately: Threads are evil - >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > They're not evil, just mischievous. > > I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming. > > "This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash." > > heh. True. > > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 26, 2009

[Pharo-project] Settings + Menu

by Alain Plantec

Hi all, Here my last setting package version with a test package (Tests-System-Settings) :) I've also added a Menu part which allows the using of pragma for menu discovering and assembling on the fly. This addon fully reuse what is done for settings. The idea is the same: use pragma within particular methods which are defining menu items (thanks to Lukas again for the idea ;-) ) The menu assembler is able to collect them and to popup the menu dynamically. The consequences are - no need for TheWorldMenu class and - this would be the end of #registerOpenCommand: and #unregisterOpenCommand:. As for settings, the main benefit is that menu items are brought by packages. An application specific menu can be added anywhere in the world menu. One could also use this feature in order to allow user-defined menu entries. As an example, I've re-defined a part of the world menu. it is implemented in MenuSettings class (package SettingSandBox1). Such a menu is dynamically assembled and is popup very quickly. So I think that there would be no more need for a world menu instance kept alive in the system. you can try it with: WorldMenuAssembler new doPopUpMenu You can also use SystemMenuTree new open in order to browse all menu entries. It is only a very simple version. Maybe it could be used in order to implement a 'menu editor' tool: define your menus and generate corresponding code. Here are two examples of methods with menu pragma from MenuSettings class. - the Save item : a simple item with one target and one selector wmSave <worldMenu> ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; selector: #saveSession; previous: #wmSystemSettings; description: 'save the current version of the image on disk' - the ToolsSet item set : a multi node with a collection of menu items wmToolSet <worldMenu> ^ (SettingManager newMenuSiblings name: 'Toolset') line: true; menus: (ToolSet default mainMenuItems collect: [:item | (SettingManager newMenu: item first) target: ToolSet default; selector: item second]) Cheers alain

March 25, 2009

Re: [Pharo-project] Issue 657

by HernÃ¡n Morales Durand

Rob, the attachement is an image of what I see in my display (1024x768, old poor dying monitor), so if you use other resolution and the dialog shows different, the answer to your question it seems to be no. Hardcoding display resolutions in a ifTrue: stairway is obviously not a good solution, in the other hand, to write display policies (IIRC VW has something like this) it seems to be way too much just for an about dialog. There is another place in which this problem arises? Any tips? HernÃ¡n 2009/3/25 Rob Rothwell <r.j.rothwell(a)gmail.com> > Trial and error has this working for me: > > aboutThisSystem > "Identify software version" > > ^ self > inform: self systemInformationString withCRs > extent: 680 @ 575. > > Does Squeak handle different resolution displays "uniformly?" Is it like > working with twips or anything? Or, are these just pixels? > > Thanks! > > Rob > > > > On Wed, Mar 25, 2009 at 6:35 PM, Rob Rothwell <r.j.rothwell(a)gmail.com>wrote: > >> Worked great but the Ok button is gone now! >> >> Rob >> >> 2009/3/25 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> >>> http://code.google.com/p/pharo/issues/detail?id=657 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 25, 2009