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

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

by Janko MivÅ¡ek

Hi Stef, StÃ©phane Ducasse pravi: > did we do a fork of swazoo? > I mean in pharo? > I was not aware of that. No, not on Pharo and not by you the Pharo guys. Fork named Hyper was done on VW and Gemstone. Sorry for misunderstanding, I made a general example to show and to recommend, what to do in such case. Best regards Janko > > Stef > > On Mar 21, 2009, at 10:24 AM, Janko MivÅ¡ek wrote: > >> Guys, >> >> Let me say few words from my experience, because such fork actually >> happened to Swazoo, which maintainer I am. So, was I insulted? Well, I >> was surely not happy, but insulted? No! >> >> I took that as a competitive pressure to be even better with main >> Swazoo >> line. To prove therefore with deeds that our branch is the best. >> >> So please, don't mix competition with insulting. Use the competitive >> pressure (anger if you wish) to ride on it and be even better! Prove >> yourself with your work! >> >> Community is wise enough to be able to choose the best contender at >> the >> end. If you are chosen, celebrate, if you are not, analyze situation >> and >> be better next time, but don't give up, and specially don't feel >> insulted! >> >> Best regards >> Janko >> >> >> >> Keith Hodges pravi: >>>> 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 :) >>>> >>>> >>> Igor, >>> >>> I am not understanding your logic. >>> >>> You appear to be saying that if package X has got current >>> maintainers, >>> then it is not rude to make your own version of Package X. And that >>> if >>> you fork a package that has no maintainer then you will be in >>> trouble. >>> >>> I am saying the opposite - that if you fork a package that has got >>> current maintainers, you >>> >>> a) insult the maintainers, >>> b) you undermine the progress that they may have made, >>> c) you undermine any efforts thay have made to build a team and >>> communication around that project. >>> d) you prevent future progress by the existing team >>> e) you make extra work for the exisiting team because you dont >>> communicate with them and they are forced to play catch up to you all >>> the time >>> f) you send out the message that volunteering to maintain any part of >>> the kernel is a hapless task, and will ultimately be a waste of >>> time and >>> effort. >>> >>> Keith >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> -- >> Janko MivÅ¡ek >> Svetovalec za informatiko >> Eranova d.o.o. >> Ljubljana, Slovenija >> www.eranova.si >> tel: 01 514 22 55 >> faks: 01 514 22 56 >> gsm: 031 674 565 >> >> _______________________________________________ >> 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 > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

March 21, 2009

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

by Igor Stasenko

2009/3/21 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > Janko MivÅ¡ek wrote: >> Guys, >> >> Let me say few words from my experience, because such fork actually >> happened to Swazoo, which maintainer I am. So, was I insulted? Well, I >> was surely not happy, but insulted? No! >> >> I took that as a competitive pressure to be even better with main Swazoo >> line. To prove therefore with deeds that our branch is the best. >> >> So please, don't mix competition with insulting. Use the competitive >> pressure (anger if you wish) to ride on it and be even better! Prove >> yourself with your work! >> >> Community is wise enough to be able to choose the best contender at the >> end. If you are chosen, celebrate, if you are not, analyze situation and >> be better next time, but don't give up, and specially don't feel insulted! >> >> Best regards >> Janko >> >> > Again its not about the technical choice, its about the philosophical > principle. Let me make this clear. > > "I spent a year of my time on tools and ideas that may benefit all, only > only only only only only only if all choose in principle to use those > ideas." (we sort out the technical details in the end). > > Check through my last email, and look at what it means to the community > if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said > ideas, its not just limited to code). > > 1. You/I will have to manage a separate project JUST for pharo. The > new(1 year old) PackageInfo-Base would allow you to export. > MyPackage.pharo from your main distribution. > > 2. You will have to manage a separate test suite JUST for Pharo. The > SUnit-improved is designed to allow tests to be marked and categorised > as to what should work where. This scheme should also apply to other > testing frameworks as they are integrated (SSpec). > > 3. You will have to manage a separate load script/universe for your > pharo code, and users will not have a place to tweak their load scripts > for pharo. Thus to support pharo you are forced to actually try loading > your code in pharo regularly. Remember pharo is a moving target, so you > will have to test it every month/week or so. IF your code ever fails to > load you will get a black mark of incompetence from the community, so > you had better keep on top of it. Meanwhile the squeak users can upload > their feedback of what is needed to make your package work in squeak > into the load scripts in Sake/Packages. Then on your next iteration you > can go and pick up the required changes, at your leisure. > > If you wonder why I keep banging on about this, I have over 40 packages > that I maintain both publically and as part of my work. I have gone to > an extreme amount of effort to try and minimise the pain, and the pharo > guys are ignoring the IDEAS and the code, and therefore making > unnecessary work for everyone. > Keithy, what you proposing is change the development process pattern which people used to do for a years now, to a new, not yet clearly evaluated paradigms. I think you should be aware that forcing people to change their development style will meet a certain oppression. From your side, as an evangelist of a new approach, it very important to show how easy & painless the new process is going comparing to old one. Write tutorials , show simple 1.2.3. steps etc etc. Blaming the people that they keep using old development techniques is not the way to go. I think that Stephane clearly understands a different problems of software development , packaging, maintaining & distributing. What he maybe not clearly sees is a big win from using approach proposed by you. I hope you will find a meeting points to make interchange between Squeak & Pharo (and other forks) be painless, fun and productive. > 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 21, 2009

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

