January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

On Jan 2, 2012, at 2:18 PM, Lukas Renggli wrote: >>> and fork from Pharo 1.3? I guess this is only >>> way, because with the inclusion of RB into Pharo 1.4 people that want >>> to use the original version and everything that depends on it (maybe >>> this is just me?) are locked out. >> >> Not totally true :). I could merge the code each time you publish a new version but this is tedious. >> So how do we collaborate? :). >> First I will update the RB version. > > I looked at the ConfigurationOfRefactoringEngine today, and I could > not figure out how to update it: I will look at it once we beat the event crashing bug because I hate it. BTW something I would like is - we have a core - when working on coreA, we load all the system in another core - from this other core we hack with rb and other tools the coreA - we publish changes to coreA - without having to touch core and we produce coreA without interference Because I loaded RB in Core because we crawl in mud all the time and I do everything by hand. Now the problem is that also we cannot scope the changes. > - There is now a package Refactoring-Pharo-Platform that should be > loaded together with Refactoring-Core. > > - There seems to be some code moved between the packages in Pharo 1.4, > so I don't see how the head can be merged with that code. Strange it should not. > > - There are parts for GemStone and Squeak in the configuration, that I > don't know how to deal with. Me too :) >> You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). > > Zinc is something else. Zinc is a clean replacement for HTTPSocket. It > is backward compatible by providing the old and ugly HTTPSocket > interface. > > The refactoring engine is something entirely new that you think you > might want to use in the future for remote images. Now that sounds to > me more like a research project that should be done aside, without > inflicting on the current development. Now see above this is not research. I cannot publish anything on that. > As discussed previously, I > don't think that the refactoring engine provides the right model for > this task; but should it turn out otherwise, why not adapt it at that > time? Also I don't see why Pharo would want to have remote editing > functionality in all images. Shouldn't that better be a completely > separate project? Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil trueâ¦.) so that we can bootstrap it with itself. > This leads me to the question: Did anybody ever sketch an architecture > of where Pharo should be heading to? I created a simplified one based > on my own understanding of the current proposals: http://bit.ly/vpnAf1 > (Google Docs). We should because we know where we want to go. > I think Pharo should concentrate only one the blue squares, eventually > only on the dark-blue one. Everything else should be a distribution on > top. Kernel developers might want/need to use a distribution on top of > the kernel themselves. Although it has been argued in the past that > this doesn't work, I don't see a reason why not. In any other open > source project (i.e. a Linux kernel hacker might as well use Emacs or > Gnome, even if they are not part of the kernel) people work like this, > why not in Pharo too? Probably. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

>> and fork from Pharo 1.3? I guess this is only >> way, because with the inclusion of RB into Pharo 1.4 people that want >> to use the original version and everything that depends on it (maybe >> this is just me?) are locked out. > > Not totally true :). I could merge the code each time you publish a new version but this is tedious. > So how do we collaborate? :). > First I will update the RB version. I looked at the ConfigurationOfRefactoringEngine today, and I could not figure out how to update it: - There is now a package Refactoring-Pharo-Platform that should be loaded together with Refactoring-Core. - There seems to be some code moved between the packages in Pharo 1.4, so I don't see how the head can be merged with that code. - There are parts for GemStone and Squeak in the configuration, that I don't know how to deal with. > You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). Zinc is something else. Zinc is a clean replacement for HTTPSocket. It is backward compatible by providing the old and ugly HTTPSocket interface. The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development. As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project? This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs). I think Pharo should concentrate only one the blue squares, eventually only on the dark-blue one. Everything else should be a distribution on top. Kernel developers might want/need to use a distribution on top of the kernel themselves. Although it has been argued in the past that this doesn't work, I don't see a reason why not. In any other open source project (i.e. a Linux kernel hacker might as well use Emacs or Gnome, even if they are not part of the kernel) people work like this, why not in Pharo too? Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] Image input sensors blocked

by Guido Stepken

StÃ©phane Ducasse wrote <stephane.ducasse(a)inria.fr>: > Something that we prepared since months one little step after the other is to be able to avoid polling events but to use a semaphore. > This is not use in image but can be activated using > > InputEventSensor installEventSensorFramework > > Remember that VisualWorks did that in 1998 :). > > > Now we went over the 100 of Sensor direct references in the code and fix them. We should still analyze the ones that are left around 70. > The idea is that sensor should not be invoked from Morphic since Morphic is handling VM event. So code that predates Morphic or that is outside morphic and that > implement a loop can react strangely. > So a lot of cleaning in perspective. Now on this road with fixed (not integrated yet) the raw VM event manipulation done at the border > between Morphic and none Morphic world. We are getting there. > > Now Janko I do not know. May be others will have ideas. > > Try InputEventSensor installEventSensorFramework even if I do not see why this would change something. > > I will sit with igor this afternoon to check the bug we found because some events were blocked on a waitQueue. > The cool thing is that for this bug is that we can systematically crash our image. > > Stef Happy new year! Tnx for confirming, what i have been complaining last year! :-) Btw.: Do you consider remote events while bundling images, e.g. via s2s? Should JS Smalltalk like Amber being able to run Morphic one day, it could be very interesting to use Pharo via simple Browser even in multiuser mode. I think, this design approach would give Pharo a tremendous advantage over ALL other competitors... Have a nice time hacking! Guido Stepken

