we should remove it or fix it. No kitchen sink in Pharo please. Stef
On Dec 14, 2012, at 6:51 PM, Pavel Krivanek wrote: > 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 <[email protected]> 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 <[email protected]> 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 > > <[email protected]>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 <[email protected]> wrote: > >> > >>> ... and please, please, please, use real names, not initials when > >> committing packages! > >>> > >>> Esteban > >>> > >>> On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <[email protected]> > >> 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 > >>>> > >>>> > >>> > >>> > >> > >> > >> > > >
