On 10 Oct 2009, at 22:50, Schwab,Wilhelm K wrote:

Stef,

Rio and non-core packages reminds me of #newForWin32, which is missing a #new, so it answers the class instead of an instance. This breaks the installation on Windows, and it also leads to a broken image on Windows if it is not corrected on another OS.

I _think_ I reported it.

Bill

You would be using an ancient version of Rio, I think I zeroed out the latest of the old packages to prevent people loading them. Both Universes and Sake/Packages have the correct definitions as to which package to load. Keith

On Oct 12, 2009, at 10:53 AM, Adrian Lienhard wrote:

This is a good list. I would like to add:

- evaluate Metacello as a package management system for Pharo (Dale announced Metacello beta on the Seaside-dev mailing list yesterday) - simple testserver (load updates from stream, run test, report results by mail) - remove Accuny from image and use NiceFonts in Pharo-core

- review closure fixes and make all tests green (I'm working on this) Excellent!

I added the list to http://code.google.com/p/pharo/wiki/PharoSprint

I made the page editable by public. No need to login, just click on edit at the top right of the page. Lukas 2009/10/12 Oscar Nierstrasz <oscar@iam.unibe.ch>:

I made a wiki page:

http://scg.unibe.ch/wiki/events/PharoSprintLille09

It would be nice if people who are planning to attend have write access to the wiki. Please ask me or Lukas Renggli if you need to be added as a wiki user.

- on

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Lukas Renggli http://www.lukas-renggli.ch

Yes I want to cut some dirty cycles Network could be a first start and after the ugly morphic ;-} On Oct 12, 2009, at 3:01 PM, Simon Denier wrote:

Also during the sprint, me and Jannik would like to run an experiment running eDSM (a matrix visualization of dependencies) to refactor some package dependencies (heads up for those who will attend WCRE this week, eDSM is on schedule Wednesday :)). For people interested (we will contact or you can contact us), the experiment will take around 3 hours and you get to do what you want to do in Pharo, but with our tool :)

On 10 oct. 2009, at 10:01, Stéphane Ducasse wrote:

...

Hi guys

I would like to have several kinds of tasks so that people can pick up Now let me know if you have other points

- fixing stuff for 1.0 - integrating pending for 1.1 - OB related UI - fixing more elaborated points for 1.1 - package structure - improving the system (smalllint?) - Popup discard - TextEditor from Squeak/CUIS - ToolBuilder changes - checking squeak fixes - Preparing release candidate - fixing _ - free fonts - Dreaming about the future - filesystem? Rio/ - newcompiler - true package - management of noncore packages - browsers - release/integration process

BTW what is costing me most of my time is cleaning the inbox. Can we script that because moving these files is a pain.

Syeg

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mike is it related to the testServer publihsed on squeaksource? Because ESUG will also sponsor a summer talk project on the topics. So if we could join forces it would be great. For the server this is not clear yet. Internally we have our server that we could use but we have to check the security. I'm waiting that marcus arrives to check that with him and damien. Stef On Oct 12, 2009, at 6:25 PM, Michael Roberts wrote:

hi I can't make the sprint but I have the basic core of a test server that runs the tests and updates the wiki. I just need to be able to spawn svn shell commands which I'm stuck on due to osprocess crash. I can post the code in task forces if someone is interested.

To turn it into a server we need a host and some scripts to kick it off. Do we have any hardware as a group? cheers mike

On Monday, October 12, 2009, Stéphane Ducasse <stephane.ducasse@inria.fr

...

wrote: Yes I want to cut some dirty cycles Network could be a first start and after the ugly morphic ;-} On Oct 12, 2009, at 3:01 PM, Simon Denier wrote:

...

Also during the sprint, me and Jannik would like to run an experiment running eDSM (a matrix visualization of dependencies) to refactor some package dependencies (heads up for those who will attend WCRE this week, eDSM is on schedule Wednesday :)). For people interested (we will contact or you can contact us), the experiment will take around 3 hours and you get to do what you want to do in Pharo, but with our tool :)

On 10 oct. 2009, at 10:01, Stéphane Ducasse wrote:

...

Hi guys

I would like to have several kinds of tasks so that people can pick up Now let me know if you have other points

- fixing stuff for 1.0 - integrating pending for 1.1 - OB related UI - fixing more elaborated points for 1.1 - package structure - improving the system (smalllint?) - Popup discard - TextEditor from Squeak/CUIS - ToolBuilder changes - checking squeak fixes - Preparing release candidate - fixing _ - free fonts - Dreaming about the future - filesystem? Rio/ - newcompiler - true package - management of noncore packages - browsers - release/integration process

