Issue 3706 in pharo: In OB: Text in comment pane of Browser uses syntax highlighting

Status: Accepted
Owner: [hidden email]
Labels: Milestone-1.2-DevImage

New issue 3706 by [hidden email]: In OB: Text in comment pane of  
Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706

In OB: Text in comment pane of Browser uses syntax highlighting

... dificult to write class comments like that

Updates:
        Cc: Benjamin.VanRyseghem.Pharo

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

Benjamin, I believe you are the most knowledgeable in this area. Would you  
have time to look into it?

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

I will tak e a look, but OB is so in-understandable ...

Updates:
        Cc: guillermopolito

Comment #3 on issue 3706 by [hidden email]: 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 #4 on issue 3706 by [hidden email]: In OB: Text in comment  
pane of Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706

Weird, I'm looking at http://source.lukas-renggli.ch/omnibrowser and almost  
every last version of each package is already in PharoOB...  Stef, Can you  
point me where are you looking?

I don't have much idea of OB either.  Looking at it, all I can say is that  
the lower panel is an OBDefinitionPanel, who is filled when  
#definitionChanged: is announced with and announcement with a definition :).

And! I see in OB-Standard-Definitions some interesting definitions that we  
should look at ;).

Ben, are you available this afternoon?  Maybe we can do one or two hours of  
ob understanding/fixing by chat :).

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 #6 on issue 3706 by [hidden email]: In OB: Text in comment  
pane of Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706

lukas

1.2 is released.
Now Why we dragged beyond is because of OB. So if you wait until 1.2 is  
released and we wait to get OB released fixed for 1.2 we will never make it.
So could you publish a version in PharoOB and that somebody update the  
configurationOfOmnibrowser and that we get DONE :).

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.

Comment #8 on issue 3706 by [hidden email]: 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.

Den 13. mars 2011 kl. 11:44 skrev [hidden email]:

>
> Comment #8 on issue 3706 by [hidden email]: 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?

On Mar 13, 2011, at 12:05 PM, Henrik Johansen wrote:

:)

>
> Maybe it's a good idea to update the "latest stable core" and "latest stable dev" links independently?

Yes!!!
>
> Cheers,
> Henry

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

 From a PR point of view this would be horrible. We announce Pharo 1.2, but  
despite the big announcement, the pharo that everyone is using is not there.

Ihere should only be "Pharo". We tried to have Pharo Full (with OB and  
Refactoring tools, syntax highlighting...) be that Pharo.

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 #12 on issue 3706 by [hidden email]: 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).
We cannot play the platform evolution (vs the core) if maintainers of the  
packages do not play the game.
It works really well with Moose.
So we cannot maintain OB in alpha because we do not know OB. But this will  
be solved in the future I hope by using metacello and also making sure that  
we do not need OB.
Still the process problem stays the same.

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 #14 on issue 3706 by [hidden email]: In OB: Text in comment  
pane of Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706

I understand that you cannot maintain seaside pier magritte. Now do not  
wait that 1.2 is released to migrate to it else this is clearly a deadlock.
So what is the conclusion? That we cannot have a system where we maintain  
all the tools in alpha. So people should not wait the release version to  
migrate but the beta phase. The beta phase is done for that: you can  
migrate the tools to get ready for the rc. And else we will not ship  
external tools because we do not know how they work. I do not know and do  
not have the time to understand and maintain OB. So either other people do  
it or it dies and I cannot do much about that. This is not because we will  
have it in the core that it will change this state of fact.

Comment #15 on issue 3706 by [hidden email]: 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 #16 on issue 3706 by [hidden email]: In OB: Text in comment  
pane of Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706

Lukas, I understand you can't mantain all those tools for every release of  
pharo, squeak, moose...  Most of us can't do all that.

But there's another problem :S.  You're actually the only mantainer of OB  
and we depend on your times.  And then there is not too much people who  
knows/understands OB, and your repo is read access only...

To solve part of this, I'd like to know a little bit more about ob and this  
afternoon I'll be reading it's code.  But having your repo as read only you  
become a bottle neck...   That's why we pushed a new repo in SS...

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?