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

Re: [Pharo-dev] books site description

by Stephane Ducasse

Good idea. Can you do a pull request? The web site is kept on Square Bracket on github. Stef On Sat, Apr 8, 2017 at 5:08 AM, Ben Coman <btc(a)openinworld.com> wrote: > Just a passing thought, at http://files.pharo.org/books/ > it might be nice for the top descriptive text to indicate a reading order. > > Something like... > > Newcomers should start with Pharo By Example, then proceed to: > - Spec UI Framework for desktop applications, > - Enterprise Pharo for web development, > - Agile Visualization for data processing. > Deep Into Pharo and Numerical Methods are broadly applicable to all > three domains. > > cheers -ben >

April 11, 2017

Re: [Pharo-dev] SmallInteger #printString versus #printOn:

by Stephane Ducasse

but I guess that the printOn: method should still be working because we can invoke it instead of creating a new stream. I mean as a developer I do not know that printString is not creating a stream so normally I should use printOn: especially from other printOn: method to avoid the creation of spurious streams. Now this printstring method is just good to printString and asString (if it invokes it). May be smallInteger>>printOn: call it too if it does not I have the impression that it should. On Sat, Apr 8, 2017 at 1:41 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-04-08 6:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> I was going to slip this example into the welcome help, >> >> 1 printString [debugIt] >> >> and I'm confronted by SmallInteger>>printString >> >> printString >> "Highly optimized version for base 10 >> and that we know it is a SmallInteger." >> | integer next result len | >> self = 0 ifTrue: [^'0']. >> self < 0 ifTrue: [^'-', self negated printString]. >> len := self decimalDigitLength. >> result := String new: len. >> integer := self. >> len to: 1 by: -1 do: [:i | >> next := integer // 10. >> result byteAt: i put: 48 + (integer - (next * 10)). >> integer := next]. >> ^result >> >> >> and I gather from other discussions this should(?) belong in >> SmallInteger>>printOn: >> Or is there a large benefit to avoiding the #printStringLimitedTo: >> machinery ? >> >> cheers -ben >> > > It should be printOn: generally, except that printOn: requires creating a > Stream, and requires passing thru Stream indirection for writing into the > target String. > > As the comment tells, the sole reason for this implementation is "Highly > optimized version". So consider that it's an exception to the rules. Maybe > this kind of decision could be periodically re-examined in the light of > performance measurements (I'm thinking of Sista)? >

April 11, 2017

Re: [Pharo-dev] discord channel request

by Stephane Ducasse

About the mooc and the social barrier I agree. We should make sure that shy people ask questions. On Sun, Apr 9, 2017 at 7:45 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Apr 9, 2017 at 8:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > #welcome is not necessary there is already a bot in place that provides a > > welcome message and displays a command for help for newcomers > > There have been some requests to remove the bot. > But I see that you've responded to feedback to tune its behaviour, > so I'm happy to wait to see how that panes out. > But oh! the irony... > > jecisc-Yesterday at 8:16 PM > Can you delete this level thing with the bot please?(edited) > > Mee6BOT-Yesterday at 8:16 PM > GG @jecisc, you just advanced to level 3 ! > > > btw, where is the bot hosted? > > > > #help is not necessary too, Discord has a search capability which could > be > > potentially used from inside a Pharo image but again the question is who > is > > going to do this > > Its not just about searchability. Its a social barrier thing. > If the regulars are rolling through some deep discussion, > a newcomer may hesitate to jump in with a side topic. > > If you want to condense channels, then probably the #mooc and #help > could be rolled into one. > > cheers -ben > > > > > #mooc , I am not against this idea but again we had a student yesterday > > asking for help that is following Mooc , I had no problem providing it > and > > he had not issues with the process of getting his question aswered in > > #general channel. If he asked at #mooc I would have missed it because I > am > > not going to keep a mind in all channels. > > > > For general questions I would prefer , even if they are mooc related , > to be > > at #general channel, lets not fragment our discussions for little > > justification, > > but for very mooc discusions, like where to find a specific > > teach or reports of errors in mooc it makes sense to have a mooc channel. > > > > My policy is to point an admin for each channel , channel admis are > > different than us general admins, we have full power they can only > > > > 1)manage message in a specific channel > > 2) manage webhooks (for example github commits or rss feeds) > > 3) create instant invites > > > > so if there is one person that is willing to become a mooc admin i will > > create the channel and add his as admin > > > > On Sun, Apr 9, 2017 at 5:33 AM Ben Coman <btc(a)openinworld.com> wrote: > >> > >> Could we have additional channels: > >> > >> #welcome - which would be the generally advertised invite URL. A > >> read-only channel that informs about community rules and summaries > available > >> channels etc (maybe including hidden channels and who to ask for invite) > >> > >> #help - To be referenced from in-Image Help Browser. Maybe later have > an > >> in-Image chat tool that connects to this channel. How cool would it be > to > >> have live help from within the IDE? > >> > >> #mooc - So people can maybe look back through history before asking > >> questions, and also people further along might help others less > advanced ==> > >> more participation > >> > >> cheers -ben > >

April 11, 2017

Re: [Pharo-dev] [Pharo6] Wanted: Human Readable ChangeLog

by Stephane Ducasse

better autocategorisation of method On Tue, Apr 11, 2017 at 5:41 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Ok. Here is my memory list: > > - MessageBrowser with filter > - Epicea for code changes > - haltOnce is active by default per method. It not requires global turning > on. > - haltOnce is managed from source code area in Nautilus > - execution counter for message nodes in source code area in Nautilus > - anObject asMethodConst to cache expressions dynamically. > - debugger temp names mapping is fixed > - improved debugger title for DNU > - ephemeron support > - more reliable interruption by cmd+. > - cmd+r in Nautilus supports any nodes: message rename, inst var rename, > class rename and etc. > - fast inspector based on FastTable > - fast debugger based on FastTable > - workspace variables are visible from debugger > - inheritable process specific variables > - new process specific variable CurrentExecutionEnvironment with values: > DefaultExecutionEnvironment by default and TestExecutionEnvironment during > test run > - SUnit improvements: time limit for tests, preventing "forked debuggers". > > 2017-04-11 15:58 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> Hi, >> >> We have the complete list of changes here: >> >> https://pharo.fogbugz.com/f/filters/?fClosedBugs=true&fGloba >> l=true&fOpenBugs=false&ixFixFor=22&ixPerson=46&ixPriority=6& >> priorityRange=-1&sColumns=Category-Favorite-Case- >> TitleComment-Status-Priority-LastUpdated&sSorts=Priority >> >> all 1386 closed issues with MileStone Pharo6. >> >> For the release announcement, it would be nice to have a shorter, more >> digestible list. >> >> I think we need 2 kind: >> >> 1) some 5-8 âmost importantâ ones >> 2) a list of maybe 20 issues that are interesting >> >> I think the easiest is to do it together.. so if you have points for the >> 2 kinds of changes, I would be interested. >> >> I will then create one merged version of everything people send me (or to >> the list). >> >> Marcus >> > >

April 11, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Stephane Ducasse

Yes in calypso and friends. On Tue, Apr 11, 2017 at 7:38 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Nice work, I like the approach. > > Did you inspire your work in how Dolphin and VAST implements menu > creation, command execution, and so on? > I find your solution similar to how Dolphin implements it, where even > each Presenter is even queried about each command by using a command > query and routing solution. > > Will you use this in the context of Calypso and friends? > > Regards! > > > Esteban A. Maringolo > > > 2017-04-11 11:49 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi. > > > > I am glad to announce Commander library which implements command pattern > > based on first class objects. > > In Commander every application action is implemented as separate class > with > > #execute method and all state required for execution. > > > > Commands are reusable objects and applications provide various ways to > > access them: shortcuts, context menu, buttons, etc.. This information is > > attached to command classes as activator objects. Currently there are > three > > types of activators: > > > > - CmdShortcutCommandActivator > > - CmdContextMenuCommandActivator > > - CmdDragAndDropCommandActivator > > > > Activators are declared in command class side methods marked with pragma > > #commandActivator. For example following method will allow > > RenamePackageCommand to be executed by shortcut in possible system > browser: > > > > RenamePackageCommand class>>packageBrowserShortcutActivator > > > > <commandActivator> > > ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext > > > > > > And for context menu it will be: > > > > > > RenamePackageCommand class>>packageBrowserMenuActivator > > <commandActivator> > > ^CmdContextMenuCommandActivator byRootGroupItemFor: > > PackageBrowserContext > > > > > > Activators are always declared with application context where they can be > > applied (PackageBrowserContext in example). Application should provide > such > > contexts with information about application state. Every widget can bring > > own context to interact with application as separate tool. For example > > system browser shows multiple panes which provide package context, class > > context and method context. And depending on context browser shows > different > > menu and provides different shortcuts. > > > > For more details look at my blog > > http://dionisiydk.blogspot.fr/2017/04/commander-command- > pattern-library.html > > and read docs here. > > > > Best regards, > > Denis > > > > > >

April 11, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Esteban A. Maringolo

Nice work, I like the approach. Did you inspire your work in how Dolphin and VAST implements menu creation, command execution, and so on? I find your solution similar to how Dolphin implements it, where even each Presenter is even queried about each command by using a command query and routing solution. Will you use this in the context of Calypso and friends? Regards! Esteban A. Maringolo 2017-04-11 11:49 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > I am glad to announce Commander library which implements command pattern > based on first class objects. > In Commander every application action is implemented as separate class with > #execute method and all state required for execution. > > Commands are reusable objects and applications provide various ways to > access them: shortcuts, context menu, buttons, etc.. This information is > attached to command classes as activator objects. Currently there are three > types of activators: > > - CmdShortcutCommandActivator > - CmdContextMenuCommandActivator > - CmdDragAndDropCommandActivator > > Activators are declared in command class side methods marked with pragma > #commandActivator. For example following method will allow > RenamePackageCommand to be executed by shortcut in possible system browser: > > RenamePackageCommand class>>packageBrowserShortcutActivator > > <commandActivator> > ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext > > > And for context menu it will be: > > > RenamePackageCommand class>>packageBrowserMenuActivator > <commandActivator> > ^CmdContextMenuCommandActivator byRootGroupItemFor: > PackageBrowserContext > > > Activators are always declared with application context where they can be > applied (PackageBrowserContext in example). Application should provide such > contexts with information about application state. Every widget can bring > own context to interact with application as separate tool. For example > system browser shows multiple panes which provide package context, class > context and method context. And depending on context browser shows different > menu and provides different shortcuts. > > For more details look at my blog > http://dionisiydk.blogspot.fr/2017/04/commander-command-pattern-library.html > and read docs here. > > Best regards, > Denis > >

April 11, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Alexandre Bergel

Just in case of: I do not want my email to be read as I did not intent to. You are doing a great work Denis. Keep going! Alexandre > On Apr 11, 2017, at 12:34 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Was is really necessary to introduce pragmas here? > > Alexandre > > >> On Apr 11, 2017, at 11:49 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi. >> >> I am glad to announce Commander library which implements command pattern based on first class objects. >> In Commander every application action is implemented as separate class with #execute method and all state required for execution. >> >> Commands are reusable objects and applications provide various ways to access them: shortcuts, context menu, buttons, etc.. This information is attached to command classes as activator objects. Currently there are three types of activators: >> >> - CmdShortcutCommandActivator >> - CmdContextMenuCommandActivator >> - CmdDragAndDropCommandActivator >> >> Activators are declared in command class side methods marked with pragma #commandActivator. For example following method will allow RenamePackageCommand to be executed by shortcut in possible system browser: >> >> RenamePackageCommand class>>packageBrowserShortcutActivator >> <commandActivator> >> ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext >> >> And for context menu it will be: >> >> RenamePackageCommand class>>packageBrowserMenuActivator >> <commandActivator> >> ^CmdContextMenuCommandActivator byRootGroupItemFor: PackageBrowserContext >> >> Activators are always declared with application context where they can be applied (PackageBrowserContext in example). Application should provide such contexts with information about application state. Every widget can bring own context to interact with application as separate tool. For example system browser shows multiple panes which provide package context, class context and method context. And depending on context browser shows different menu and provides different shortcuts. >> >> For more details look at my blog http://dionisiydk.blogspot.fr/2017/04/commander-command-pattern-library.html and read docs here. >> >> Best regards, >> Denis >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 11, 2017

Re: [Pharo-dev] [Pharo6] Wanted: Human Readable ChangeLog

by Denis Kudriashov

Ok. Here is my memory list: - MessageBrowser with filter - Epicea for code changes - haltOnce is active by default per method. It not requires global turning on. - haltOnce is managed from source code area in Nautilus - execution counter for message nodes in source code area in Nautilus - anObject asMethodConst to cache expressions dynamically. - debugger temp names mapping is fixed - improved debugger title for DNU - ephemeron support - more reliable interruption by cmd+. - cmd+r in Nautilus supports any nodes: message rename, inst var rename, class rename and etc. - fast inspector based on FastTable - fast debugger based on FastTable - workspace variables are visible from debugger - inheritable process specific variables - new process specific variable CurrentExecutionEnvironment with values: DefaultExecutionEnvironment by default and TestExecutionEnvironment during test run - SUnit improvements: time limit for tests, preventing "forked debuggers". 2017-04-11 15:58 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > We have the complete list of changes here: > > https://pharo.fogbugz.com/f/filters/?fClosedBugs=true& > fGlobal=true&fOpenBugs=false&ixFixFor=22&ixPerson=46& > ixPriority=6&priorityRange=-1&sColumns=Category-Favorite- > Case-TitleComment-Status-Priority-LastUpdated&sSorts=Priority > > all 1386 closed issues with MileStone Pharo6. > > For the release announcement, it would be nice to have a shorter, more > digestible list. > > I think we need 2 kind: > > 1) some 5-8 âmost importantâ ones > 2) a list of maybe 20 issues that are interesting > > I think the easiest is to do it together.. so if you have points for the 2 > kinds of changes, I would be interested. > > I will then create one merged version of everything people send me (or to > the list). > > Marcus >

April 11, 2017

Re: [Pharo-dev] [Ann] Commander. Command pattern library

by Alexandre Bergel

Was is really necessary to introduce pragmas here? Alexandre > On Apr 11, 2017, at 11:49 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > I am glad to announce Commander library which implements command pattern based on first class objects. > In Commander every application action is implemented as separate class with #execute method and all state required for execution. > > Commands are reusable objects and applications provide various ways to access them: shortcuts, context menu, buttons, etc.. This information is attached to command classes as activator objects. Currently there are three types of activators: > > - CmdShortcutCommandActivator > - CmdContextMenuCommandActivator > - CmdDragAndDropCommandActivator > > Activators are declared in command class side methods marked with pragma #commandActivator. For example following method will allow RenamePackageCommand to be executed by shortcut in possible system browser: > > RenamePackageCommand class>>packageBrowserShortcutActivator > <commandActivator> > ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext > > And for context menu it will be: > > RenamePackageCommand class>>packageBrowserMenuActivator > <commandActivator> > ^CmdContextMenuCommandActivator byRootGroupItemFor: PackageBrowserContext > > Activators are always declared with application context where they can be applied (PackageBrowserContext in example). Application should provide such contexts with information about application state. Every widget can bring own context to interact with application as separate tool. For example system browser shows multiple panes which provide package context, class context and method context. And depending on context browser shows different menu and provides different shortcuts. > > For more details look at my blog http://dionisiydk.blogspot.fr/2017/04/commander-command-pattern-library.html and read docs here. > > Best regards, > Denis > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 11, 2017

[Ann] Commander. Command pattern library

by Denis Kudriashov

Hi. I am glad to announce Commander library which implements command pattern based on first class objects. In Commander every application action is implemented as separate class with #execute method and all state required for execution. Commands are reusable objects and applications provide various ways to access them: shortcuts, context menu, buttons, etc.. This information is attached to command classes as activator objects. Currently there are three types of activators: - CmdShortcutCommandActivator - CmdContextMenuCommandActivator - CmdDragAndDropCommandActivator Activators are declared in command class side methods marked with pragma #commandActivator. For example following method will allow RenamePackageCommand to be executed by shortcut in possible system browser: RenamePackageCommand class>>packageBrowserShortcutActivator <commandActivator> ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext And for context menu it will be: RenamePackageCommand class>>packageBrowserMenuActivator <commandActivator> ^CmdContextMenuCommandActivator byRootGroupItemFor: PackageBrowserContext Activators are always declared with application context where they can be applied (PackageBrowserContext in example). Application should provide such contexts with information about application state. Every widget can bring own context to interact with application as separate tool. For example system browser shows multiple panes which provide package context, class context and method context. And depending on context browser shows different menu and provides different shortcuts. For more details look at my blog http://dionisiydk.blogspot.fr/2017/04/commander-command-pattern-library.html and read docs here <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> . Best regards, Denis

April 11, 2017