- Pharo-dev - lists.pharo.org

[ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

Hi guys, Iâm sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 >From flowâs readme at github: Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

Oct. 5, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Jan Vrany

On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: > Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. > However, I think itâs better to do feature detection instead of dialect detection. So, something like: > > ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ > stream := CharacterWriteStream on: (String new: 10) > ] ifFalse:[ > stream := WriteStream on: (String new: 10) > ] > Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The "feature testing" code would look like ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ]. (true, in this very case you may be able to get around using different method, but you get the point, no?) Some time ago Hilaire posted a very nice, 15 lines long code that does reliable "feature detection" whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly). Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it. While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests. > And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. > That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet. Jan > cheers > Johan > > On 05 Oct 2014, at 09:00, stepharo <stepharo(a)free.fr> wrote: > > > Hi jan > > > > Thanks for the proposal. > > I thought about it and I'm against because it goes again the idea of dispatch. > > I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. > > Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. > > Let us see what other people think. > > > > Stef > > > > On 4/10/14 22:14, Jan Vrany wrote: > >> Hi guys, > >> > >> I've just opened: > >> > >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… > >> > >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to > >> SmalltalkImage to ease multi-dialect development. > >> > >> RATIONALE: > >> > >> Commonly used approach to solve differences among dialect is to use a > >> sort of platform object and dispatch there for troublesome operations > >> that has to be specialized. This platform object is usually in platform > >> specific package. > >> Other option is to load some library like Grease or Sport. > >> > >> The problem of the first approach is that brings to much (unnecessary) > >> burden when used for two, three things. The amount of of the code and > >> management is way to bigger then the amount of the code that has to be > >> specialized. Loading Grease/Sport on the other hand introduces a > >> dependency on an external package - not worth of for two or three > >> things. > >> > >> The proposed dialect testing messages would allow for simple, > >> #ifdef-like idiom like: > >> > >> | stream | > >> ... > >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk > >> isSomeCoolDialect]) ifTrue:[ > >> stream := CharacterWriteStream on: (String new: 10) > >> ] ifFalse:[ > >> stream := WriteStream on: (String new: 10) > >> ] > >> > >> The #respondsTo: check, while not nice, is required as at the moment not > >> all dialects could be trusted to have these testing messages. > >> > >> Putting these methods may not stick with Pharo standard (whatever it > >> is), but Smalltalk global is probably one of the > >> very few that are present in pretty much every Smalltalk implementation. > >> Other option would be to place them to the class side of an Object > >> (which is amost certainly present everywhere), however > >> > >> Smalltalk isPharo > >> > >> reads better than > >> > >> Object isPharo. > >> > >> Best, Jan > >> > >> > >> > > > > > > >

Oct. 5, 2014

Re: [Pharo-dev] structuring widget examples

by Tudor Girba

Hi Stef, I was not clear. The E.g. presentation for a class lists all examples. So, it is expected that we get more examples for a class. Take a look at the attached screenshot showing the examples of FileReference. Let's call it <example> and then we use it consistently throughout the system. Is that Ok? Cheers, Doru [image: Inline image 1] On Sun, Oct 5, 2014 at 5:58 PM, stepharo <stepharo(a)free.fr> wrote: > > On 5/10/14 15:10, Tudor Girba wrote: > > Hi Stef, > > Great. GT is already prepared for this :). If you define a <gtExample> > on the class side, you will get an "E.g." tab with those examples. > > It's called gtExample because we did not want to interfere with other > pragmas, but perhaps we can change it to <eg>, or <example>. What do you > think? > > > for a given class I would like to have potentially multiple examples. I > already have that in certain classes. > Then since these examples are for core classes I do not really like the > idea to get gt* > > Now first we should have many more and renaming a pragma is just the easy > part of the game. > Because I'm turning WidgetExamples into class methods examples and trying > to understand the API of UITheme > and reducing the mess. > > I want > > - UITheme to call widgets class methods > - but I have to understand the theme impact on the API. > > a kind of gigantic task. but we will see. > Stef > > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 2:25 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I started to systematically defined widget example using the pragram >> <exampleWidget> >> >> >> rowPrototype >> "Answer a prototypical row" >> "self rowPrototype openInHand" >> <exampleWidget> >> >> | sampleMorphs aRow | >> sampleMorphs := (1 to: (2 + 3 atRandom)) collect: >> [:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @ (80 >> + ((20 atRandom)))); color: Color random; setNameTo: ('egg', integer >> asString); yourself]. >> aRow := self inARow: sampleMorphs. >> aRow setNameTo: 'Row'. >> aRow enableDragNDrop. >> aRow cellInset: 6. >> aRow layoutInset: 8. >> aRow setBalloonText: 'Things dropped into here will automatically be >> organized into a row. Once you have added your own items here, you will >> want to remove the sample colored eggs that this started with, and you will >> want to change this balloon help message to one of your own!'. >> aRow color: Color veryVeryLightGray. >> ^ aRow >> >> This means that GTool will get instances for free to play with and the >> finder get really handy to browse widgets. >> >> If you want to join the effort you are welcome. >> >> Stef >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] gt issues

