Updates: Cc: guillermopolito Comment #3 on issue 3706 by stephane...@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 Sorry guys but I will not spend my time trying to understand how to fix OB. I looked at the fixes lukas published in his repository and I do not understand why this is not in PharoOB and in addition I do not have the time to understand all the changes. So may be we should remove OB from Pharo.

Comment #5 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 Did you check out the overlay at http://source.lukas-renggli.ch/pharo12/? This is the code I wrote during the the last sprint in Bern. It contains a complete rewrite of the text editor for morphic and it fixes all the other problems I encountered in Pharo 1.2. Shout and eCompletion works perfectly for me. Being an overlay means that you should load it like this: Gofer new renggli: 'pharo12'; " this repository take precedence " renggli: 'omnibrowser'; " over the code in here " package: ... " list all the OB packages " Note, that you cannot merge the overlay packages with any other code, because they are a clean rewrite. They do not use the old interface of the text editor that was hacked in ugly ways to kind of make it work in Pharo 1.2. The packages in http://source.lukas-renggli.ch/pharo12/ are ment to replace the packages in http://source.lukas-renggli.ch/omnibrowser/ as soon as Pharo 1.2 is released.

Comment #7 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 Really? I never saw an announcement. Also http://www.pharo-project.org/pharo-download/stable downloads Pharo 1.1.1 and this is what my build-server is using.

Den 13. mars 2011 kl. 11:44 skrev pharo@googlecode.com:

Comment #8 on issue 3706 by marcus.d...@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706

The problem is that Pharo will be stable when Pharo Full will be released as stable. With Pharo Full containing OB, we have a catch 22.

Or, depending on how you choose to look at it, a classic case of muscommunication :) Maybe it's a good idea to update the "latest stable core" and "latest stable dev" links independently? Cheers, Henry

Comment #9 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 How about releasing PharoCore before PharoDev? Why do they have to be tied together?

Comment #11 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 If you only want "One Pharo" then you should also only make one "One Pharo". Looks to me like there are two Pharo developed today: one that nobody but the developers use (PharoCore) and one that doesn't work (PharoDev). Obviously there is something wrong here. The tools cannot always play catch up with the rapid changes in "PharoCore". If "PharoDev" is the only thing people care about then it should be also the platform to drive forward, the platform that is constantly kept running, the platform that sees a constant stream of bug fixes, the platform that you use at all times, ... I don't see how "PharoDev" can work otherwise.

Comment #13 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706

Yes but if the maintainer of OB does not want to maintain the 1.2 branch when we are doing 1.2 alpha then what do we do? ( I never understood your position at this level).

The thing is that I cannot (and I never could) maintain Seaside, Magritte, Pier, PetitParser and Helvetia on a (shaky) not yet released version of Pharo.

We cannot play the platform evolution (vs the core) if maintainers of the packages do not play the game.

With Seaside, Magritte and Pharo we do not want to play such games (to be able to deliver the best possible first experience). With OB and RB I don't have the time to maintain two versions (I thought that people jumped in here for Pharo 1.2, but frankly the existing code is very broken).

It works really well with Moose.

I do not agree. From what I know, many Moose users stick with old versions of Moose (and Pharo), because the new versions do not work for them.

Comment #15 on issue 3706 by tudor.gi...@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 I can understand that staying with older versions might be cheaper in the short term, and I can certainly understand that having to work on so many projects is a daunting task. However, I do not agree with your statement about Moose. We keep the latest Moose version stable since at least one year, and by pushing people to use it we made it work well. Now, of course, if people simply use Moose, they will probably stay with some older "released" version, but at least for development, we always work and push other people to work with the latest Pharo. Like that we apply the lean philosophy: if something brakes along the line, everyone stops and checks the problem. It can be painful at the beginning, but in the long run you spend less effort and get less problems. So, all in all, I think it makes a lot of sense to have development always be based on the latest Pharo, especially if the projects are so close to it (like RB or OB).

Comment #17 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 The read only access in my repository is intentional: For OmniBrowser it took me over 2 years to fix 200+ broken tests, to fix 5000+ trivial code critics issues, to move code into the right packages, to fix code in the metamodel that directly accessed the view, to fix code that violated basic architectural decisions, to add tests for behavior that nobody cared to write a test for, to remove unused code that was broken and nobody ever tried, etc. And exactly the same story repeated with the refactoring engine; and now again with OmniBrowser. Open repositories where nobody takes responsibility, where nobody reviews all code, where nobody spends a lot of time in exercising and improving the code base every day; and where nobody gives a clear direction of where to go do not work in my opinion (=> I don't want to use such code). I am very happy that PharoCore does not have a public code repository. It seems to work very well. Why would PharoDev take a different approach and have a public code repository?

Comment #19 on issue 3706 by laurent....@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 A rule may be that PharoCore integrators should have write access to all dependents repository used in Pharo. If someone refuse write access to Pharo integrators, then the package should not be in Pharo. So the dependent repository is not public, but confidence is here community managed and may resolve the stuck problem.

Comment #21 on issue 3706 by renggli: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 You have to use Shout and eCompletion from that same repository. They both had to be changed to work with the next text editors too.

Updates: Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage Comment #23 on issue 3706 by marcus.d...@gmail.com: In OB: Text in comment pane of Browser uses syntax highlighting http://code.google.com/p/pharo/issues/detail?id=3706 (No comment was entered for this change.)