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

Re: [Pharo-project] Problem with senders?

by Mariano Martinez Peck

Sorry...It was totally my fault :( Sorry I nwas trying to run Algernon, but it doesn't work :( I am algernon adict. I did this: Installer sm update; install: 'Algernon'. Installer wiresong project: 'ob'; install: 'OB-Algernon'. On Fri, Mar 20, 2009 at 7:48 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch>wrote: > > > I am trying to see the senders of a message. I select "startsWith:" in a > > workspace -> right button -> extended search -> senders of it and I get > > a wallback. > > I cannot reproduce this. > What kind of image do you use? Looks like a pharo-dev; but which version? > Did you update it manually to 10256? > #of:label: is defined for a long time in OBNavigate; which version of OB > have you loaded? > > David > > > MessageNotUnderstood: OBShowSenders class>>of:label: > > 20 March 2009 1:11:08 am > > > > VM: unix - a SmalltalkImage > > Image: Pharo0.1 [Latest update: #10256] > > > > SecurityManager state: > > Restricted: false > > FileAccess: true > > SocketAccess: true > > Working Dir /home/mariano/squeak/imagenes > > Trusted Dir /home/mariano/squeak/imagenes/secure > > Untrusted Dir /home/mariano/squeak/imagenes/My Squeak > > > > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: > > Receiver: OBShowSenders > > Arguments and temporary variables: > > aMessage: of: an OBSelectorNode label: 'Senders of > > startsWith: [4]' > > exception: MessageNotUnderstood: OBShowSenders > class>>of:label: > > resumeValue: nil > > Receiver's instance variables: > > superclass: OBNavigate > > methodDict: a MethodDictionary(#browserClass->a > > CompiledMethod (3617) #noChildr...etc... > > format: 136 > > instanceVariables: nil > > organization: ('as yet unclassified' browserClass > > noChildrenMessage) > > > > subclasses: nil > > name: #OBShowSenders > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #'OB-Standard-Announcements' > > traitComposition: nil > > localSelectors: nil > > > > DEVToolSet class>>browseSendersOf:name:autoSelect: > > Receiver: DEVToolSet > > Arguments and temporary variables: > > aSymbol: #startsWith: > > labelString: 'Senders of startsWith: [4]' > > autoSelectString: 'startsWith:' > > Receiver's instance variables: > > superclass: StandardToolSet > > methodDict: a MethodDictionary() > > format: 2 > > instanceVariables: nil > > organization: ('as yet unclassified') > > > > subclasses: nil > > name: #DEVToolSet > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #ImageForDevelopers > > traitComposition: nil > > localSelectors: nil > > > > ToolSet class>>browseSendersOf:name:autoSelect: > > Receiver: ToolSet > > Arguments and temporary variables: > > aSymbol: #startsWith: > > titleString: 'Senders of startsWith: [4]' > > autoSelectString: 'startsWith:' > > Receiver's instance variables: > > superclass: AppRegistry > > methodDict: a MethodDictionary() > > format: 2 > > instanceVariables: nil > > organization: ('as yet unclassified') > > > > subclasses: nil > > name: #ToolSet > > classPool: nil > > sharedPools: nil > > environment: Smalltalk > > category: #'System-Applications' > > traitComposition: nil > > localSelectors: nil > > registeredClasses: an OrderedCollection(StandardToolSet > > OTToolset DEVToolSet) > > default: DEVToolSet > > > > SystemNavigation>>browseSendersOf:name:autoSelect: > > Receiver: a SystemNavigation > > Arguments and temporary variables: > > aSelector: #startsWith: > > labelString: 'Senders of startsWith:' > > autoSelectString: 'startsWith:' > > title: 'Senders of startsWith: [4]' > > size: 4 > > senders: an OrderedCollection(a MethodReference Algernon >> > > #isMatchingClass:gi...etc... > > Receiver's instance variables: > > browserClass: nil > > hierarchyBrowserClass: nil > > > > > > --- The full stack --- > > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: > > DEVToolSet class>>browseSendersOf:name:autoSelect: > > ToolSet class>>browseSendersOf:name:autoSelect: > > SystemNavigation>>browseSendersOf:name:autoSelect: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > SystemNavigation>>browseAllCallsOn: > > [] in TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt {[self > > systemNavigation browseAllCallsOn: aSelector]} > > TextMorphForShoutEditor(Controller)>>terminateAndInitializeAround: > > TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt > > [] in PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt {[textMorph > > editor sendersOfIt]} > > [] in PluggableShoutMorph(PluggableTextMorph)>>handleEdit: {[result := > > editBlock value]} > > TextMorphForShout(TextMorph)>>handleEdit: > > PluggableShoutMorph(PluggableTextMorph)>>handleEdit: > > PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt > > UndefinedObject(Object)>>perform:orSendTo: > > [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > > {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: > > selector] ...]} > > BlockContext>>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: > > ...etc... > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 20, 2009

[Pharo-project] Pharo a VMs

by Mariano Martinez Peck

Hi men! I know very little about VMs but I have a very simple question, which vms are 100% compatibles with Pharo ? I know standard vm, cog, exupery and hydra. And which of them that are compatible with pharo is the most "performant" ? thanks, Mariano

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Igor Stasenko

Concenrning Monticello, i think it would be nice to split it on parts, like: Monticello-Core Monticello-Persistance (Files/Sockets etc) Monticello-UI (Morphic/another framework) now, make sure that Core part could work well with any squeak fork, while rest of stuff can be easily replaced by different implementations. -- Best regards, Igor Stasenko AKA sig.

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Igor Stasenko

2009/3/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is. > > Igor I think that the point of keith was not about that goal (even if > his process > implies been able to plant new trees everywhere and not cutting that > much rotten trees). Well, i tried to describe your motives, as i see it, to show that often its not possible to build a new thing without breaking an old one. Again, as i said, lets say you improved/changed the package X to suit your vision, and this package is no longer maintained by any other party. So does it makes such change evil of some sort? I don't think so. Consider a Morphic. Can anyone tell who is maintaining it? No one! Gary did a lot of hard work balancing between good and stinky code trying to improve things in his Polymorph package without breaking things in Morphic. Now think, how easier/faster it would be it we would have an official Morphic package/module and official maintainer(s) who continuously improving the code & maintaining it. > I think that keith was frustrated that we could give feedback or > threshold for > package inclusion in pharo and that he worked on them and that we > neglected > them. > Now everybody has the right to stand up for or against a package and > make a point. > Of course stating publicly that a given piece of code is great is > easier than the inverse > especially when you want to pay attention to the human at the other > end of the line. I think you have a full right to decide what [not] to include in Pharo. Keith mentioned that you making many changes to many different parts of system , which supposed to be maintained by original authour(s) or currently active team(s), without giving a feedback or credit or consulting with them about promoting such changes. Okay, i think you're not stepping into other's domain.. it would be rude.. But its going to be tricky, when you change the package X (not maintained by anyone), from which depends a lot of work, which doing in parallel by other team for package Y, which depends on X. Here lies the problem, which can be solved by communicating with people. Of course it requires the good will of both sides :) > Stef > > On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote: > >> 2009/3/20 Keith Hodges <keith_hodges(a)yahoo.co.uk>: >>>> >>>> I have nearly 20 years of brain cells now if I do not die before >>>> so I >>>> do not want to >>>> spend my time on boring stuff when I can avoid it. >>>> >>> But you are throwing the baby out with the bath water. >>>> No but we have the right to choose and consider if we like it or >>>> not. >>>> >>>> >>> Actually I disagree. >>> >>> You are mixing two completely different things here. >>> >>> 1. Squeak, an open source project with lots of stake holders that may >>> cramp your style. >>> 2. Any other completely open sub-project which you are invited to >>> contribute to and further your aims by participating with (i.e. >>> Monticello) >>> >>> When you forked pharo you understandably forked 1. There was no >>> need to >>> fork any external projects (2) >>> >>> Every sub-project (2) has its own developers, and its own culture, >>> and >>> attitude towards participation and change. When you treat other -sub >>> projects and their communities with the same contempt that you >>> understandably have towards the squeak community, you result in >>> insulting those communities. >>> >>> The initiative I started on MC has a culture of participation and >>> collaboration, together with an ethos of being as responsive as >>> possible >>> to feedback and suggestions. When you ignore this, you insult >>> everyone >>> that has put time and effort into that project. >>> >>> In a similar manner, any initiative or sub-project that you undertake >>> within pharo, can have an ethos following either of two options. >>> >>> A). Pharo team specific developed for pharo speced for pharo only. >>> B). A completely open sub-project which anyone is invited to >>> support and >>> to further your aims by participating with. >>> >>> When you pick option A, or fork option 2, you are actually insulting >>> every project that was offered to you on the basis of option 2 above. >>> Because you are saying, that you are happy to take from the other OSS >>> efforts but you are not happy to give back, or contribute back to >>> them >>> on a similarly open basis. (and "you can port it if you want it" >>> doesn't >>> count) >>> >>> The clearest example of this continues to be Monticello. >>> >>> When I do months of work and suffer considerably for the good of >>> "everyone that wants change" of which you were one person at the >>> top of >>> the list. I do the work out of the goodness of my heart because I >>> expect >>> in the ethos of open source software that there is some give and >>> take. >>> "Take" because I build on the work of others that freely >>> contributed to >>> me, and "give" because I contribute to the furtherment of the vision >>> that they started, and "take" again because I anticipate others >>> continuing the good fight in the long run on everyones behalf. >>> >>> Given a completely open independent project, that you are invited to >>> support and contribute to, on which much work has already been done >>> "on >>> YOUR behalf", in the direction of "YOUR goals". I consider it to be >>> extremely rude and insulting, for you not to join in and further your >>> own aims by contributing positively back to that project. >>> >>> The reason that I have no interest in participating in pharo, is not >>> that I dont agree with the vision. Its the fact that I find the >>> attitude >>> of the pharo team (with a couple of notable exceptions) to be >>> extremely >>> rude. Perhaps its a cultural thing. >>> >>> I consider the attitude conveyed by the words "No but we have the >>> right >>> to choose and consider if we like it or not." Â to be tantamount to >>> snobbery, when the option and invitation is completely open for you >>> to >>> participate and make it as likeable as you wish. >>> >>> It is perfectly possible for the following projects to be initiated >>> as >>> loadable modular sub-projects, developed with an ethos of >>> participation >>> for anyone to contribute and for anyone to use. >>> >>> 1. Registration for menus and UI features >>> 2. Improvements to Streams >>> 3. HTTPSocket >>> 4. Alternatives to Changesets >>> 5. Replace the changes file mechanism with something else >>> 6. Atomic loading (including traits) >>> 7. Replacements for Morphic, MVP >>> 8. Compiler >>> 9. Network. >>> 10. Compression. >>> 11. Files >>> 12. SSpec >>> 13. SUnit >>> 14. Code Browsers/Tools >>> >>> I am seriously considering licencing Rio under something other than >>> MIT, >>> so that you cant use it, until you change your attitude towards your >>> potential benefactors. >>> >> >> There is one problem with Squeak, that it grew out to something >> amorphous, up to the point that its really hard to tell where ends one >> package/module and starts another one. >> I sense the future of squeak is to make a cleaning to cut-out many >> interdependencies, for getting to the point where all code is clearly >> falls into separate modules. From this point, different modules can be >> improved separately, but not sooner. And Pharo team is doing a lot for >> making this happen. >> For example, i wouldn't buy the Compression framework which fails to >> work without Morphic/Etoys. And i don't think that making sure Â it >> doesn't have such interdependencies is a rude. I think its rude to >> keep thing in such state by honing the swamp which equally sucks the >> energy from everyone and suppressing progress. >> >> You can't plant the wheat in the forest, first you have to cut down >> the trees and get rid of stumps. >> I think its too early to say that Pharo went too far from Squeak to >> make it hard to backport any changes/improvements. I appreciate >> Stephane's attempts to chop down some old rotten trees in forest to >> make more space for growing a new sprouts. >> >> There's another aspect of same thing: a lot of Squeak code/packages >> having no maintainers. >> People expect that someone takes care of code which is released with >> image. But let us be realistic: there is no such developers/teams who >> could take a grasp of such big code base and maintain it. >> And there is choice: keep using old code (mostly w/o changes), >> sacrificing the potential of having a lot of code bloat, or cut it out >> and then reintegrate/reimplement it in a more modular style. >> >>> Keith >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 20, 2009

[Pharo-project] changeset and tests

by StÃ©phane Ducasse

Hi today I was helping a new coder here to recover some changes and I noticed that the changeset was full of doit. Apparently the tests execution seems to be added to the changesets. I will investigate that more but we should pay attention. Stef

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by StÃ©phane Ducasse

Yes. Sometimes I'm sad of removing fun stuff. But this is the way it is. Igor I think that the point of keith was not about that goal (even if his process implies been able to plant new trees everywhere and not cutting that much rotten trees). I think that keith was frustrated that we could give feedback or threshold for package inclusion in pharo and that he worked on them and that we neglected them. Now everybody has the right to stand up for or against a package and make a point. Of course stating publicly that a given piece of code is great is easier than the inverse especially when you want to pay attention to the human at the other end of the line. Stef On Mar 20, 2009, at 9:20 PM, Igor Stasenko wrote: > 2009/3/20 Keith Hodges <keith_hodges(a)yahoo.co.uk>: >>> >>> I have nearly 20 years of brain cells now if I do not die before >>> so I >>> do not want to >>> spend my time on boring stuff when I can avoid it. >>> >> But you are throwing the baby out with the bath water. >>> No but we have the right to choose and consider if we like it or >>> not. >>> >>> >> Actually I disagree. >> >> You are mixing two completely different things here. >> >> 1. Squeak, an open source project with lots of stake holders that may >> cramp your style. >> 2. Any other completely open sub-project which you are invited to >> contribute to and further your aims by participating with (i.e. >> Monticello) >> >> When you forked pharo you understandably forked 1. There was no >> need to >> fork any external projects (2) >> >> Every sub-project (2) has its own developers, and its own culture, >> and >> attitude towards participation and change. When you treat other -sub >> projects and their communities with the same contempt that you >> understandably have towards the squeak community, you result in >> insulting those communities. >> >> The initiative I started on MC has a culture of participation and >> collaboration, together with an ethos of being as responsive as >> possible >> to feedback and suggestions. When you ignore this, you insult >> everyone >> that has put time and effort into that project. >> >> In a similar manner, any initiative or sub-project that you undertake >> within pharo, can have an ethos following either of two options. >> >> A). Pharo team specific developed for pharo speced for pharo only. >> B). A completely open sub-project which anyone is invited to >> support and >> to further your aims by participating with. >> >> When you pick option A, or fork option 2, you are actually insulting >> every project that was offered to you on the basis of option 2 above. >> Because you are saying, that you are happy to take from the other OSS >> efforts but you are not happy to give back, or contribute back to >> them >> on a similarly open basis. (and "you can port it if you want it" >> doesn't >> count) >> >> The clearest example of this continues to be Monticello. >> >> When I do months of work and suffer considerably for the good of >> "everyone that wants change" of which you were one person at the >> top of >> the list. I do the work out of the goodness of my heart because I >> expect >> in the ethos of open source software that there is some give and >> take. >> "Take" because I build on the work of others that freely >> contributed to >> me, and "give" because I contribute to the furtherment of the vision >> that they started, and "take" again because I anticipate others >> continuing the good fight in the long run on everyones behalf. >> >> Given a completely open independent project, that you are invited to >> support and contribute to, on which much work has already been done >> "on >> YOUR behalf", in the direction of "YOUR goals". I consider it to be >> extremely rude and insulting, for you not to join in and further your >> own aims by contributing positively back to that project. >> >> The reason that I have no interest in participating in pharo, is not >> that I dont agree with the vision. Its the fact that I find the >> attitude >> of the pharo team (with a couple of notable exceptions) to be >> extremely >> rude. Perhaps its a cultural thing. >> >> I consider the attitude conveyed by the words "No but we have the >> right >> to choose and consider if we like it or not." to be tantamount to >> snobbery, when the option and invitation is completely open for you >> to >> participate and make it as likeable as you wish. >> >> It is perfectly possible for the following projects to be initiated >> as >> loadable modular sub-projects, developed with an ethos of >> participation >> for anyone to contribute and for anyone to use. >> >> 1. Registration for menus and UI features >> 2. Improvements to Streams >> 3. HTTPSocket >> 4. Alternatives to Changesets >> 5. Replace the changes file mechanism with something else >> 6. Atomic loading (including traits) >> 7. Replacements for Morphic, MVP >> 8. Compiler >> 9. Network. >> 10. Compression. >> 11. Files >> 12. SSpec >> 13. SUnit >> 14. Code Browsers/Tools >> >> I am seriously considering licencing Rio under something other than >> MIT, >> so that you cant use it, until you change your attitude towards your >> potential benefactors. >> > > There is one problem with Squeak, that it grew out to something > amorphous, up to the point that its really hard to tell where ends one > package/module and starts another one. > I sense the future of squeak is to make a cleaning to cut-out many > interdependencies, for getting to the point where all code is clearly > falls into separate modules. From this point, different modules can be > improved separately, but not sooner. And Pharo team is doing a lot for > making this happen. > For example, i wouldn't buy the Compression framework which fails to > work without Morphic/Etoys. And i don't think that making sure it > doesn't have such interdependencies is a rude. I think its rude to > keep thing in such state by honing the swamp which equally sucks the > energy from everyone and suppressing progress. > > You can't plant the wheat in the forest, first you have to cut down > the trees and get rid of stumps. > I think its too early to say that Pharo went too far from Squeak to > make it hard to backport any changes/improvements. I appreciate > Stephane's attempts to chop down some old rotten trees in forest to > make more space for growing a new sprouts. > > There's another aspect of same thing: a lot of Squeak code/packages > having no maintainers. > People expect that someone takes care of code which is released with > image. But let us be realistic: there is no such developers/teams who > could take a grasp of such big code base and maintain it. > And there is choice: keep using old code (mostly w/o changes), > sacrificing the potential of having a lot of code bloat, or cut it out > and then reintegrate/reimplement it in a more modular style. > >> Keith >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by StÃ©phane Ducasse