by kmo

By video controls I meant /first, previous, next, last /buttons - but that's not a good idea now I think about it. I still think "page" numbers might be better than dots. But, as you say, I managed to use the dots so they can't be that bad, Still, I think the dots would look more obviously like navigation controls if they were embedded in a small sunken or raised panel. But perhaps as you suggest with more contrast in colour even that might not be necessary. I'm a bit more concerned about how easy it is to end up with lots of panes that are identical. For example, in the screenshots of smallInteger(42) in this thread. Every pane reads the same. Isn't that confusing? No doubt I'll get used to it, though. I don't like the idea of flashing the controls by the way - that seems very artificial to me. -- View this message in context: http://forum.world.st/gt-issues-tp4782476p4782808.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Ben Coman

Tudor Girba wrote: > Hi, > > On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > Tudor Girba wrote: > > Hi Esteban, > > I know it's a usability principle, but usability should also > take into account culture. Programmers are not every-day users, > and the assumptions we take should adapt to their needs. This is > why it is worth exploring what might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, > > > But programmers new to Pharo don't know the shortcuts. Menus > enhance the explorability of the system, and lower the cognitive > load of remembering everything all at once, and helps with video > tutorials. > cheers -ben > > > Perhaps it was not clear, but the current discussion is about > copy/cut/paste :). > > Cheers, > Doru > > Yes, it was not clear. I was thinking more of the "Extended search..." and suchlike, but I see you've mentioned addressing that already. cheers -ben > > > but I did not consider the case in which people go through > multiple virtual boxes to get to the image. This is a legitimate > issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > On 04 Oct 2014, at 22:43, Tudor Girba > <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> > <mailto:tudor@tudorgirba.com > <mailto:tudor@tudorgirba.com>>> wrote: > > Hi HernÃ¡n, > > Thanks for the feedback. Just a question: Was there > anything you > do like? :) > > The rest of the reply is inline. > > > On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com > <mailto:hernan.morales@gmail.com> > <mailto:hernan.morales@gmail.__com > <mailto:hernan.morales@gmail.com>>> wrote: > > Sorry if following issues were reported. I have seen > so many > mails about GT that I wanted to try it. These are my > first > notes and personal tastes, don't take them as > negative just > want to provide some feedback: > > - First weird thing: The Workspace doesn't open a > Workspace > anymore, it opens a Playground window. > > > That is because it is still a work in progress. > > - When I select code, right click gives no "Copy, > Cut, Delete" > commands. > > > This was reported. The menu is missing on purpose. I > still have a > hard time understanding why a developer needs those menu > entries, > but we will add them back. Btw, the shortcuts do work. > > > Is an usability principle: A system should provide visual > feedback > about what happens and about what it can do. How can we > know what can or cannot do the playground? > But of course, using menus as documentation is not always a good > idea, soâ¦ we need to find a balance here :) > I always use OSX design guidelines as a base on what I want > to do > (not that we should take it literally, but is always good to see > what others with time to invest have to say). And this > is all what they say about > menus: > https://developer.apple.com/__library/mac/documentation/__userexperience/co… > <https://developer.apple.com/library/mac/documentation/userexperience/concep…> > > Esteban > > > - Selecting an instance variable from the "State" tab, > completely shift the code view and scrolls to a new > Inspector. > Is not that I would love to scroll back everytime to > get a > view on my code. > > > The usage depends on the scenario in which you are. In > most cases, > when you do want to drill through many objects, you are > likely to > only use the playground as an entry point. When you > build a more > elaborate piece of code in the playground, you typically > do not > need to drill too much. In any case, if you want to > scroll back, > there are also keybindings that allow you to navigate: > Cmd+Alt+Left/Right. > > - I cannot find how to close new Inspector tabs. > > > This is a feature that is already planned. > > - "Print it" seems broken. It seems to print > evaluation result > but suddenly dissapears. > > > What do you mean? Can you elaborate on that? Print it should > behave like here: > > - Debugger buttons Into, Through, etc. > -- They are too small and close themselves for the > importance > they have. > -- They have no caption, so you have to mouse over > to know > what they do (until you get used to) > -- They are like "too distant" from the code view. > > > The debugger is not in the Pharo image, so I think you > are trying > the Moose image. Is that so? > In any case, the positioning of the icons will be the same > everywhere in GT (to the right of the scope they relate > to). We > are still fiddling with the right balance in the debugger. > > Cheers, > Doru > > > Cheers, > > HernÃ¡n > > > > > > -- www.tudorgirba.com <http://www.tudorgirba.com> > <http://www.tudorgirba.com/> > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 5, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 5, 2014