by StÃ©phane Ducasse

janko did we do a fork of swazoo? I mean in pharo? I was not aware of that. Stef On Mar 21, 2009, at 10:24 AM, Janko MivÅ¡ek wrote: > Guys, > > Let me say few words from my experience, because such fork actually > happened to Swazoo, which maintainer I am. So, was I insulted? Well, I > was surely not happy, but insulted? No! > > I took that as a competitive pressure to be even better with main > Swazoo > line. To prove therefore with deeds that our branch is the best. > > So please, don't mix competition with insulting. Use the competitive > pressure (anger if you wish) to ride on it and be even better! Prove > yourself with your work! > > Community is wise enough to be able to choose the best contender at > the > end. If you are chosen, celebrate, if you are not, analyze situation > and > be better next time, but don't give up, and specially don't feel > insulted! > > Best regards > Janko > > > > Keith Hodges pravi: >>> 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 :) >>> >>> >> >> Igor, >> >> I am not understanding your logic. >> >> You appear to be saying that if package X has got current >> maintainers, >> then it is not rude to make your own version of Package X. And that >> if >> you fork a package that has no maintainer then you will be in >> trouble. >> >> I am saying the opposite - that if you fork a package that has got >> current maintainers, you >> >> a) insult the maintainers, >> b) you undermine the progress that they may have made, >> c) you undermine any efforts thay have made to build a team and >> communication around that project. >> d) you prevent future progress by the existing team >> e) you make extra work for the exisiting team because you dont >> communicate with them and they are forced to play catch up to you all >> the time >> f) you send out the message that volunteering to maintain any part of >> the kernel is a hapless task, and will ultimately be a waste of >> time and >> effort. >> >> Keith >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2009

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

by Keith Hodges

Janko MivÅ¡ek wrote: > Guys, > > Let me say few words from my experience, because such fork actually > happened to Swazoo, which maintainer I am. So, was I insulted? Well, I > was surely not happy, but insulted? No! > > I took that as a competitive pressure to be even better with main Swazoo > line. To prove therefore with deeds that our branch is the best. > > So please, don't mix competition with insulting. Use the competitive > pressure (anger if you wish) to ride on it and be even better! Prove > yourself with your work! > > Community is wise enough to be able to choose the best contender at the > end. If you are chosen, celebrate, if you are not, analyze situation and > be better next time, but don't give up, and specially don't feel insulted! > > Best regards > Janko > > Again its not about the technical choice, its about the philosophical principle. Let me make this clear. "I spent a year of my time on tools and ideas that may benefit all, only only only only only only only if all choose in principle to use those ideas." (we sort out the technical details in the end). Check through my last email, and look at what it means to the community if Pharo doesnt adopt MC1.5 and SUnit improved ideas (notice I said ideas, its not just limited to code). 1. You/I will have to manage a separate project JUST for pharo. The new(1 year old) PackageInfo-Base would allow you to export. MyPackage.pharo from your main distribution. 2. You will have to manage a separate test suite JUST for Pharo. The SUnit-improved is designed to allow tests to be marked and categorised as to what should work where. This scheme should also apply to other testing frameworks as they are integrated (SSpec). 3. You will have to manage a separate load script/universe for your pharo code, and users will not have a place to tweak their load scripts for pharo. Thus to support pharo you are forced to actually try loading your code in pharo regularly. Remember pharo is a moving target, so you will have to test it every month/week or so. IF your code ever fails to load you will get a black mark of incompetence from the community, so you had better keep on top of it. Meanwhile the squeak users can upload their feedback of what is needed to make your package work in squeak into the load scripts in Sake/Packages. Then on your next iteration you can go and pick up the required changes, at your leisure. If you wonder why I keep banging on about this, I have over 40 packages that I maintain both publically and as part of my work. I have gone to an extreme amount of effort to try and minimise the pain, and the pharo guys are ignoring the IDEAS and the code, and therefore making unnecessary work for everyone. Keith

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by Igor Stasenko