BTW what is costing me most of my time is cleaning the inbox. Can we script that because moving these files is a pain.

Syeg

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

RT @tinybuddha: "Do not give your attention to what others do or fail to do; give it to what you do or fail to do." ~Dhammapada ----- "keith" <keith_hodges@yahoo.co.uk> wrote: | On 12 Oct 2009, at 17:45, Stéphane Ducasse wrote: | | > Mike is it related to the testServer publihsed on squeaksource? | > Because ESUG will also sponsor a summer talk project on the topics. | > So if we could join forces it would be great. | > | > For the server this is not clear yet. Internally we have our server | > that we could use but | > we have to check the security. | > | > I'm waiting that marcus arrives to check that with him and damien. | > | > Stef | | Why why why why why is compete more attractive than contributing. | | Let me explain.... | | Step 1. We would like a test server. | Step 2. Is anyone working on this already? | Step 3. Would anyone like to collaborate to specify and work on a test | server? | | Bob is already written it just needs configuring, TestReporter is | already written, | and has been available for 3 years or more. | | The same thing is happening again and again and again. | | Why did anyone even start working on Metacello when Sake/Packages was | | already there a year before hand. | | Why are the steps above not the default way of working for the | community? It is beyond incredulity. | | Keith | | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef, Adrian no it's not related to anything published on SqueakSource. i'll put something in task forces later in the week with some comments. It's not a server, just the core code that runs the tests I put on the wiki. Given the wiki can be updated with svn that's the route i propose. We can also update the issue tracker by marking files in a special way. i haven't tried that yet but could be useful in the future. I think we can auto-create issues, or at least auto-close them. the code is literally only a few lines here & there. I don't think it needs to be that clever. i would prefer to see all energy going into fixing bugs! You'll need to integrate it with something that loads the updates, but I would see that taking more shape once the package system and process of pharo is more mature. what lukas describes sounds interesting. I need OSProcess to spawn svn, unless we have a lighter weight way of doing that? cheers Mike

I think it makes sense to open a ticket in our tracker, yes. Especially since OSProcess is an important package for us. Adrian On Oct 12, 2009, at 23:19 , Michael Roberts wrote:

Adrian, sorry i did not read your mail carefully ;-)

no we don't have an issue on the tracker yet. whilst it is an external package I think it is important enough we maintain compatibility. Is it reasonable for us to track on our tracker? I would say so, but in the past sometimes i think we have closed issues for not being pharo directly.

cheers Mike

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

How long the community will support the deliberate decision of not answering to a major contributor? How do you expect contribution of large open source companies to this project avoiding political or technical conflicts (or both)? Focusing only on bug-driven development and ingoring valid questions with a kind of systematic corporative silence is not the way to go. And if the managerial staff decide to continue ignoring, sooner or later you would have two problems to resolve: The unsolved pending questions plus the management of the emergence of social subsystems (if the number of contributors increases) without enough coordinators for pivots, because of the limited size of contributors for a niche technology like Smalltalk. Censorship of uninformed newcomers is common and an implicit norm, censorship of a known member is disgusting. Such attitude is limiting involvement and participation in the community, because implicitly define clear roles which affects the discussion space and group dynamics. Finally, I do not want a holy war here, I just want responses without personal attacks and without quoting out of context fallacies. Cheers, Hernán 2009/10/12 keith <keith_hodges@yahoo.co.uk>:

On 12 Oct 2009, at 17:45, Stéphane Ducasse wrote:

...

Mike is it related to the testServer publihsed on squeaksource? Because ESUG will also sponsor a summer talk project on the topics. So if we could join forces it would be great.

For the server this is not clear yet. Internally we have our server that we could use but we have to check the security.

I'm waiting that marcus arrives to check that with him and damien.

Stef

Why why why why why is compete more attractive than contributing.

Let me explain....

Step 1. We would like a test server. Step 2. Is anyone working on this already? Step 3. Would anyone like to collaborate to specify and work on a test server?

Bob is already written it just needs configuring, TestReporter is already written, and has been available for 3 years or more.

The same thing is happening again and again and again.

Why did anyone even start working on Metacello when Sake/Packages was already there a year before hand.

Why are the steps above not the default way of working for the community? It is beyond incredulity.

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/10/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Hernan

...

