And are we allowed to remove features? ;-) On the other hand, we may look at it as fix of an umimplemented call. But we can let it there because I doubt we will be able to remove all unimplemented calls in 2.0 - even in the Pharo Kernel.

-- Pavel

On Fri, Dec 14, 2012 at 1:47 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I know I will use it (though I am not allowed to add more features in 2.0 ;))
so it will be 3.0. Anyways I will add a fully-fledged command-line REPL.

so it's up to you, I can add it again anyway

On 2012-12-14, at 05:07, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
> So what about to remove VTermInputDriver from the image? �And add it in
> future with working handler.
>
> -- Pavel
>
> On Thu, Dec 13, 2012 at 5:24 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
>
>> haha, so these are commits from the pre-full-name aera.
>> Anyway, dfgs was a student in bern ;), but since I put the code in the
>> system I should be the owner ;).
>>
>> VTerm*Driver abstract over the terminal, and yes they are crucial for any
>> decent terminal support.
>> - provide colors for terminal
>> - provide cursor navigation
>> - provide terminal capability access
>>
>> due to lack of NativeBoost in the main image,
>> so far I could not use tcap, but that will change.
>>
>> So far I did not port the input handler (but there is a fully fledged
>> smalltalk-based readline implementation ready).
>> Once that is in the image there should be no more undefined calls.
>>
>> And using #perform: is a very bad habit in my opinion.
>> It breaks all tools, since you make everything implicit (and quite slow as
>> well)..
>>
>> On 2012-12-11, at 09:05, Esteban Lorenzano <estebanlm@gmail.com> wrote:
>>
>>> ... and please, please, please, use real names, not initials when
>> committing packages!
>>>
>>> Esteban
>>>
>>> On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek@gmail.com>
>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to ask who has the initials "dfgs". And I have a question
>> for him/her. The VTermInputDriver initialization methods generate a lot of
>> unimplemented calls because they expect a handler object with protocol that
>> is not defined in the image. Do we need the VTerm classes at all? Can you
>> provide an abstract handler class? Or what about to switch this calls to
>> perform:/perform:with: form.
>>>>
>>>> Cheers,
>>>> -- Pavel
>>>>
>>>>
>>>
>>>
>>
>>
>>