2009/3/21 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: > >> Wait, i proposing nearly same: Have an event source which produces >> (non-morphic) event objects and InputSensor. >> I just want to know where Announcements takes part of it, or should be >> postpone that for a next step? > > What I did while exploring an alternative UI framework was to use the > rewrite and add an Announcer as a second listener. "Interested parties" > could then subscribe to event announcements. The raw input events are first > converted to first class event objects before submitting them to the > announcer. Right, but here we're talking about doing such conversion much more earlier (at event source object), so then event sensor already deals with first class event objects. I want to know, if such scheme (which i described in first post) is plausible. > As discussed earlier this allows for having a completely separate UI running > without any overlaps to morphic. Tweak always had the problem of still being > tied into the morphic event processing, the combination of the sensor > rewrite and announcers avoid this. > Right, that's why we need a separate set of classes (i called them KernelXXXEvent) which representing an events which came from VM and not tied to Morphic. > I meant to make this stuff available a long time ago, partly as an effort to > try to avoid duplicate effort with the Alain's Miro framework, but kept > distracted by other things. > Will put it a bit higher on my list :-) > Let me know, if you need some help. At least i can send you a proto implementation of KernelXXXEvent classes. I'm also started writing it, but then other things drawn my attention :) > Michael > > -- Best regards, Igor Stasenko AKA sig.

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by Michael Rueger

Igor Stasenko wrote: > Wait, i proposing nearly same: Have an event source which produces > (non-morphic) event objects and InputSensor. > I just want to know where Announcements takes part of it, or should be > postpone that for a next step? What I did while exploring an alternative UI framework was to use the rewrite and add an Announcer as a second listener. "Interested parties" could then subscribe to event announcements. The raw input events are first converted to first class event objects before submitting them to the announcer. As discussed earlier this allows for having a completely separate UI running without any overlaps to morphic. Tweak always had the problem of still being tied into the morphic event processing, the combination of the sensor rewrite and announcers avoid this. I meant to make this stuff available a long time ago, partly as an effort to try to avoid duplicate effort with the Alain's Miro framework, but kept distracted by other things. Will put it a bit higher on my list :-) Michael

March 21, 2009

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

by Janko MivÅ¡ek

Guys, Let me say few words from my experience, because such fork actually happened to Swazoo, which maintainer I am. So, was I insulted? Well, I was surely not happy, but insulted? No! I took that as a competitive pressure to be even better with main Swazoo line. To prove therefore with deeds that our branch is the best. So please, don't mix competition with insulting. Use the competitive pressure (anger if you wish) to ride on it and be even better! Prove yourself with your work! Community is wise enough to be able to choose the best contender at the end. If you are chosen, celebrate, if you are not, analyze situation and be better next time, but don't give up, and specially don't feel insulted! Best regards Janko Keith Hodges pravi: >> 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 :) >> >> > > Igor, > > I am not understanding your logic. > > You appear to be saying that if package X has got current maintainers, > then it is not rude to make your own version of Package X. And that if > you fork a package that has no maintainer then you will be in trouble. > > I am saying the opposite - that if you fork a package that has got > current maintainers, you > > a) insult the maintainers, > b) you undermine the progress that they may have made, > c) you undermine any efforts thay have made to build a team and > communication around that project. > d) you prevent future progress by the existing team > e) you make extra work for the exisiting team because you dont > communicate with them and they are forced to play catch up to you all > the time > f) you send out the message that volunteering to maintain any part of > the kernel is a hapless task, and will ultimately be a waste of time and > effort. > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

March 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Rewriting an Input/EventSensor code