How long the community will support the deliberate decision of not answering to a major contributor? How do you expect contribution of large open source companies to this project avoiding political or technical conflicts (or both)?

this is not that we do not reply. This is that keith is always saying the same. Now I do not have to power to say to people not to develop their own stuff and also people have the freedom not to understand        - sake        - now you can ask jannik for example: we started to write something on installer and sake        but we got confused on sake (may be with a physical meeting at esug this would make a lot of point clearer)        - not to like some part of the installer        - not to contribute        - not have the time to understand something        - prefer to build thier own even if this is limited

       - For example I tried to check the SUnitextensions and I could not find them.

Did you see me not integrating something in Pharo Did you see me not mentioning rio? Even if they are some points I do not like.

Please, do not misunderstand me, you're doing a terrific job with Pharo. My concerns were more about the political stuff.

...

Focusing only on bug-driven development and ingoring valid questions with a kind of systematic corporative silence is not the way to go. And if the managerial staff decide to continue ignoring, sooner or later you would have two problems to resolve: The unsolved pending questions plus the management of the emergence of social subsystems (if the number of contributors increases) without enough coordinators for pivots, because of the limited size of contributors for a niche technology like Smalltalk.

Censorship of uninformed newcomers is common and an implicit norm, censorship of a known member is disgusting.

sorry hernan but I cannot let you say that in this mailing-list. Did we ever not reply to a newbie email?

I expressed myself bad, that claim for newcomers is a general rule in other open source projects (not Pharo fortunately), when they enter a mailing list, they do not know the project's history and start "spamming" with already answered topics.

...

Such attitude is limiting involvement and participation in the community, because implicitly define clear roles which affects the discussion space and group dynamics.

Finally, I do not want a holy war here, I just want responses without personal attacks and without quoting out of context fallacies.

Are my answer satisfactory? Now I have a question:        - do you use sake personnally?        - do you have positive experience?        - did you check the code? what is your feedback?        - is there tests?        - what do you think about task definition pros and cons?

You can replace Sake but RIO, Sunit extensions (if you find it) Please do it.

We've used Monticello Configurations in our application. It was enough for our needs. However I've invested time in understanding the Installer/Sake/Packages triad (I have problems with the documentation). I've annotated this in my personal swiki for future use. In a more generic level and this is somewhat out of topic (sorry), I'm mostly a user of Pharo, but what I perceive is competition between some tools. Competition is good... sometimes. What I mean is: There are some developers which support innovation activities? Good. There are some developers which support stabilization over a robust development platform? Fantastic. What I suspect sometimes is a mixing of both scenarios, and from a consumption point of view it could be negative, because some people do not want to hear about alternatives at all, namely : Monticello, ChangeSets/ChangeSorter, CVSTProject (?), SqueakARchive, Installer, ScriptLoader, Sake, Universes, etc. And the relations and complex interactions between them. It is time consuming to study each source code management tool (plus the latest ones), and I know professional busy programmers which simply do not have the time to make a review, they don't want to invest in training. If the community could vote for a tool, I think that would clarify: -The preferred source code management tool (based on true production experience with Smalltalk). -The interest in having just one main tool for SCC (or at least the perception people have with CPAN or dpkg or rpm). -The interest in alternatives or additional functionality. -The previous experience with some other tools, this way you can see if there's a profile from users of CVS, etc. Well, yet another idea. Best regards, Hernán

So far in our group people succeeded to make TestServer running for Moose and if they come and tell me that sake is better/easier/ then we will probably switch

Now I asked the summertalk student to also consider evaluating Sake and we will see.

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

You can replace Sake but RIO, Sunit extensions (if you find it)

So you are the lead on pharo and you have never used universes? Sorry but using I cant find SUnitExtensions when the package is and has always been called "SUnit-improved" as an excuse is is totally ridiculous.

Are my answer satisfactory? Now I have a question: - do you use sake personnally? - do you have positive experience? - did you check the code? what is your feedback? - is there tests? - what do you think about task definition pros and cons?

