- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versioner

by Stephan Eggermont

Kilon wrote: >I disagreed with this Stephan > >"That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my >fears are unfounded." > >this what I was replying to. Ok. The concrete problem we ran into with the current version of Versioner is that it wants to resolve dependencies to exact versions. For configurations depending on Seaside, Magritte or Grease, this is normally unwanted. They should depend on the symbolic release versions. With the high number of changes in Pharo, exact versions have a short lifetime. Dale wrote: >In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) > it is much easier to construct custom "tools" to support variations in workflow >... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... In order to work together effectively in open source projects it is important that contributors know what workflow is used in a project. That is easier when the number of different workflows is limited. Because projects depend on other projects the number of combinations of workflow is very large. Scriptable tools can easily support these resulting combinations. Building a GUI tool that is both very flexible and very easy to use seems to be less easy. Stephan

June 30, 2014

Re: [Pharo-dev] Versioner

by Esteban A. Maringolo

2014-06-30 13:15 GMT-03:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy > to customize (for several reasons) ... before knickers get knotted, please > keep in mind that I think that customizable GUI-based tools are important, > it's just that the GUI raises the entry level bar a bit higher than it needs > to be... > > There is room in Smalltalk for plain old-fashioned scripts (workspaces don't > quite cut it in this regard) that can be easily shared and customized (and > written in Smalltalk) ... > > anway, some (breakfast) food for thought... This is, in my opinion, a flaw that affects any system born as a GUI. There was no CLI culture in the past. It happens to Smalltalk, obviously, and also affected Microsoft (another UI centric OS) who had to put a lot of effort (and $$$) to add command line support for most of their solutions, as a response to devops and similar users. Mac got developer traction since they put BSD underneath a fancy GUI. According to the Unix Philosophy (http://en.wikipedia.org/wiki/Unix_philosophy) Smalltalk, and Pharo, are compliant with the "Rule of Modularity" whitin the image, but not with the "Rule of composition" as seen from external programs. Pharo's command line support is certainly better than before. But we're not there yet, when even web pages are mostly composed/scaffolded/provisioned using CLI tools today instead of using behemont tools like Dreamweaver/Expression. This is also food for thought. In case anybody is still hungry. :) Regards!

June 30, 2014

Amber frontend with Pharo backend

by Sebastian Sastre

Hi guys, cross-posting to Amber groupâ¦ Iâve recently published the code of http://tasks.flowingconcept.com Here: http://github.com/sebastianconcept/tasks Have fun sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

June 30, 2014

Re: [Pharo-dev] Versioner

by Dale Henrichs

On Mon, Jun 30, 2014 at 10:01 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > ----------Dale------------- > > "Smalltalk with it's heavy reliance on GUI-based tools is not quite as > easy to customize (for several reasons) ... before knickers get knotted, > please keep in mind that I think that customizable GUI-based tools are > important, it's just that the GUI raises the entry level bar a bit higher > than it needs to be... " > > I can't speak for others but I would say that for me is lack of > documentation mainly, I am actually learning Rubric slowly, obviously I > don't code in Pharo full time as some of you nor I have years of experience > in my back, reading and understanding code is a slow process. If those > tools were well documented there would be a lot more people hacking them > and contributing to them since it would lower the steep learning curve > quite substantially. But I can understand that Pharo has not the amount of > people that for example emacs has to provide an in depth documentation > about its tools and libraries and I try to help it to come one step closer. > > I don't think not having GUIs is a problem for me. I did not have issues > working with Metacello . I actually recently started using Versioner and I > use it for the simple stuff, have no issues falling back to metacello if I > have to. Pharo puts emphasis on GUI but it should not be viewed as a > mandatory requirement. I am actually working on making Workspace behave > similar to emacs with as less GUI as possible. There is even a tool to run > a shell terminal inside Pharo and of course we should forget that Pharo > runs from terminal too. > Cool! I really think it is worthwhile exploring the territory "below the GUI" or "with minimal GUI" ... there is no question that a good GUI tool is very useful, but there is a place for the stripped down minimal effort tools as well ... Dale

June 30, 2014

Re: [Pharo-dev] Versioner

by kilon alios

----------------Stephan--------------- "That's fine, you work in a different context than we do. What do you disagree on?" I disagreed with this Stephan "That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and *not* to create a single workflow for all people working on pharo projects. I hope my fears are unfounded." this what I was replying to. "You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation." I have read through it yes, I did not argue that Versioner is perfect. I am actually arguing the opposite, that is a rather basic tool, it gets some basic tasks done but obviously its not the "one ring to rule them all" meaning its up to pharo developers to contribute and improve it or create additional tools to assist with tasks that Versioner can't handle. I disagree that it has an agenda to enforce a single workflow. It is what it is and it can be improved. "Common sense, I hope..." So basically what you saying is that being in a environment ( Pharo ) which is making it easier to create your own IDE tools is not common sense to create your own IDE tools ? You want to join efforts that fine , you want to do it your own way thats fine too, the end result is tools that solve problems. Obviously joining effort is the preferable choice, but doing your own thing is a recipe that Pharo has been based on. I think its great to have these discussion so people are aware of problems before they face them in real life. I definitely would love to read about these problems and plan ahead my actions. If its a problem for Moose people there is no reason to believe it won't be a problem for others in the near future. ----------Dale------------- "Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... " I can't speak for others but I would say that for me is lack of documentation mainly, I am actually learning Rubric slowly, obviously I don't code in Pharo full time as some of you nor I have years of experience in my back, reading and understanding code is a slow process. If those tools were well documented there would be a lot more people hacking them and contributing to them since it would lower the steep learning curve quite substantially. But I can understand that Pharo has not the amount of people that for example emacs has to provide an in depth documentation about its tools and libraries and I try to help it to come one step closer. I don't think not having GUIs is a problem for me. I did not have issues working with Metacello . I actually recently started using Versioner and I use it for the simple stuff, have no issues falling back to metacello if I have to. Pharo puts emphasis on GUI but it should not be viewed as a mandatory requirement. I am actually working on making Workspace behave similar to emacs with as less GUI as possible. There is even a tool to run a shell terminal inside Pharo and of course we should forget that Pharo runs from terminal too.

June 30, 2014

[pharo-project/pharo-core] 091e69: 40055

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 091e69a4d07cb65c1b95d0972dc08116dd22d64e https://github.com/pharo-project/pharo-core/commit/091e69a4d07cb65c1b95d097… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script55.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40055.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/instance/testing/isSpecial.st A Slot.package/Slot.class/instance/testing/isSpecial.st R Slot.package/SlotClassBuilder.class/instance/deprecated/client_.st M Slot.package/SlotClassBuilder.class/instance/private/apply_.st R System-ObjectStorage.package/extension/SmalltalkImage/instance/storeDataOn_.st M Tool-Profilers.package/MessageTally.class/instance/collecting leaves/leavesInto_fromSender_.st M Tool-Profilers.package/MessageTally.class/instance/comparing/sonsOver_.st M Tool-Profilers.package/MessageTally.class/instance/printing/printOn_.st M Tool-Profilers.package/QSystemTally.class/instance/testing/isPrimitives.st A Tool-Profilers.package/SpaceTally.class/class/fileout/printSpaceAnalysis.st M Tool-Profilers.package/SpaceTally.class/instance/fileout/printSpaceAnalysis.st M Tool-Profilers.package/TimeProfiler.class/instance/accessing-computed/leaveItems.st A Traits.package/TClassDescription.class/instance/slots/usesSpecialSlot.st Log Message: ----------- 40055 13441 Small code critique cleanup in Tools https://pharo.fogbugz.com/f/cases/13441 13442 add test to classes for checking non-ivar slots are used https://pharo.fogbugz.com/f/cases/13442 13443 remove #storeDataOn: from SmalltalkImage https://pharo.fogbugz.com/f/cases/13443 http://files.pharo.org/image/40/40055.zip

June 30, 2014

[pharo-project/pharo-core]

by GitHub

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

June 30, 2014

Re: [Pharo-dev] Versioner

by Dale Henrichs

On Mon, Jun 30, 2014 at 8:49 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Kilon wrote: > >I just don't see it the way you do. > Versioner makes life easier for a specific kind of projects. It is > important to be aware > of its limitations. > > >What stops anyone from implementing his own configuration tool ? > > Common sense, I hope... > Kilon has a point and so does Stephan ... In a programming language where the development environment allows script-based tools (as opposed to GUI-based tools) it is much easier to construct custom "tools" to support variations in workflow ... individual developers routinely copy/share scripts that routinely need to be customized for their environment ... Smalltalk with it's heavy reliance on GUI-based tools is not quite as easy to customize (for several reasons) ... before knickers get knotted, please keep in mind that I think that customizable GUI-based tools are important, it's just that the GUI raises the entry level bar a bit higher than it needs to be... There is room in Smalltalk for plain old-fashioned scripts (workspaces don't quite cut it in this regard) that can be easily shared and customized (and written in Smalltalk) ... anway, some (breakfast) food for thought... Dale

June 30, 2014

Re: [Pharo-dev] Versioner

by Stephan Eggermont

Kilon wrote: >I just don't see it the way you do. That's fine, you work in a different context than we do. What do you disagree on? You might have missed a discussion on the Moose list. There Stef proposed to use Versioner to manage the Moose configuration, and use it in a specific way. We noticed some problems, and try to explain where they come from in order to get an improved situation. >For me Versioner is a tool to make life a bit easier with Configurations, its not "the one ring to rule them all" , far from it. Versioner makes life easier for a specific kind of projects. It is important to be aware of its limitations. >What stops anyone from implementing his own configuration tool ? Common sense, I hope... Stephan

June 30, 2014

caturing key pressed

by Pablo R. Digonzelli

Hi all , I need to capture the key pressed in a Spec TextModel and ListModel. Can someone give orientation? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

June 30, 2014