by Igor Stasenko

2009/3/21 Andreas Raab <andreas.raab(a)gmx.de>: > Igor Stasenko wrote: >> >> Recently , we discussed it with Andreas, and had an idea to integrate >> this with Announcement framework (and Announcement will become a core >> package). > > Actually, Jecel propsed the combination. > >> Here is my vision , how things should look like: > > [... big snip ...] > >> Michael, Andreas, i'd like to hear your comments and remarks, as well >> as any others are wellcome. > > It's too much to do all that in one go around. What I would propose is to > start simple by having an event source which maps from raw event buffers to > some kind of (non-morphic) event objects and have InputSensor be a client of > that. I believe that is a straightforward extension of the work that has > already been done. > Wait, i proposing nearly same: Have an event source which produces (non-morphic) event objects and InputSensor. I just want to know where Announcements takes part of it, or should be postpone that for a next step? > Cheers, > Â - Andreas > -- Best regards, Igor Stasenko AKA sig.

March 21, 2009

Re: [Pharo-project] Pharo a VMs

by Alexandre Bergel

All VM on which Squeak run may be safely used with Pharo. This may change in the future with the introduction of closures. Cheers, Alexandre On 20 Mar 2009, at 21:59, Mariano Martinez Peck wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 21, 2009

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

by StÃ©phane Ducasse

>> But you never even understood what the reason behind kernel-extension > was, you criticised it and refused to use anything that depended on > it, > because it wasn't perfectly what you wanted, and it contained method > overrides. This was feedback and explanation for YOU of why we did not include it. > That was the whole point, it was supposed to contain method > overrides. If you put all of the method overrides for the kernel in > one > place, then multiple overlapping method overrides from different > packages do not occur, there will be no conflicts. > You didn't really > participate in that discussion, you simply said things along the > line of > Kernel-Extensions includes Null therefore we dont like it, full stop. No I gave you feedback. Who else by the way? **I** sat with damien and we together read the code and sent it. > When I stopped using Kernel-Extensions, and started using changesets > to > publish exactly the same code without method overrides, all of a > sudden > the same code became magically acceptable! You might be interested to > know that more than 80-90% of what was Kernel-Extensions has already > been added to pharo, so there wasnt so much wrong with it after all. Not that much. I checked. >> > Its got nothing to do with replying or not. Yes it is because I can ignore you completely too. > Its all to do with your team having the expertise to get SystemEditor > working with Traits, for the good of all, but instead you spend time > and > effort forking MC, for the good of yourselves, and in the process > trash > a lot of time and effort expended for your benefit. We are not doing that. We are running after time. > Its to do with your team forking SUnit unnecessarily etc etc It is not my team, it is people with busy agenda not having the time to look at other packages >>> 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, >> You saw how we worked with the settings and preference discussion >> with >> alain. >> > So Alain is external to your team? He had the courtesy of discussing > the > preferences ideas with the wider community, and for that I thanked > him, > and added him to my "non-rude" list. Good! >> > Hang on... this is a list of projects, most of which dont have any > code > yet, and you are talking about rejecting stuff that doesnt meet your > standards! That's exactly what I mean. No I just warn you so that you do not get frustrated again. > If you spec out a project, plan it, and "contribute" to the team that > works on it, then it will meet your standards by definition. Therefore > there is no need to prejudice anything with such comments as "if > 'their' work its not up to 'our' standards". Exact! Keith hold on a moment. you are spining on yourself. We have a lot of deadlines, a lot of administration, I do pharo on my free time often the evening, I have no time to code what I want for my research, I fight all the time to get money, I have a huge pile of unfinished todos. So we all have more or less the same. So my contributions to something will be nearly null. Do you think that lukas can do more than seaside pier, phd, paper and books? Do you think that alex can do more than a start up, writing paper, fixing our code base on moose? > That's my whole point, you get the standards you want by participating > in the process, not by looking down your nose at the contributions > being > hacked by some poor old stressed out full time carer. But with the time constraints I have give feedback is the only thing I can do right now. Else I would have wrote another rio and lot more. >>> 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 >> > These "some people", are more folks who have never sent me a single > email discussing the design. And by the way Rio has had three complete > redesigns since it was first written, incorporating various feedback > and > ideas. > > Thankfully I have "some emails" from "some people" who like it I imagine that too. > > > Keith > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2009