Jan. 2, 2012

Re: [Pharo-project] Image input sensors blocked

by Levente Uzonyi

On Mon, 2 Jan 2012, Janko MivÅ¡ek wrote: > S, StÃ©phane Ducasse piÅ¡e: > >>> There is opportunity for someone of you to finally catch this bug! My >>> image is blocked again, but Aida is still working and my backdoor too :) >>> So, I can run any code on image. 'Sensor startUp' didn't help, what can >>> yet try? Last action was OSProcess related, can this be a problem, some >>> sempahore related stuff? > >> Can you tell us which version you use? > > Pharo 1.3 13299 > >> We faced a strange behavior related with event processing last week with igor. >> May be tomorrow we will investigate what is happening. >> But this is not related to OSProcess since we do not use it nor load it. >> For us, we could plug a completely new way to generate events, everything worked well >> HandMorph was using our new events, but a pop up would freeze to death the system. > > Ok, I'll wait one more day with this image blocked, then I want to > continue with my work :) > > Any idea which command yet to try to unblock it? Maybe some restart of > all input sensor stuff? Why don't you ask the VM to print the smalltalk call stacks? Levente > > Janko > > >> >> Stef >> >> >>> >>> Even better, contact me privately to get access to this image via web >>> and debug it by yourself. >>> >>> Best regards >>> Janko >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

On Jan 2, 2012, at 11:47 AM, Stefan Marr wrote: > > On 02 Jan 2012, at 11:30, StÃ©phane Ducasse wrote: >>> My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time. >> >> this is what we are doing :) >> Because there are parts we refrained ourselves to even look at them :) > > No, you are not focusing at all. You do everything and you want everything. > > You want a full blown Pharo distribution with great dev tools to enable businesses. > You want bootstrapping. > You want better event handling. > You want a vector canvas. > You want better infrastructure like the Ring. > You want RPackage. > You want remote debugging. > You want ... Stefan wanting and doing are two different things. Wanting let us plan. Now you can believe that we do not plan. You can also check what we are committing in the changes and see that this is not always what we want. > I guess if I would dig through the discussions I could make up a list with at least 20 items. > > That is not what I would call focused. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Jan. 2, 2012

Re: [Pharo-project] Image input sensors blocked

by StÃ©phane Ducasse

Something that we prepared since months one little step after the other is to be able to avoid polling events but to use a semaphore. This is not use in image but can be activated using InputEventSensor installEventSensorFramework Remember that VisualWorks did that in 1998 :). Now we went over the 100 of Sensor direct references in the code and fix them. We should still analyze the ones that are left around 70. The idea is that sensor should not be invoked from Morphic since Morphic is handling VM event. So code that predates Morphic or that is outside morphic and that implement a loop can react strangely. So a lot of cleaning in perspective. Now on this road with fixed (not integrated yet) the raw VM event manipulation done at the border between Morphic and none Morphic world. We are getting there. Now Janko I do not know. May be others will have ideas. Try InputEventSensor installEventSensorFramework even if I do not see why this would change something. I will sit with igor this afternoon to check the bug we found because some events were blocked on a waitQueue. The cool thing is that for this bug is that we can systematically crash our image. Stef On Jan 2, 2012, at 11:33 AM, Janko MivÅ¡ek wrote: > S, StÃ©phane Ducasse piÅ¡e: > >>> There is opportunity for someone of you to finally catch this bug! My >>> image is blocked again, but Aida is still working and my backdoor too :) >>> So, I can run any code on image. 'Sensor startUp' didn't help, what can >>> yet try? Last action was OSProcess related, can this be a problem, some >>> sempahore related stuff? > >> Can you tell us which version you use? > > Pharo 1.3 13299 > >> We faced a strange behavior related with event processing last week with igor. >> May be tomorrow we will investigate what is happening. >> But this is not related to OSProcess since we do not use it nor load it. >> For us, we could plug a completely new way to generate events, everything worked well >> HandMorph was using our new events, but a pop up would freeze to death the system. > > Ok, I'll wait one more day with this image blocked, then I want to > continue with my work :) > > Any idea which command yet to try to unblock it? Maybe some restart of > all input sensor stuff? > > Janko > > >> >> Stef >> >> >>> >>> Even better, contact me privately to get access to this image via web >>> and debug it by yourself. >>> >>> Best regards >>> Janko >>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Stefan Marr

