Re: [Pharo-dev] Versioner
I just don't see it the way you do. 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. What stops anyone from implementing his own configuration tool ? On Mon, Jun 30, 2014 at 10:23 AM, Diego Lont wrote: > I am afraid this mail is going to be too long, but I feel it needs to be > written. I will start with the conclusion, so you can skip the mail if you > feel it does not interest you. Please keep the discussion on the Moose > list, as there the discussion was started. > > I am very happy that versioner is being built. We need more and better > software configuration tools, and versioner will make our life easier. 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. > > Software configuration management (SCM) is in my opinion an undervalued > topic within the software world. One cannot find very many good books on > them, and I am afraid this lack of knowledge shows in the way people go > around with their SCM. So I would like to write down some observations of > the SCM processes in Pharo that I believe we should keep in mind. > > The main target of SCM is to keep the impact of changes as minimal as > possible. Good SCM allows all people working on a certain project, to make > their changes, without causing trouble for other project members and people > using this project. Open source projects are (in SCM terms) rather complex, > as they involve a lot of people, including some people we do not know. > > 1. One of the best things of Metacello is that it does not require you to > follow a certain workflow. It is very flexible and supports a large range > of possible workflows. Within the Pharo community we have at least 3 > different workflows: > A. For Pharo core, we have a pharo inbox, where suggested fixes for > reported bugs are put. These fixes are reviewed and, if accepted, > integrated into Pharo. This ensures that the changes in Pharo hold (most of > the time) to quite some quality standards. > B. For the “cross-platform” projects (Grease, Seaside, Magritte, etc.) all > suggested fixes are put in the main repository on smalltalkhub. The fixes > are, after review and tests, released by putting them in a “released” > version of the configuration. Since not all fixes should be in all > versions, and sometimes only concern a certain platform, the process for > Pharo core would not work: releasing fixes are more complex because of the > cross-platform issues. > C. For the “moose” projects all suggested fixes are put in the main > repository and are accepted by default. Since most projects evolve very > fast, quality assurance is done afterwards, by submitting bug fixes. > > I can say a lot about why I believe these workflows are appropriate for > their different projects, but the point I am trying to make here, is that > these workflows have come to existence because of the different demands on > them. And to stress my point about the flexibility (thank you Dale): > When there was a problem with the workflow in the cross platform projects, > I could find a solution (using releases) that Metacello supported. > > 2. Unfortunately Metacello does not have a good UI. And for large > configurations like Seaside, it is a lot of work to keep them maintained. I > dream of a tool that acts as a UI for Metacello: this tool is flexible as > Metacello, while making the simple things real easy (hitting a button and > done). Does versioner aim to do this? > > 3. I always get very nervous when someone says: They do it like this, and > that works very well for them. So we should do that too. I do not believe > that is always a good idea. The conclusion should be a question: Can we use > that too? And now I cannot find the mail about the java SCM practice, but I > do not think we can apply it to all our processes ... > > 4. Modularity is very important. Also for performing good SCM. And yes, we > lack sufficient modularity in Moose. It should be better. I.e. because of > the lack of modularity, it is sometimes hard to distinguish between where > the change needs to be put in. So there is no clear group to point out who > should accept the changes. So this is also an SCM problem. > > Cleaning up the configuration will help here very much. Thank you Steff > for the good work here. And maybe you also have a point that the people > working on Moose should have more focus on keeping things modular, because > it makes the system better maintainable in a lot of ways. > > 5. Forking things will only make SCM worse, as it adds a complexity. So I > very much hope we can come to an agreement how the process works, without > resorting to drastic measures. > > Regards, > Diego >
Re: [Pharo-dev] Versioner
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
Re: [Pharo-dev] Versioner
On Mon, Jun 30, 2014 at 8:49 AM, Stephan Eggermont 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
Re: [Pharo-dev] Versioner
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.
Re: [Pharo-dev] Versioner
On Mon, Jun 30, 2014 at 10:01 AM, kilon alios 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
Re: [Pharo-dev] Versioner
2014-06-30 13:15 GMT-03:00 Dale Henrichs : > 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!
Re: [Pharo-dev] Versioner
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
Re: [Pharo-dev] Versioner
Esteban, Just to be clear, I believe that there should be Smalltalk scripting/cli from within the image (augment workspace usage) as well as from without ... more food (for lunch) thought:) Dale On Mon, Jun 30, 2014 at 11:36 AM, Esteban A. Maringolo wrote: > 2014-06-30 13:15 GMT-03:00 Dale Henrichs >: > > 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! > >
Re: [Pharo-dev] Versioner
That is exactly my point. But Stef currently tries to enforce this workflow of working to Moose. And since this workflow will not work well for Moose (because of the demands on the process), I object to this. I don't think Stef wants to impose the workflow. Stef wants to improve code modularity in Moose and avoid broken / bad configs. Moose is a big project and one solution to ease the maintenance is to use a tool (Versionner for example). Now it is clear that Versionner does not have all features to support the Moose process and I will take some time to see how to implement a smart deep release. With that, it should be enough to support Moose workflow. We want to have a working workflow :) And the point is to make one becoming true. After we can discuss. Stef
Re: [Pharo-dev] Versioner
Your response shows that I have not made my point well. I wanted to point out that we need different workflows because of the different demands. A workflow is more than only a tool, but starts with people building something and ends with people using something. And you point out that versioner has one workflow implemented, and therefor will not be applicable to all projects. A. For pharo core all projects are included in pharo. The number of external influences (VM, plugins) is very limited. It works here to have no configuration at all, since there is only 1 release-branch: the current one. And since the file server creates a version of each build, we can always go back to a specific build. Quality is very important to pharo as a lot of users depend on a good working pharo. But it should not be like that! Pharo should be modular too. And we need to have configurations. Why we cannot have better tools based on Roassal because we do not want to have a monolithic solution. So we should have a modular image and tools and process to get there. B. For the “cross-platform” projects this workflow is not sufficient, because there are much more external influences. So here we use the configurations to manage the releases. And the complexity of the configuration of Seaside shows this is a very complex thing to do. This complexity is not from Metacello. Metacello allows us to do a decent job here for the supported platforms. For the unsupported platforms there is some additional manual work involved, with all risks to this. The complexity here stems from the Software Configuration challenges Seaside faces. A simple inbox won’t do the job for us. Quality here is also very important as a lot of users depend on a good working Seaside. Also there are more demands on reproducibility, as there are quite some systems depending on Seaside that should function 24/7. C. For the “moose” projects, we have a few advantages above the cross-platform projects, and a few disadvantages: + Moose only needs to work for pharo. So we can cut out a lot of platform specific junk. Some projects are suited for multiple platforms, but not for the amount of platform Seaside should work on. + There are far less projects depending on Moose. Most of them are integrated, so tests will automatically be fired. And the projects that do depend on Moose usually do not have run 24/7. - Moose depends on more projects then Seaside. To create an exact version is therefor much harder. - A large part of the Moose bugs comes from the change rate of the projects Moose depends on. Pharo has a very drastic strategy to improve its architecture. This causes quite some maintenance work. So that there is no review is not the point. The point is that because of these different demands we need to accept a lower quality standard for moose. This lower quality standard is maybe undesirable, but is not easily improved. Having no review is a consequence of this, not the cause. If we want to improve this quality standard, better SCM tools will not suffice. On the other hand, this lower quality standard has so far worked for Moose, as there are less people who depend on Moose. Regards, Diego
Re: [Pharo-dev] Versioner
Hi Stephan, Le 30 juin 2014 à 20:50, Stephan Eggermont a écrit : > 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. I don't think it is the problem because the solving to exact versions is an option (You have a check box). The real problem is the support of platform-specific sections. > 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. Yes but some part are reusable. For example, Versionner uses MetacelloToolBox that was not thinked to support the current Versionner workflow. Versionner has some classes (model, commands) aside the GUI that can be reused for other workflows. Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Versioner
> Am 30.06.2014 um 20:50 schrieb 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. I disagree here. Using symbolic versions in a release just seems to be easier to use while being wrong. I'm talking about a "release" here. A release is only useful if you have exact versions. Everything else is asking for trouble and not reliable. That you can read in the mail archives. Nevertheless if you want a workflow where everything is updated in an uncontrolled way so be it. What you are saying is that metacello is lacking support for specifying if baseline symbolic versions should be resolved or not, right? I do not really see how versionner can influence this. Even if versionner would try to solve this in a custom way the configuration of that would have to be put in the metacello config as well. But where? Or did I miss the point? Norbert > > 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
[Pharo-dev] Versioner does not work on Pharo 4
So I tried today to open versioner to make a configuration for Ephestos and i got this error RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode EphPyParser class(Object)>>mustBeBooleanInMagic: EphPyParser class(Object)>>mustBeBoolean MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: EphPyParser class(Object)>>mustBeBooleanInMagic: EphPyParser class(Object)>>mustBeBoolean [ :cl | (answer includes: cl) ifFalse: [ (([ cl isMetacelloConfig ] on: Error do: [ :ex | ex return: false ]) and: [ cl name asString beginsWith: 'ConfigurationOf' ]) ifTrue: [ answer add: cl ] ] ] in MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | ... OrderedCollection>>do: MetacelloProjectRegistration class>>configurationClasses MetacelloToolBox class>>configurationClasses MBConfigurationRoot>>configurationClasses MBConfigurationRoot>>configurations VersionnerSpecBrowser class>>imageConfigurations VersionnerSpecBrowser class>>open [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser class>>menuCommandOn: in Block: [ VersionnerSpecBrowser open ] BlockClosure>>cull: [ | selArgCount | "show cursor in case item opens a new MVC window" (selArgCount := selector numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount = arguments size ifTrue: [ target perform: selector withArguments: arguments ] ifFalse: [ target perform: selector withArguments: (arguments copyWith: evt) ] ]. self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: ToggleMenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using:
Re: [Pharo-dev] Versioner does not work on Pharo 4
Hi Kilon, You error is strange. I use Versionner on Pharo 4.0 without any problem. If I take a closer look at the stack trace, the error comes from the MetacelloToolBox when Versionner asks for configuration classes. What is really strange is that after this message sent, the stack shows the execution goes through EphPyParser class(Object)>>mustBeBoolean. I don't get why. I tried in a fresh Pharo image to load Ephestos, create a config for it, and got no problem. Can you try to reproduce and give more information about the environment, what you did? Thanks, Christophe. Le 17 sept. 2014 à 16:57, kilon alios a écrit : > So I tried today to open versioner to make a configuration for Ephestos and i > got this error > > RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode > EphPyParser class(Object)>>mustBeBooleanInMagic: > EphPyParser class(Object)>>mustBeBoolean > MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: > EphPyParser class(Object)>>mustBeBooleanInMagic: > EphPyParser class(Object)>>mustBeBoolean > [ :cl | > (answer includes: cl) > ifFalse: [ > (([ cl isMetacelloConfig ] > on: Error > do: [ :ex | ex return: false ]) and: [ cl name asString > beginsWith: 'ConfigurationOf' ]) > ifTrue: [ answer add: cl ] ] ] in > MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | ... > OrderedCollection>>do: > MetacelloProjectRegistration class>>configurationClasses > MetacelloToolBox class>>configurationClasses > MBConfigurationRoot>>configurationClasses > MBConfigurationRoot>>configurations > VersionnerSpecBrowser class>>imageConfigurations > VersionnerSpecBrowser class>>open > [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser class>>menuCommandOn: > in Block: [ VersionnerSpecBrowser open ] > BlockClosure>>cull: > [ > | selArgCount | > "show cursor in case item opens a new MVC window" > (selArgCount := selector numArgs) = 0 > ifTrue: [ target perform: selector ] > ifFalse: [ > selArgCount = arguments size > ifTrue: [ target perform: selector withArguments: > arguments ] > ifFalse: [ target perform: selector withArguments: > (arguments copyWith: evt) ] ]. > self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in > Block: [ ... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > ToggleMenuItemMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > MenuMorph(Morph)>>processEvent:using: > smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Versioner does not work on Pharo 4
Well to kepp you updated , because I did not bother replying to my own thread since none seemed to care or have the same issue as me. I tried on windows again same error as macos on a fresh image by the way. So I know it must not be me. But now with a latest Pharo 4 image i get no errors in both Macos and Windows, so the bug apparently was fixed. That may explain why you get no error , maybe it was a bug in a specific release. The only things I am doing with pharo is 1) use dark theme 2) use free type font Arial on windows and Monaco on macos 3) use filetree for working with a git directory. On Fri, Sep 19, 2014 at 11:20 AM, Christophe Demarey < christophe.dema...@inria.fr> wrote: > Hi Kilon, > > You error is strange. I use Versionner on Pharo 4.0 without any problem. > If I take a closer look at the stack trace, the error comes from the > MetacelloToolBox when Versionner asks for configuration classes. > What is really strange is that after this message sent, the stack shows > the execution goes through EphPyParser class(Object)>>mustBeBoolean. > I don't get why. > I tried in a fresh Pharo image to load Ephestos, create a config for it, > and got no problem. > Can you try to reproduce and give more information about the environment, > what you did? > > Thanks, > Christophe. > > Le 17 sept. 2014 à 16:57, kilon alios a écrit : > > > So I tried today to open versioner to make a configuration for Ephestos > and i got this error > > > > RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode > > EphPyParser class(Object)>>mustBeBooleanInMagic: > > EphPyParser class(Object)>>mustBeBoolean > > MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: > > EphPyParser class(Object)>>mustBeBooleanInMagic: > > EphPyParser class(Object)>>mustBeBoolean > > [ :cl | > > (answer includes: cl) > > ifFalse: [ > > (([ cl isMetacelloConfig ] > > on: Error > > do: [ :ex | ex return: false ]) and: [ cl name > asString beginsWith: 'ConfigurationOf' ]) > > ifTrue: [ answer add: cl ] ] ] in > MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | > ... > > OrderedCollection>>do: > > MetacelloProjectRegistration class>>configurationClasses > > MetacelloToolBox class>>configurationClasses > > MBConfigurationRoot>>configurationClasses > > MBConfigurationRoot>>configurations > > VersionnerSpecBrowser class>>imageConfigurations > > VersionnerSpecBrowser class>>open > > [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser > class>>menuCommandOn: in Block: [ VersionnerSpecBrowser open ] > > BlockClosure>>cull: > > [ > > | selArgCount | > > "show cursor in case item opens a new MVC window" > > (selArgCount := selector numArgs) = 0 > > ifTrue: [ target perform: selector ] > > ifFalse: [ > > selArgCount = arguments size > > ifTrue: [ target perform: selector withArguments: > arguments ] > > ifFalse: [ target perform: selector withArguments: > (arguments copyWith: evt) ] ]. > > self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > in Block: [ ... > > BlockClosure>>ensure: > > CursorWithMask(Cursor)>>showWhile: > > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > > MouseButtonEvent>>sentTo: > > ToggleMenuItemMorph(Morph)>>handleEvent: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > ToggleMenuItemMorph(Morph)>>processEvent:using: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > MenuMorph(Morph)>>processEvent:using: > > > >
Re: [Pharo-dev] Versioner does not work on Pharo 4
Le 19 sept. 2014 à 11:21, kilon alios a écrit : > Well to kepp you updated , because I did not bother replying to my own thread > since none seemed to care or have the same issue as me. I was out of office last days ... > I tried on windows again same error as macos on a fresh image by the way. So > I know it must not be me. On which image? I just tried on a fresh 3.0 image and it also works for me. > The only things I am doing with pharo is > > 1) use dark theme > > 2) use free type font Arial on windows and Monaco on macos > > 3) use filetree for working with a git directory. Maybe a side effect. Could you give me a script to help reproducing the problem? Maybe just your startup script. Does the problem appear the first time you open Versionner? Thanks, Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Versioner does not work on Pharo 4
just for the record I have not created any kind of configuration in Ephestos. The code that you can download from Smalltalkhub or github is the only thing that lives inside the image. I use Smalltalkhub as a backup for github repo until I make sure filetree is a reliable way to work with github and pharo. I have not touche any of the internals of Pharo all my code lives inside the SThub repo. Other than the steps I described , and the code you can get from sthub I have done nothing to the pharo image. Also I forgot to say I dont mind at all late replies, I did not want to imply that I was annoyed or anything like that with people not replying. Its perfectly ok to not reply to my threads or reply days afterwards or even moths. I have in my hand scientific evidence that I am not the center of this world. Thank you Christopher and everyone who is trying to help me in each of my problems. I really appreciate it. On Fri, Sep 19, 2014 at 12:49 PM, kilon alios wrote: > I dont use a startup script myself, in windows the image with problem is > release 40230, i download that specific release and it works o_O , so maybe > it was something I did afterall ? very strange > > so I attached my image folder, hope it helps you > > On Fri, Sep 19, 2014 at 12:39 PM, Christophe Demarey < > christophe.dema...@inria.fr> wrote: > >> >> Le 19 sept. 2014 à 11:21, kilon alios a écrit : >> >> > Well to kepp you updated , because I did not bother replying to my own >> thread since none seemed to care or have the same issue as me. >> >> I was out of office last days ... >> >> > I tried on windows again same error as macos on a fresh image by the >> way. So I know it must not be me. >> >> On which image? I just tried on a fresh 3.0 image and it also works for >> me. >> >> > The only things I am doing with pharo is >> > >> > 1) use dark theme >> > >> > 2) use free type font Arial on windows and Monaco on macos >> > >> > 3) use filetree for working with a git directory. >> >> Maybe a side effect. >> Could you give me a script to help reproducing the problem? Maybe just >> your startup script. >> Does the problem appear the first time you open Versionner? >> >> Thanks, >> Christophe. > > >
