[Pharo-project] who is "dfgs"?
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
... 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
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
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
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
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
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 <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
participants (4)
-
Camillo Bruni -
Esteban Lorenzano -
Pavel Krivanek -
Stéphane Ducasse