[pharo-project/pharo-core] 32845c: 40284

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 32845c46176f43f87157c4ccc34157cf9392aa05 https://github.com/pharo-project/pharo-core/commit/32845c46176f43f87157c4cc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-05 (Sun, 05 Oct 2014) Changed paths: M KernelTests.package/IVsAndClassVarNamesConflictTest.class/definition.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/setUp.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/tearDown.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/setUp.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/tearDown.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingCapitalizedInstanceVariables.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingClasseVariablesBeginingWithLowerCaseCharacters.st M KernelTests.package/ObsoleteTest.class/definition.st A KernelTests.package/ObsoleteTest.class/instance/running/setUp.st A KernelTests.package/ObsoleteTest.class/instance/running/tearDown.st R KernelTests.package/ObsoleteTest.class/instance/testing/testClassObsolete.st R KernelTests.package/ObsoleteTest.class/instance/testing/testTraitObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testClassObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testFixObsoleteSharedPools.st A KernelTests.package/ObsoleteTest.class/instance/tests/testTraitObsolete.st M MonticelloGUI.package/MCSliceMaker.class/instance/actions/downloadIssueSummary.st A MonticelloGUI.package/MCSliceMaker.class/instance/actions/informFailedWith_.st A Morphic-Base.package/StringMorph.class/class/examples/exampleManyStringMorphs.st R Morphic-Base.package/StringMorph.class/class/testing/test.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/example.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/exampleDisable.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/labelFont.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabelFor_label_getEnabled_.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabel_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/examples/exampleButtonNoAction.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_action_label_help_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_getState_action_arguments_getEnabled_label_help_.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/example.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/exampleWithMenu.st R Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/as yet unclassified/from_label_to_label_contextClass_.st A Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/instance creation/from_label_to_label_contextClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/definition.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/accessing/nextCount.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/cleaning/deleteClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newClassName.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_category_.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_poolDictionaries_category_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script284.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40284.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteBindings.st M System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteReferences.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteSharedPools.st M Traits.package/TBehavior.class/instance/accessing/sharedPoolNames.st M Traits.package/TClassDescription.class/instance/printing/sharedPoolsString.st Log Message: ----------- 40284 13905 entering non existing issue numbers in slice maker https://pharo.fogbugz.com/f/cases/13905 14164 using exampleWidget and not widgetExample https://pharo.fogbugz.com/f/cases/14164 13088 Deleting class that is used in pool dictionaries leaves a "private" class pool entry https://pharo.fogbugz.com/f/cases/13088 http://files.pharo.org/image/40/40284.zip

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Esteban Lorenzano