On 02 Jan 2012, at 11:30, StÃ©phane Ducasse wrote: >> My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time. > > this is what we are doing :) > Because there are parts we refrained ourselves to even look at them :) No, you are not focusing at all. You do everything and you want everything. You want a full blown Pharo distribution with great dev tools to enable businesses. You want bootstrapping. You want better event handling. You want a vector canvas. You want better infrastructure like the Ring. You want RPackage. You want remote debugging. You want ... I guess if I would dig through the discussions I could make up a list with at least 20 items. That is not what I would call focused. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 2, 2012

Re: [Pharo-project] Image input sensors blocked

by Janko MivÅ¡ek

S, StÃ©phane Ducasse piÅ¡e: >> There is opportunity for someone of you to finally catch this bug! My >> image is blocked again, but Aida is still working and my backdoor too :) >> So, I can run any code on image. 'Sensor startUp' didn't help, what can >> yet try? Last action was OSProcess related, can this be a problem, some >> sempahore related stuff? > Can you tell us which version you use? Pharo 1.3 13299 > We faced a strange behavior related with event processing last week with igor. > May be tomorrow we will investigate what is happening. > But this is not related to OSProcess since we do not use it nor load it. > For us, we could plug a completely new way to generate events, everything worked well > HandMorph was using our new events, but a pop up would freeze to death the system. Ok, I'll wait one more day with this image blocked, then I want to continue with my work :) Any idea which command yet to try to unblock it? Maybe some restart of all input sensor stuff? Janko > > Stef > > >> >> Even better, contact me privately to get access to this image via web >> and debug it by yourself. >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

On Jan 2, 2012, at 11:11 AM, Stefan Marr wrote: > > > On 02 Jan 2012, at 10:53, StÃ©phane Ducasse wrote: >> We do not want to strip an image in the long but if to make sure that we can make progress we have to >> add stuff to the image we will. I added RB because we were thinking that I could have time to work on RPackage that we could >> load Nautilus but I got trapped by new duties. Still see my other mails. > > You guys have the same argument again and again. > > Stef, to me it looks like you have conflicting goals with Pharo. > You want to make everything better, and all at the same time. > > My post-docs would tell me: stop, take a step back, see the bigger picture, and focus on one thing at a time. this is what we are doing :) Because there are parts we refrained ourselves to even look at them :) Stef

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

On Jan 2, 2012, at 11:08 AM, Lukas Renggli wrote: >> please read this mail until the end before replying :) > > Done. > >>> Moreover, every generic framework included with the core will sooner >>> or later introduce dependencies from random core packages. >> >> Why do you say random. Of course people make mistakes and are not perfect. But we will fix it. > > I am saying "random" because people (including me) will start to use > whatever the auto-completion is offering. And we all know that the > proposals of the auto-completion are rather random at times. You can > see that in Pharo, Seaside, Pier, Magritte, ... over time packages > tend to blend. Whatever you add now, you cannot easily remove > tomorrow. I know. This is why I worked on bootstrap during holidays and cleaning event. >> You see I read and spent time to answer your kind of mail. Because you are still my friend >> and because I had a lot of fun with you and I'm sure that you could have fun with us. > > Thank you. > > Now this makes me wonder how I should behave if I am not allowed to > say why I think that Pharo is on the wrong track? say it! we are not against this kind of feedback. You know well that I hate politically correctness. But think positive. For example for Announcement: - raise the issue - motivate the point - send code I'm 100% sure that igor will value your code and criticisms. We are all for improving but not for bad words and the system will get better. We are not autists and we value feedback even when it is negative. We listen what you are saying believe me. > You want me to shut up no just use other words. Yesterday I was in a library reading books on positive communication and I'm sure that we can all improve, me the first :). > and fork from Pharo 1.3? I guess this is only > way, because with the inclusion of RB into Pharo 1.4 people that want > to use the original version and everything that depends on it (maybe > this is just me?) are locked out. Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version. You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). But I would not do that for RB. We can unload RB from 1.4 without problem but I would like to have a - calm - non conflictual - reasonable - with clear argument (because I checked the BrowserEnvironment new location and I imagine that plugin an environment instead is not something that is done in 15 min) roadmap so that WE (YOU and US) can build a roadmap together. I do not think it is much. I'm even ready to be calm :) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 2, 2012