Handle Close Event in Image - necessary for 1.0?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Handle Close Event in Image - necessary for 1.0?

Torsten Bergmann
>So...which is the working Windows VM we should use for 1.0 ? the one before
>4 version.

Last one before this change was introduced was the 3.11.8 Squeak VM
which I adapted for Pharo. You can download it from:

https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip


However I still believe that fixing this in 1.0 would not only
be a plus - it will also prevent questions regarding this
new problem since people WILL use newer VM's after the
first 1.0 release of Pharo and then instantly step into the problem!


And it is not a Windows specific problem as Stef thinks it is.

Bert requested John today (see [1]) to change the default for Mac too ...
so if you upgrade your Mac VM for whatever reason (maybe to do
1.1 work or since you need a newer VM for a commercial project)
then you will step into this with the 1.0 image.

Guess what people think when Pharo tries to bring Squeak to a
better quality level and then would not be able to close the
system as usual after upgrading to a newer and better VM.

But maybe my expectations for a 1.0 release are too high...

Bye
T.



[1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Michael Roberts-2
1.0 will be a maintained release. I suggest we push out 1.0 and
schedule this fix for the first maintenance release. otherwise we will
never get it out the door. from a process point of view, there will
always be another important bug to fix.

thanks,
Mike

On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <[hidden email]> wrote:

>>So...which is the working Windows VM we should use for 1.0 ? the one before
>>4 version.
>
> Last one before this change was introduced was the 3.11.8 Squeak VM
> which I adapted for Pharo. You can download it from:
>
> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip
>
>
> However I still believe that fixing this in 1.0 would not only
> be a plus - it will also prevent questions regarding this
> new problem since people WILL use newer VM's after the
> first 1.0 release of Pharo and then instantly step into the problem!
>
>
> And it is not a Windows specific problem as Stef thinks it is.
>
> Bert requested John today (see [1]) to change the default for Mac too ...
> so if you upgrade your Mac VM for whatever reason (maybe to do
> 1.1 work or since you need a newer VM for a commercial project)
> then you will step into this with the 1.0 image.
>
> Guess what people think when Pharo tries to bring Squeak to a
> better quality level and then would not be able to close the
> system as usual after upgrading to a newer and better VM.
>
> But maybe my expectations for a 1.0 release are too high...
>
> Bye
> T.
>
>
>
> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse
+1

On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote:

> 1.0 will be a maintained release. I suggest we push out 1.0 and
> schedule this fix for the first maintenance release. otherwise we will
> never get it out the door. from a process point of view, there will
> always be another important bug to fix.
>
> thanks,
> Mike
>
> On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <[hidden email]> wrote:
>>> So...which is the working Windows VM we should use for 1.0 ? the one before
>>> 4 version.
>>
>> Last one before this change was introduced was the 3.11.8 Squeak VM
>> which I adapted for Pharo. You can download it from:
>>
>> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip
>>
>>
>> However I still believe that fixing this in 1.0 would not only
>> be a plus - it will also prevent questions regarding this
>> new problem since people WILL use newer VM's after the
>> first 1.0 release of Pharo and then instantly step into the problem!
>>
>>
>> And it is not a Windows specific problem as Stef thinks it is.
>>
>> Bert requested John today (see [1]) to change the default for Mac too ...
>> so if you upgrade your Mac VM for whatever reason (maybe to do
>> 1.1 work or since you need a newer VM for a commercial project)
>> then you will step into this with the 1.0 image.
>>
>> Guess what people think when Pharo tries to bring Squeak to a
>> better quality level and then would not be able to close the
>> system as usual after upgrading to a newer and better VM.
>>
>> But maybe my expectations for a 1.0 release are too high...
>>
>> Bye
>> T.
>>
>>
>>
>> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html
>>
>> --
>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Adrian Lienhard
Yes, there will certainly be other important fixes, which – together with the new close logic – are going into a 1.0.1 maintenance release.

Cheers,
Adrian

On Apr 6, 2010, at 22:40 , Stéphane Ducasse wrote:

> +1
>
> On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote:
>
>> 1.0 will be a maintained release. I suggest we push out 1.0 and
>> schedule this fix for the first maintenance release. otherwise we will
>> never get it out the door. from a process point of view, there will
>> always be another important bug to fix.
>>
>> thanks,
>> Mike
>>
>> On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <[hidden email]> wrote:
>>>> So...which is the working Windows VM we should use for 1.0 ? the one before
>>>> 4 version.
>>>
>>> Last one before this change was introduced was the 3.11.8 Squeak VM
>>> which I adapted for Pharo. You can download it from:
>>>
>>> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip
>>>
>>>
>>> However I still believe that fixing this in 1.0 would not only
>>> be a plus - it will also prevent questions regarding this
>>> new problem since people WILL use newer VM's after the
>>> first 1.0 release of Pharo and then instantly step into the problem!
>>>
>>>
>>> And it is not a Windows specific problem as Stef thinks it is.
>>>
>>> Bert requested John today (see [1]) to change the default for Mac too ...
>>> so if you upgrade your Mac VM for whatever reason (maybe to do
>>> 1.1 work or since you need a newer VM for a commercial project)
>>> then you will step into this with the 1.0 image.
>>>
>>> Guess what people think when Pharo tries to bring Squeak to a
>>> better quality level and then would not be able to close the
>>> system as usual after upgrading to a newer and better VM.
>>>
>>> But maybe my expectations for a 1.0 release are too high...
>>>
>>> Bye
>>> T.
>>>
>>>
>>>
>>> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html
>>>
>>> --
>>> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse
In reply to this post by Torsten Bergmann
Torsten I appreciate your effort but we can only do what can be done in the time
we can allocate to do a task if you see what I mean.
I cannot test on windows because we do not have a windows machine. We are doing an incredible
amount of work but we cannot do more than it is reasonable to do.

Then in freeze time this is freeze time. we will try to get shorter iteration cycles and this is not
by delaying 1.0 that we are making progress on that front.

And this is not by saying that pharo "will be less quality than" ... more or less that it helps.

So 1.0 will be like it can. And if people bash us this is ok too.
You remember a while ago one guy asked who is ready to pay 10 Euros per month to have a
better pharo and we got 6 persons....

> However I still believe that fixing this in 1.0 would not only
> be a plus - it will also prevent questions regarding this
> new problem since people WILL use newer VM's after the
> first 1.0 release of Pharo and then instantly step into the problem!
>
>
> And it is not a Windows specific problem as Stef thinks it is.
>
> Bert requested John today (see [1]) to change the default for Mac too ...

TODAY. Imagine I was painting my house.... and this evening this would have to be fixed?
When is the last time that a bug that annoys you on windows got fixed in one day?
because for me on mac so far it took months.

> so if you upgrade your Mac VM for whatever reason (maybe to do
> 1.1 work or since you need a newer VM for a commercial project)
> then you will step into this with the 1.0 image.

Yes and since you are a good pharoers you will know and you will understand
and help us and help yourself.


> Guess what people think when Pharo tries to bring Squeak to a
> better quality level and then would not be able to close the
> system as usual after upgrading to a newer and better VM.
>
> But maybe my expectations for a 1.0 release are too high...
>
> Bye
> T.
>
>
>
> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

csrabak
Em 06/04/2010 17:48, Stéphane Ducasse < [hidden email] > escreveu:

> Torsten I appreciate your effort but we can only do what can be done
> in the time we can allocate to do  a task if you see what I mean.  I
> cannot test on windows because we  do not have a windows machine. We
> are doing an incredible amount of work but we cannot do more than it
> is reasonable to do.
>  Then in freeze time this is freeze time. we will try to get shorter
> iteration cycles and this is not  by delaying 1.0 that we are making
> progress on that front.
>  And this  is not by saying  that pharo "will be  less quality than"
> ... more or less that it helps.
>  So 1.0 will be  like it can. And if people bash  us this is ok too.
> You remember a while ago one guy  asked who is ready to pay 10 Euros
> per month to have a better pharo and we got 6 persons....

BTW, did you find a means of collecting the contributions?

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
>
> TODAY. Imagine I was painting my house.... and this evening this would have to be fixed?
> When is the last time that a bug that annoys you on windows got fixed in one day?
> because for me on mac so far it took months.

John
BTW nothing with your vm but with mac osX  like the fonts getting unreadable in mail reader. I thought that they would issue a fix quite fast but no
probably focusing on itunes crap.

Stef




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse
In reply to this post by csrabak

On Apr 7, 2010, at 5:13 AM, [hidden email] wrote:

> Em 06/04/2010 17:48, Stéphane Ducasse < [hidden email] > escreveu:
>
>> Torsten I appreciate your effort but we can only do what can be done
>> in the time we can allocate to do  a task if you see what I mean.  I
>> cannot test on windows because we  do not have a windows machine. We
>> are doing an incredible amount of work but we cannot do more than it
>> is reasonable to do.
>> Then in freeze time this is freeze time. we will try to get shorter
>> iteration cycles and this is not  by delaying 1.0 that we are making
>> progress on that front.
>> And this  is not by saying  that pharo "will be  less quality than"
>> ... more or less that it helps.
>> So 1.0 will be  like it can. And if people bash  us this is ok too.
>> You remember a while ago one guy  asked who is ready to pay 10 Euros
>> per month to have a better pharo and we got 6 persons....
>
> BTW, did you find a means of collecting the contributions?

No we should go to the "prefecture" and check how to create an association.


>
> --
> Cesar Rabak
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Henrik Sperre Johansen
In reply to this post by Stéphane Ducasse

On Apr 6, 2010, at 10:48 19PM, Stéphane Ducasse wrote:

> Torsten I appreciate your effort but we can only do what can be done in the time
> we can allocate to do a task if you see what I mean.
> I cannot test on windows because we do not have a windows machine. We are doing an incredible
> amount of work but we cannot do more than it is reasonable to do.
>
> Then in freeze time this is freeze time. we will try to get shorter iteration cycles and this is not
> by delaying 1.0 that we are making progress on that front.
>
> And this is not by saying that pharo "will be less quality than" ... more or less that it helps.
>
> So 1.0 will be like it can. And if people bash us this is ok too.
> You remember a while ago one guy asked who is ready to pay 10 Euros per month to have a
> better pharo and we got 6 persons....
>
>> However I still believe that fixing this in 1.0 would not only
>> be a plus - it will also prevent questions regarding this
>> new problem since people WILL use newer VM's after the
>> first 1.0 release of Pharo and then instantly step into the problem!
>>
>>
>> And it is not a Windows specific problem as Stef thinks it is.
>>
>> Bert requested John today (see [1]) to change the default for Mac too ...
>
> TODAY. Imagine I was painting my house.... and this evening this would have to be fixed?
> When is the last time that a bug that annoys you on windows got fixed in one day?
> because for me on mac so far it took months.
>
>> so if you upgrade your Mac VM for whatever reason (maybe to do
>> 1.1 work or since you need a newer VM for a commercial project)
>> then you will step into this with the 1.0 image.
>
> Yes and since you are a good pharoers you will know and you will understand
> and help us and help yourself.

I've put some slices based on the .cs in the inbox, one for 1.0 and one for 1.1.  (quitSession was moved to WorldState in 1.1, and some other minor diffs)
I've also tested and can confirm they work with the newest Windows VM, not sure about the behavior on Linux, which apparently was updated as well.


Cheers,
Henry



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse
Thanks Henrik
this is something I understand. I will integrate that for 1.1

Now adrian is polishing 1.0 so we will see what will happen.

Stef


On Apr 7, 2010, at 10:35 AM, Henrik Johansen wrote:

>
> On Apr 6, 2010, at 10:48 19PM, Stéphane Ducasse wrote:
>
>> Torsten I appreciate your effort but we can only do what can be done in the time
>> we can allocate to do a task if you see what I mean.
>> I cannot test on windows because we do not have a windows machine. We are doing an incredible
>> amount of work but we cannot do more than it is reasonable to do.
>>
>> Then in freeze time this is freeze time. we will try to get shorter iteration cycles and this is not
>> by delaying 1.0 that we are making progress on that front.
>>
>> And this is not by saying that pharo "will be less quality than" ... more or less that it helps.
>>
>> So 1.0 will be like it can. And if people bash us this is ok too.
>> You remember a while ago one guy asked who is ready to pay 10 Euros per month to have a
>> better pharo and we got 6 persons....
>>
>>> However I still believe that fixing this in 1.0 would not only
>>> be a plus - it will also prevent questions regarding this
>>> new problem since people WILL use newer VM's after the
>>> first 1.0 release of Pharo and then instantly step into the problem!
>>>
>>>
>>> And it is not a Windows specific problem as Stef thinks it is.
>>>
>>> Bert requested John today (see [1]) to change the default for Mac too ...
>>
>> TODAY. Imagine I was painting my house.... and this evening this would have to be fixed?
>> When is the last time that a bug that annoys you on windows got fixed in one day?
>> because for me on mac so far it took months.
>>
>>> so if you upgrade your Mac VM for whatever reason (maybe to do
>>> 1.1 work or since you need a newer VM for a commercial project)
>>> then you will step into this with the 1.0 image.
>>
>> Yes and since you are a good pharoers you will know and you will understand
>> and help us and help yourself.
>
> I've put some slices based on the .cs in the inbox, one for 1.0 and one for 1.1.  (quitSession was moved to WorldState in 1.1, and some other minor diffs)
> I've also tested and can confirm they work with the newest Windows VM, not sure about the behavior on Linux, which apparently was updated as well.
>
>
> Cheers,
> Henry
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Henrik Sperre Johansen

On Apr 7, 2010, at 12:38 25PM, Stéphane Ducasse wrote:

> Thanks Henrik
> this is something I understand. I will integrate that for 1.1

Yes, there's some new stuff there which won't work well if we ever move towards multi-window support, but the entire event-handling will have to be rewritten in that case anyways, so I didn't think too much of it.
I'd say the first step in any case would be moving Event-object generation out of the HandMorph class... (did MVC make its own kind of events?)

Probably a good idea to switch to something reacting to new events in the queue rather than polling it too, if we intend to ever switch the inputEventPollingFetcher for the actual InputEventFetcher some time in the future.
Though,  InputEventSensor installEventSensorFramework seems borken on Windows now (eventbuffer overflows with 4.0.2 VM ), and incredibly slow to signal semaphore (albeit not loosing any events anymore in 1.1) on a Mac 4.2.4 VM. On the 5.X series, it works like a dream though :D

Cheers,
Henry


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Handle Close Event in Image - necessary for 1.0?

Stéphane Ducasse

On Apr 7, 2010, at 5:54 PM, Henrik Johansen wrote:

>
> On Apr 7, 2010, at 12:38 25PM, Stéphane Ducasse wrote:
>
>> Thanks Henrik
>> this is something I understand. I will integrate that for 1.1
>
> Yes, there's some new stuff there which won't work well if we ever move towards multi-window support, but the entire event-handling will have to be rewritten in that case anyways, so I didn't think too much of it.
> I'd say the first step in any case would be moving Event-object generation out of the HandMorph class... (did MVC make its own kind of events?)
>
> Probably a good idea to switch to something reacting to new events in the queue rather than polling it too, if we intend to ever switch the inputEventPollingFetcher for the actual InputEventFetcher some time in the future.

Yes I think that we should move to not use a polling of event.

> Though,  InputEventSensor installEventSensorFramework seems borken on Windows now (eventbuffer overflows with 4.0.2 VM ), and incredibly slow to signal semaphore (albeit not loosing any events anymore in 1.1) on a Mac 4.2.4 VM. On the 5.X series, it works like a dream though :D
>
> Cheers,
> Henry
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project