Geeeee. MC is not any project, it is our key infrastructural element. So we must control it. Because it took us a lot of energy to build our infrastructure: I remember 3.9 endeavor. >> The initiative I started on MC has a culture of participation and > collaboration, together with an ethos of being as responsive as > possible > to feedback and suggestions. When you ignore this, you insult everyone > that has put time and effort into that project. > > When you pick option A, or fork option 2, you are actually insulting > every project that was offered to you on the basis of option 2 above. > Because you are saying, that you are happy to take from the other OSS > efforts but you are not happy to give back, or contribute back to them > on a similarly open basis. (and "you can port it if you want it" > doesn't > count) this is totally wrong. You can take our code and port it back to anything you like. All our code is 100% MIT so what? Some people are also just stealing/copying our ideas but this is life. > The clearest example of this continues to be Monticello. It is not since MC is not any project, it is our key infrastructural element. So we must control it. > When I do months of work and suffer considerably for the good of > "everyone that wants change" of which you were one person at the top > of > the list. I do the work out of the goodness of my heart because I > expect > in the ethos of open source software that there is some give and take. > "Take" because I build on the work of others that freely contributed > to > me, and "give" because I contribute to the furtherment of the vision > that they started, and "take" again because I anticipate others > continuing the good fight in the long run on everyones behalf. keith are you telling me that I did not give to this community. Frankly? Are you serious? or blind? I will not make a list of what I did and I'm doing because I do not do it to enumerate it in public. > Given a completely open independent project, that you are invited to > support and contribute to, on which much work has already been done > "on > YOUR behalf", in the direction of "YOUR goals". I consider it to be > extremely rude and insulting, for you not to join in and further your > own aims by contributing positively back to that project. But of what are you talking? That you introduced traits support and atomic loading on MC and that we do not consider it? But you know several people privately asked us not to include your code. So we pay attention. When I took the time to give feedback on kernel extensions or rio this was because I considered your work and I wanted to help you improving your code. But you can also think that I was whatever you want. > The reason that I have no interest in participating in pharo, is not > that I dont agree with the vision. Its the fact that I find the > attitude > of the pharo team (with a couple of notable exceptions) to be > extremely > rude. Perhaps its a cultural thing. Do you think that I'm rude because I reply to you or when I do not reply? > I consider the attitude conveyed by the words "No but we have the > right > to choose and consider if we like it or not." to be tantamount to > snobbery, this has nothing to do with snobbery. This has to do with freedom. You as anybody else on this earth cannot get a free check with what we are doing. You saw how we worked with the settings and preference discussion with alain. I like that way of doing things, we discuss and learn from each other. This is one solution and first it should work well in pharo. Of course this may not scale for more complex projects. > when the option and invitation is completely open for you to > participate and make it as likeable as you wish. I do not ask for that. I do not see why I would have the right to come and change think in your project. > It is perfectly possible for the following projects to be initiated as > loadable modular sub-projects, developed with an ethos of > participation > for anyone to contribute and for anyone to use. > > 1. Registration for menus and UI features > 2. Improvements to Streams > 3. HTTPSocket > 4. Alternatives to Changesets > 5. Replace the changes file mechanism with something else > 6. Atomic loading (including traits) > 7. Replacements for Morphic, MVP > 8. Compiler > 9. Network. > 10. Compression. > 11. Files > 12. SSpec > 13. SUnit > 14. Code Browsers/Tools Probably. Now if we do not like the code quality we will not use that. This has nothing with snobbery this has to do with credibility on the long run. > I am seriously considering licencing Rio under something other than > MIT, > so that you cant use it, until you change your attitude towards your > potential benefactors. Do it if you need, we will just not use it. Note that some people do not like rio design, so the fact that it is MIT does not mean that we will use it. I looked at it because files are so bad in Squeak. Now I can understand your frustration but there are few stuff I can do. I do not have the time to do all the things I would like to do. Stef

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Igor Stasenko

2009/3/20 Keith Hodges <keith_hodges(a)yahoo.co.uk>: >> >> I have nearly 20 years of brain cells now if I do not die before so I >> do not want to >> spend my time on boring stuff when I can avoid it. >> > But you are throwing the baby out with the bath water. >> No but we have the right to choose and consider if we like it or not. >> >> > Actually I disagree. > > You are mixing two completely different things here. > > 1. Squeak, an open source project with lots of stake holders that may > cramp your style. > 2. Any other completely open sub-project which you are invited to > contribute to and further your aims by participating with (i.e. Monticello) > > When you forked pharo you understandably forked 1. There was no need to > fork any external projects (2) > > Every sub-project (2) has its own developers, and its own culture, and > attitude towards participation and change. When you treat other -sub > projects and their communities with the same contempt that you > understandably have towards the squeak community, you result in > insulting those communities. > > The initiative I started on MC has a culture of participation and > collaboration, together with an ethos of being as responsive as possible > to feedback and suggestions. When you ignore this, you insult everyone > that has put time and effort into that project. > > In a similar manner, any initiative or sub-project that you undertake > within pharo, can have an ethos following either of two options. > > A). Pharo team specific developed for pharo speced for pharo only. > B). A completely open sub-project which anyone is invited to support and > to further your aims by participating with. > > When you pick option A, or fork option 2, you are actually insulting > every project that was offered to you on the basis of option 2 above. > Because you are saying, that you are happy to take from the other OSS > efforts but you are not happy to give back, or contribute back to them > on a similarly open basis. (and "you can port it if you want it" doesn't > count) > > The clearest example of this continues to be Monticello. > > When I do months of work and suffer considerably for the good of > "everyone that wants change" of which you were one person at the top of > the list. I do the work out of the goodness of my heart because I expect > in the ethos of open source software that there is some give and take. > "Take" because I build on the work of others that freely contributed to > me, and "give" because I contribute to the furtherment of the vision > that they started, and "take" again because I anticipate others > continuing the good fight in the long run on everyones behalf. > > Given a completely open independent project, that you are invited to > support and contribute to, on which much work has already been done "on > YOUR behalf", in the direction of "YOUR goals". I consider it to be > extremely rude and insulting, for you not to join in and further your > own aims by contributing positively back to that project. > > The reason that I have no interest in participating in pharo, is not > that I dont agree with the vision. Its the fact that I find the attitude > of the pharo team (with a couple of notable exceptions) to be extremely > rude. Perhaps its a cultural thing. > > I consider the attitude conveyed by the words "No but we have the right > to choose and consider if we like it or not." Â to be tantamount to > snobbery, when the option and invitation is completely open for you to > participate and make it as likeable as you wish. > > It is perfectly possible for the following projects to be initiated as > loadable modular sub-projects, developed with an ethos of participation > for anyone to contribute and for anyone to use. > > 1. Registration for menus and UI features > 2. Improvements to Streams > 3. HTTPSocket > 4. Alternatives to Changesets > 5. Replace the changes file mechanism with something else > 6. Atomic loading (including traits) > 7. Replacements for Morphic, MVP > 8. Compiler > 9. Network. > 10. Compression. > 11. Files > 12. SSpec > 13. SUnit > 14. Code Browsers/Tools > > I am seriously considering licencing Rio under something other than MIT, > so that you cant use it, until you change your attitude towards your > potential benefactors. > There is one problem with Squeak, that it grew out to something amorphous, up to the point that its really hard to tell where ends one package/module and starts another one. I sense the future of squeak is to make a cleaning to cut-out many interdependencies, for getting to the point where all code is clearly falls into separate modules. From this point, different modules can be improved separately, but not sooner. And Pharo team is doing a lot for making this happen. For example, i wouldn't buy the Compression framework which fails to work without Morphic/Etoys. And i don't think that making sure it doesn't have such interdependencies is a rude. I think its rude to keep thing in such state by honing the swamp which equally sucks the energy from everyone and suppressing progress. You can't plant the wheat in the forest, first you have to cut down the trees and get rid of stumps. I think its too early to say that Pharo went too far from Squeak to make it hard to backport any changes/improvements. I appreciate Stephane's attempts to chop down some old rotten trees in forest to make more space for growing a new sprouts. There's another aspect of same thing: a lot of Squeak code/packages having no maintainers. People expect that someone takes care of code which is released with image. But let us be realistic: there is no such developers/teams who could take a grasp of such big code base and maintain it. And there is choice: keep using old code (mostly w/o changes), sacrificing the potential of having a lot of code bloat, or cut it out and then reintegrate/reimplement it in a more modular style. > Keith > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 20, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Mariano Martinez Peck

On Fri, Mar 20, 2009 at 6:06 PM, <bryce(a)kampjes.demon.co.uk> wrote: > Mariano Martinez Peck writes: > > On Wed, Mar 4, 2009 at 5:39 PM, <bryce(a)kampjes.demon.co.uk> wrote: > > > > > StÃ©phane Ducasse writes: > > > > creating a unix vm. > > > > > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > > > > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > > > > > Both have the closure bytecodes and the FreeType bitblit extensions. > > > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > > > > > > > > Good job man!. I really notice a difference in response time. For me, in > > Linux, it seems to be faster than standard VM. However, In windows, It > seems > > it doesnt work te FreeType plugin. My fonts are not nice :( any idea? > The > > same image, but with standard VM, FreeType works well. > > You'll need to get the FreeType plugin from elsewhere. I didn't > compile it this time. I mean to include it in later versions of > this VM. > Ok, I would be glad you let me know when you do this :) thanks mariano > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 20, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by bryce＠kampjes.demon.co.uk

Mariano Martinez Peck writes: > On Wed, Mar 4, 2009 at 5:39 PM, <bryce(a)kampjes.demon.co.uk> wrote: > > > StÃ©phane Ducasse writes: > > > creating a unix vm. > > > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > > > Both have the closure bytecodes and the FreeType bitblit extensions. > > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > > > > Good job man!. I really notice a difference in response time. For me, in > Linux, it seems to be faster than standard VM. However, In windows, It seems > it doesnt work te FreeType plugin. My fonts are not nice :( any idea? The > same image, but with standard VM, FreeType works well. You'll need to get the FreeType plugin from elsewhere. I didn't compile it this time. I mean to include it in later versions of this VM. Bryce

March 20, 2009