> On 05 Oct 2014, at 18:24, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > Tudor Girba wrote: > Hi Esteban, > > I know it's a usability principle, but usability should also take into account culture. Programmers are not every-day users, and the assumptions we take should adapt to their needs. This is why it is worth exploring what might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, > > But programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. > cheers -ben > > Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Well, I donât know if it helps, but I cannot think on a single app in my life that does not have those ubiquitous copy/cut/paste options as part of their contextual menus. Not that because everybody does it we *have to* do it tooâ¦ but I do not see a reason to not follow the universal conventions in this case. Esteban > > Cheers, > Doru > > > > but I did not consider the case in which people go through multiple virtual boxes to get to the image. This is a legitimate issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com> > <mailto:tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>> wrote: > > Hi HernÃ¡n, > > Thanks for the feedback. Just a question: Was there anything you > do like? :) > > The rest of the reply is inline. > > > On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com> <mailto:hernan.morales@gmail.com <mailto:hernan.morales@gmail.com>>> wrote: > > Sorry if following issues were reported. I have seen so many > mails about GT that I wanted to try it. These are my first > notes and personal tastes, don't take them as negative just > want to provide some feedback: > > - First weird thing: The Workspace doesn't open a Workspace > anymore, it opens a Playground window. > > > That is because it is still a work in progress. > > - When I select code, right click gives no "Copy, Cut, Delete" > commands. > > > This was reported. The menu is missing on purpose. I still have a > hard time understanding why a developer needs those menu entries, > but we will add them back. Btw, the shortcuts do work. > > Is an usability principle: A system should provide visual feedback > about what happens and about what it can do. How can we know what can or cannot do the playground? > But of course, using menus as documentation is not always a good > idea, soâ¦ we need to find a balance here :) > I always use OSX design guidelines as a base on what I want to do > (not that we should take it literally, but is always good to see > what others with time to invest have to say). And this is all what they say about > menus: https://developer.apple.com/library/mac/documentation/userexperience/concep… <https://developer.apple.com/library/mac/documentation/userexperience/concep…> > > Esteban > > > - Selecting an instance variable from the "State" tab, > completely shift the code view and scrolls to a new Inspector. > Is not that I would love to scroll back everytime to get a > view on my code. > > > The usage depends on the scenario in which you are. In most cases, > when you do want to drill through many objects, you are likely to > only use the playground as an entry point. When you build a more > elaborate piece of code in the playground, you typically do not > need to drill too much. In any case, if you want to scroll back, > there are also keybindings that allow you to navigate: > Cmd+Alt+Left/Right. > > - I cannot find how to close new Inspector tabs. > > > This is a feature that is already planned. > > - "Print it" seems broken. It seems to print evaluation result > but suddenly dissapears. > > > What do you mean? Can you elaborate on that? Print it should > behave like here: > > - Debugger buttons Into, Through, etc. > -- They are too small and close themselves for the importance > they have. > -- They have no caption, so you have to mouse over to know > what they do (until you get used to) > -- They are like "too distant" from the code view. > > > The debugger is not in the Pharo image, so I think you are trying > the Moose image. Is that so? > In any case, the positioning of the icons will be the same > everywhere in GT (to the right of the scope they relate to). We > are still fiddling with the right balance in the debugger. > > Cheers, > Doru > > > Cheers, > > HernÃ¡n > > > > > > -- www.tudorgirba.com <http://www.tudorgirba.com/> <http://www.tudorgirba.com/ <http://www.tudorgirba.com/>> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> <http://www.tudorgirba.com <http://www.tudorgirba.com/>> > > "Every thing has its own flow" > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Tudor Girba