I have no idea what you mean by this question. This is all backwards. Your questions are all demonstrating the old pharo code snobbery which really isn't relevant to the argument at all. The whole point is to have a plan and a vision that people work towards so that we end up with a coherent solution that does what we and the community need. If something is not quite up to scratch then you/me/anyone can join in and contribute to bring it up to speed. Code snobs are welcome and helpful, if they contribute, rather than compete. Rejecting things just because its a few tests short is simply demonstrating a lack of interest in the overall concept. The repositories are open and have always been open for you to contribute to. Let me outline the basics of the plan... I cant say whether these things work in pharo or not. 0. Installer = for bootstrapping stuff anywhere including kernel minimal gui-less images. (gofer whatever that is, is not for kernel images, so you havent got anything to fulfill this role) If you were committed to not undermining the vision of "the DSM for installing things", you would develop gofer as InstallerGofer available via Installer gofer addPackage: 'PackageA'; latest; quietly; install. Then you would have the same functionality, but you would be contributing to the vision rather than setting up as competition from the outset. You would also have additional benefits such as tools for loading Gofer in all forks, see 0a below. 0a InstallerScripts for bootstrapping stuff with scripts that may differ in different forks. (ScriptLoader is a pharo only hack - so you haven't got anything to fulfil this role either) 1. Monticello, Monticello Configurations, and PackageInfo = the same in all forks, with all forks merged so that we can move MC forward with Atomic loading and binary loading. 2. SUnit - same in all forks, with categorisation of tests, tagging as to what works where. 3. LPF for bootstrapping and loading all of the above in all forks. 4. Sake (vision = minimal support for tasks with dependencies) It doesnt matter if you dont like a single bytecode of the sake code, the principle is "a package that gives the minimal support for make like task graphs". If you happen to be a make/rake expert, then enter the dialog and tell me what I am doing wrong, we could start again from scratch if you like, I don't care. But please DONT compete for the sake of it. 5. Sake/Packages (minimal gui-less package manager available in all forks) defining what works where. Again, if you don't like it, enter the dialog, and help, don't judge from afar. Sake/Packages may not be perfect, but it has done better than any other previous squeak dependency manager. The API is better than Metacello, and its easier to use, and more versatile. So, if you don't deliver something similar to this plan, AND deliver it in all forks with equivalent functionality, then whatever you do undermines this vison for everyone. This is exactly what has happened. The vision has been undermined to the point of being hounded out of existence. This email is the last death throe. Hence the reason that I have been speaking up, repeatedly, the vision is now pretty much completely undermined and almost gone, because it is unsustainable. It is unsustainable because the leaders in our community will not put any commitment to any visions other than their own, and those for the most part only exist in their own heads. (i.e. when you or andreas sit down to decide what bug to fix, or what you are going to refactor there is no published detailed plan you are working to) You apparently loaded MC1.5 once, (whereas I have been using it for 2 years) and decided that it left lots of loose ends, the reason was because you didnt unload the previous version of MC correctly. Your version of collaborating with people on a plan, is to poke around in squeaksource on your own, load a package that you think is the right one, and when it doesnt work, simply tell everyone that you couldnt find it. Perhaps you are still in the dark ages, when we didnt have irc or a package manager for squeak which understood dependencies. All you have to do in an LPF image is Installer install: 'Packages'. and you would be able to load SUnit-improved without a problem. We have had all of this stuff working for all of the time I have been trying to persuade you to use it. Keith

If you can post the code and maybe some comments on how to use it, that would be great. Maybe we can do some testing and investigation into the problem during the sprint.

Do we have an issue for the OSProcess problem or has it been discussed before?

We'll discuss where to host this server. We have several options there.

We are using Mason from <http://source.wiresong.ca/mc> to build Seaside images. We don't have a server setup yet, but it also works locally. Mason is a very flexible system, it has infrastructure to build images, build SAR archives, build documentation, load Monticello 1 and 2 packages, load Metacello configurations, run tests, run code critics and execute arbitrary scripts, etc. The OB and MC2 distributions are built using Mason for example: <http://www.wiresong.ca/static/releases/>. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

On 12 Oct 2009, at 22:28, keith wrote:

On 12 Oct 2009, at 22:08, Lukas Renggli wrote:

...

...

If you can post the code and maybe some comments on how to use it, that would be great. Maybe we can do some testing and investigation into the problem during the sprint.

Do we have an issue for the OSProcess problem or has it been discussed before?

We'll discuss where to host this server. We have several options there.

We are using Mason from <http://source.wiresong.ca/mc> to build Seaside images. We don't have a server setup yet, but it also works locally.

Mason is a very flexible system, it has infrastructure to build images, build SAR archives, build documentation, load Monticello 1 and 2 packages, load Metacello configurations, run tests, run code critics and execute arbitrary scripts, etc. The OB and MC2 distributions are built using Mason for example: <http://www.wiresong.ca/static/releases/>.

Lukas

Absolutely incredible.

Keith

translated = "oh look its Sake" Keith