[Pharo-project] Handle Close Event in Image - necessary for 1.0?
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
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 <astares@gmx.de> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+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 <astares@gmx.de> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <astares@gmx.de> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 06/04/2010 17:48, Stéphane Ducasse < stephane.ducasse@inria.fr > 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
On Apr 7, 2010, at 5:13 AM, csrabak@bol.com.br wrote:
Em 06/04/2010 17:48, Stéphane Ducasse < stephane.ducasse@inria.fr > 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Henrik Johansen -
Michael Roberts -
Stéphane Ducasse -
Torsten Bergmann