Hi, On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > >> Hi Esteban, >> >> I know it's a usability principle, but usability should also take into >> account culture. Programmers are not every-day users, and the assumptions >> we take should adapt to their needs. This is why it is worth exploring what >> might or might not be needed. >> >> I cannot believe that programmers do not know the shortcuts, >> > > But programmers new to Pharo don't know the shortcuts. Menus enhance the > explorability of the system, and lower the cognitive load of remembering > everything all at once, and helps with video tutorials. > cheers -ben > Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Cheers, Doru > but I did not consider the case in which people go through multiple >> virtual boxes to get to the image. This is a legitimate issue, so these >> actions are back. >> >> Cheers, >> Doru >> >> >> On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >> On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com >>> <mailto:tudor@tudorgirba.com>> wrote: >>> >>> Hi HernÃ¡n, >>> >>> Thanks for the feedback. Just a question: Was there anything you >>> do like? :) >>> >>> The rest of the reply is inline. >>> >>> >>> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>> >>> Sorry if following issues were reported. I have seen so many >>> mails about GT that I wanted to try it. These are my first >>> notes and personal tastes, don't take them as negative just >>> want to provide some feedback: >>> >>> - First weird thing: The Workspace doesn't open a Workspace >>> anymore, it opens a Playground window. >>> >>> >>> That is because it is still a work in progress. >>> >>> - When I select code, right click gives no "Copy, Cut, Delete" >>> commands. >>> >>> >>> This was reported. The menu is missing on purpose. I still have a >>> hard time understanding why a developer needs those menu entries, >>> but we will add them back. Btw, the shortcuts do work. >>> >> >> Is an usability principle: A system should provide visual feedback >> about what happens and about what it can do. How can we know what >> can or cannot do the playground? >> But of course, using menus as documentation is not always a good >> idea, soâ¦ we need to find a balance here :) >> I always use OSX design guidelines as a base on what I want to do >> (not that we should take it literally, but is always good to see >> what others with time to invest have to say). And this is all >> what they say about >> menus: https://developer.apple.com/library/mac/documentation/ >> userexperience/conceptual/applehiguidelines/Menus/Menus.html >> >> Esteban >> >> >>> - Selecting an instance variable from the "State" tab, >>> completely shift the code view and scrolls to a new Inspector. >>> Is not that I would love to scroll back everytime to get a >>> view on my code. >>> >>> >>> The usage depends on the scenario in which you are. In most cases, >>> when you do want to drill through many objects, you are likely to >>> only use the playground as an entry point. When you build a more >>> elaborate piece of code in the playground, you typically do not >>> need to drill too much. In any case, if you want to scroll back, >>> there are also keybindings that allow you to navigate: >>> Cmd+Alt+Left/Right. >>> >>> - I cannot find how to close new Inspector tabs. >>> >>> >>> This is a feature that is already planned. >>> >>> - "Print it" seems broken. It seems to print evaluation result >>> but suddenly dissapears. >>> >>> >>> What do you mean? Can you elaborate on that? Print it should >>> behave like here: >>> >>> - Debugger buttons Into, Through, etc. >>> -- They are too small and close themselves for the importance >>> they have. >>> -- They have no caption, so you have to mouse over to know >>> what they do (until you get used to) >>> -- They are like "too distant" from the code view. >>> >>> >>> The debugger is not in the Pharo image, so I think you are trying >>> the Moose image. Is that so? >>> In any case, the positioning of the icons will be the same >>> everywhere in GT (to the right of the scope they relate to). We >>> are still fiddling with the right balance in the debugger. >>> >>> Cheers, >>> Doru >>> >>> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >>> >>> >>> -- www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >>> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >> > > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] History of the .image

by stepharo

Hilaire I do not know if this is there but you may find that on the history book. Now soon we will have pharo bootstrapped in production :) You can ask guille to know where to look :) On 5/10/14 12:51, Hilaire wrote: > Le 04/10/2014 16:16, David T. Lewis a Ã©crit : >> On Sat, Oct 04, 2014 at 04:00:15PM +0200, Hilaire wrote: >>> Hello, >>> >>> I am curious. What is the history of the Pharo image? I know it is >>> forked from Squeak, but then from where does come the Squeak image? >>> How and when was it build from its source code definition? >>> When did it became an "evolving organism" as it is today? >>> >>> Thanks >>> >>> Hilaire >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/17995… >> >> >> >> > > Thanks for the pointer. But my curiosity targets technical > considerations. How and when was done the first image bootstrap, then at > this moment was the image became the base of development, or was a kind > of boostrap-image-build from source still done for some time. > > Hilaire >

Oct. 5, 2014