All the compilation chain and code management and manipulation tools should be
able to work on remote environment.
We already discussed and I do not have the time to explain that the design of
john was not taking into account that
we would like to be able to work with one tool on another
Now how can we make progress if we do not change Pharo?
Again, we already discussed this many times. I think Pharo is totally
off the track: Pharo should concentrate on getting a stable core and
enabling distributions on top, not on integrating as much new things
as possible.
How can
What I would like to see happening is that
- keymapping is used / integrated in Pharo 1.4
- then that OB can be loaded on top of Pharo. Remember we are not
against OB we just do not have
the knowledge to maintain it. So if lukas gets OB working for 1.4 beta
then we will
- then that OB can be loaded on top of Pharo. Remember we are not against OB
we just do not have
the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then
we will probably include in Pharo.
Now if OB is working for 1.4 only three months after 1.4 is released then
we
Lukas I really think that you are exaggerating.
Now how can we make progress if we do not change Pharo?
You were against changing RB, so how can we do remote tooling?
Alain fixed a lot of the problems of 1.3.
I think that your bad energy will damage us and I'm immensely sad.
May be a dead
Thanks for this really bad and sad message.
So you are implying that Seaside, Magritte, Pier, OB, PetitParser
will not be maintained on Pharo 1.4.
This is important for us to know that and this is a really nice stab in our
back and this will kill
a lot of the effort we build over the years.
Hello gentlemen,
Let's loosen up a bit, please :).
These are important pieces that nobody wants to see remain behind. But, before
we go on, we should first identify the root of these concerns.
@Lukas: please, could you point out what are the expected problems?
For example, all
Hi Lukas,
I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in
green.
Also, Magritte-Morph loads and seems to run well... just a small change:
replace:
PluggableListMorphOfMany
with:
PluggableListMorph ...
beMultipleSelection
(now, I want to deprecate
Hi,
On 11 Dec 2011, at 15:49, Esteban Lorenzano wrote:
Hi Lukas,
I just loaded Magritte2 into Pharo 1.4 and it loads well with all tests in
green.
Also, Magritte-Morph loads and seems to run well... just a small change:
replace:
PluggableListMorphOfMany
with:
This is important for us to know that and this is a really nice stab
in our back and this will kill a lot of the effort we build over the years.
I don't understand why you think this is a stab into your back? I have
repeated the same concerns over and over again.
Now how can we make progress
Hmm, I'll have a brief look to avoid keymapping to conflict with OB between
today and tuesday.
I don't think it makes sense to spend any time integrating it with OB (yet)
since it's removed from Pharo 1.4.
Guille
On Mon, Dec 5, 2011 at 3:32 AM, Lukas Renggli reng...@gmail.com wrote:
Ok, then
Ok, then it must be something else.
I don't know why this Keymapping thing, but it is unlikely to work
with OB if it was not written for OB. As I said, OB managed its
keybindings itself.
Lukas
On 5 December 2011 03:51, Sean P. DeNigris s...@clipperadams.com wrote:
Lukas Renggli wrote
OB.
Maybe you use the wrong browser? AFAIK, only OB implements it.
Ahh, thank you Lukas. It seems like a bug in Keymapping. What do you think,
Guillermo?
Keymapping? I don't think that would work with OB that has its own
keymapping. The problem you observe is a long standing bug: if you
don't
Lukas Renggli wrote
OB. This means, if you select the method and press Cmd+n it should
Bummer, Cmd-n with a method name selected in OB system browser still brings
up the non-chasing senders browser.
--
View this message in context:
14 matches
Mail list logo
