- Pharo-dev - lists.pharo.org

Re: [Pharo-project] glamour and pharo

by Tudor Girba

Hi Stef, We are in the new year now, so the arguments can begin :). On 31 Dec 2011, at 23:33, StÃ©phane Ducasse wrote: > I looked at it and First, these seem to be a totally different set of arguments :). That is good. > I do not like the magic of the block and arguments There really is little magic. In fact, it is about the same as the magic of Morphic calling selectors with arguments. > and the scripting aspects > Veronica showed me that she does not use long scripts. I do not understand. You do not have to use long scripts unless you want them. If you look in the current code of most browsers, you will see that most methods are pretty small. So, this is not really an argument, either. > Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas > and I'm still not convinced. I am not sure what you are referring to. > Now if people want to load glamour perfect. Now I do not have any spare cycles > to maintain it. My plate is full. I do not understand. You do not have to maintain it. It is already maintained. > For now I would like to have a good way to build and reuse Morphic widgets not to > create another layer on top. Sure. Go ahead. This is most welcome. Please understand that this debate started because you said it's sad that Alex would choose to work on top of Glamour for the Metacello browser. I simply would like to understand why you think it's so. To me, there does not seem to be a strong argument. Doru > Stef > > On Dec 31, 2011, at 5:13 PM, Tudor Girba wrote: > >> Hi, >> >> Let's take this on the Pharo mailing list. >> >> I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). >> >> And I also think your analysis is not accurate. Here is why (I apologize for the long list): >> >> 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. >> >> 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. >> >> 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. >> >> 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. >> >> 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. >> >> 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. >> >> 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. >> >> >> I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. >> >> So, before dismissing Glamour, perhaps it would be useful to actually look into it. >> >> Cheers, >> Doru >> >> >>> On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. >>> >>> Do you think so? >>> I do not think that we can base our infrastructure on something that only one person understand and can modify. >>> You will tell that this is the same for Morphic but this is not true. >>> >>> Stef >>> >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> > > -- www.tudorgirba.com "Every thing should have the right to be different."

Jan. 1, 2012

Re: [Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by Sean P. DeNigris

The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns: SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'" There does not seem to be a way to get the vm executable name. Sean -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 1, 2012

Re: [Pharo-project] Happy new year!

by Tudor Girba

Happy new year! :) Doru On 31 Dec 2011, at 22:59, StÃ©phane Ducasse wrote: > Hi guys > > I wish you good health (because at the end this is the most important and when we are going well we do not > estimate how cool it is). > Then lot of fun and business. > > Stef -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Jan. 1, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

On 31 December 2011 23:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I looked at it and > Â Â Â Â Â Â Â Â I do not like the magic of the block and arguments > Â Â Â Â Â Â Â Â and the scripting aspects > Veronica showed me that she does not use long scripts. > Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas > and I'm still not convinced. > > Now if people want to load glamour perfect. Now I do not have any spare cycles > to maintain it. My plate is full. For now I would like to have a good way to build and reuse Morphic widgets not to > create another layer on top. +1000 Pharo should concentrate on the infrastructure, so that load what they want: Glamour, OmniBrowser, ...; Seaside, Iliad, ...; or whatever the next big thing is. Happy new year, Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 31, 2011

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

I looked at it and I do not like the magic of the block and arguments and the scripting aspects Veronica showed me that she does not use long scripts. Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas and I'm still not convinced. Now if people want to load glamour perfect. Now I do not have any spare cycles to maintain it. My plate is full. For now I would like to have a good way to build and reuse Morphic widgets not to create another layer on top. Stef On Dec 31, 2011, at 5:13 PM, Tudor Girba wrote: > Hi, > > Let's take this on the Pharo mailing list. > > I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). > > And I also think your analysis is not accurate. Here is why (I apologize for the long list): > > 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. > > 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. > > 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. > > 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. > > 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. > > 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. > > 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. > > > I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. > > So, before dismissing Glamour, perhaps it would be useful to actually look into it. > > Cheers, > Doru > > >> On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: >> >>> Hi Stef, >>> >>> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. >> >> Do you think so? >> I do not think that we can base our infrastructure on something that only one person understand and can modify. >> You will tell that this is the same for Morphic but this is not true. >> >> Stef >> > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > >

Dec. 31, 2011

Re: [Pharo-project] Where did the Promise go?

by Lukas Renggli

I don't think that there was ever such a class in Pharo. Lukas On 31 December 2011 14:18, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi: > > Was the Promise class removed from the system for cleaning, and because it was not used? > Or was there another reason for not having it in its classic form? > > Thanks > 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 > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 31, 2011

Re: [Pharo-project] Where did the Promise go?

by StÃ©phane Ducasse

Probably because it was not well integrated and no users. Now if you have a good implementation we can package it. To me Object>>futureSend: aSelector at: deltaMSecs args: args "Send a message deltaSeconds into the future (some implementations may requires 'deltaMSecs' to be zero). Answers a Promise that will be resolved at some time in the future. See comment in class FutureNode." ^Project current future: self send: aSelector at: deltaMSecs args: args. Is not something I really understand. I do not see why a project would have to do anything with promise but I'm probably a bit dull. Stef On Dec 31, 2011, at 2:18 PM, Stefan Marr wrote: > Hi: > > Was the Promise class removed from the system for cleaning, and because it was not used? > Or was there another reason for not having it in its classic form? > > Thanks > 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 > >

Dec. 31, 2011

[Pharo-project] Happy new year!

by StÃ©phane Ducasse

Hi guys I wish you good health (because at the end this is the most important and when we are going well we do not estimate how cool it is). Then lot of fun and business. Stef

Dec. 31, 2011

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Tudor Girba

Happy new year to you, too, Lukas! Doru On 31 Dec 2011, at 18:58, Lukas Renggli wrote: > Let's take this on the Pharo mailing list. > > I do think that Seaside should be considered for being part of the > Pharo infrastructure. At least the Core and the basic HTML rendering > (i.e., without JQuery, Magritte and Pier). > > And I also think your analysis is not accurate. Here is why (I > apologize for the long list): > > 1. Seaside is quite well documented. There are two books describing > it. There are a tone of examples documenting all sorts of features. > There comments are not as good as they could be, but there are lots of > comments. > > 2. It is quite well tested. This part can be improved, but the core > has some 80% coverage. > > 3. I am not the only one that knows how to mingle with it. To give > some examples, more than 30 people helped fixing some intricate bugs > directly in the core (http://www.seaside.st/community/contributors) I > would also mention that countless student projects are on > Squeaksource. So, maybe it's not that difficult. > > 4. The core is quite stable since more than 10 years. There were > changes, but they were mostly related to new features and bug fixes. > > 5. The main point of using this infrastructure is not to replace > Morphic, and to empower more people to build more applications. For > example, the Seaside counter has less than 5 lines of code in total > (and one instance variable only). This is really tiny for the amount > of things it offers (you can even step through it with a debugger). > And it is highly extensible (subclassing), too. > > 6. It's actually not that large: the core has 152 classes, and if you > consider all the other packages, helper classes and specialized > frameworks (but without the example code), you get some 1162 classes. > > 7. But, perhaps the most important part is that there have been > literally thousands of applications built on top of it. Not all of > them are useful now, but they were when they were built. And it seems > that people can build one quite fast without much knowledge of the web > either. That is the whole point of this infrastructure. Esteban even > used it for building commercial applications. I built a couple, too. > The whole of Pier (SmallWiki) is now using this infrastructure, too. > > I am not saying that Seaside is perfect. There are quite a couple of > things I would like to enhance (for example, the AJAX ideas from Reef, > or the components from ExtJS), but it has proved to be quite solid > until now. > > So, before dismissing Seaside, perhaps it would be useful to actually > look into it. > > Cheers, > Lukas > > PS: If you don't like Seaside, I might have some other additions to > pharo core ready that fit as well into the template ... > > On 31 December 2011 17:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> Let's take this on the Pharo mailing list. >> >> I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). >> >> And I also think your analysis is not accurate. Here is why (I apologize for the long list): >> >> 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. >> >> 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. >> >> 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. >> >> 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. >> >> 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. >> >> 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. >> >> 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. >> >> >> I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. >> >> So, before dismissing Glamour, perhaps it would be useful to actually look into it. >> >> Cheers, >> Doru >> >> >>> On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. >>> >>> Do you think so? >>> I do not think that we can base our infrastructure on something that only one person understand and can modify. >>> You will tell that this is the same for Morphic but this is not true. >>> >>> Stef >>> >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Dec. 31, 2011

Re: [Pharo-project] seaside and pharo (was: glamour and pharo)

by Janko MivÅ¡ek

Ok guys, would you rather stop that today, it is the last day od the year! Having such tone today is not a good sign for a new year of Pharo. In any case, Happy New Year to all Pharoers and as much cooperation as possible in 2012, for a common goal, not selfish interests! Best regards Janko S, Lukas Renggli piÅ¡e: > Let's take this on the Pharo mailing list. > > I do think that Seaside should be considered for being part of the > Pharo infrastructure. At least the Core and the basic HTML rendering > (i.e., without JQuery, Magritte and Pier). > > And I also think your analysis is not accurate. Here is why (I > apologize for the long list): > > 1. Seaside is quite well documented. There are two books describing > it. There are a tone of examples documenting all sorts of features. > There comments are not as good as they could be, but there are lots of > comments. > > 2. It is quite well tested. This part can be improved, but the core > has some 80% coverage. > > 3. I am not the only one that knows how to mingle with it. To give > some examples, more than 30 people helped fixing some intricate bugs > directly in the core (http://www.seaside.st/community/contributors) I > would also mention that countless student projects are on > Squeaksource. So, maybe it's not that difficult. > > 4. The core is quite stable since more than 10 years. There were > changes, but they were mostly related to new features and bug fixes. > > 5. The main point of using this infrastructure is not to replace > Morphic, and to empower more people to build more applications. For > example, the Seaside counter has less than 5 lines of code in total > (and one instance variable only). This is really tiny for the amount > of things it offers (you can even step through it with a debugger). > And it is highly extensible (subclassing), too. > > 6. It's actually not that large: the core has 152 classes, and if you > consider all the other packages, helper classes and specialized > frameworks (but without the example code), you get some 1162 classes. > > 7. But, perhaps the most important part is that there have been > literally thousands of applications built on top of it. Not all of > them are useful now, but they were when they were built. And it seems > that people can build one quite fast without much knowledge of the web > either. That is the whole point of this infrastructure. Esteban even > used it for building commercial applications. I built a couple, too. > The whole of Pier (SmallWiki) is now using this infrastructure, too. > > I am not saying that Seaside is perfect. There are quite a couple of > things I would like to enhance (for example, the AJAX ideas from Reef, > or the components from ExtJS), but it has proved to be quite solid > until now. > > So, before dismissing Seaside, perhaps it would be useful to actually > look into it. > > Cheers, > Lukas > > PS: If you don't like Seaside, I might have some other additions to > pharo core ready that fit as well into the template ... > > On 31 December 2011 17:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> Let's take this on the Pharo mailing list. >> >> I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). >> >> And I also think your analysis is not accurate. Here is why (I apologize for the long list): >> >> 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. >> >> 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. >> >> 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. >> >> 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. >> >> 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. >> >> 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. >> >> 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. >> >> >> I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. >> >> So, before dismissing Glamour, perhaps it would be useful to actually look into it. >> >> Cheers, >> Doru >> >> >>> On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: >>> >>>> Hi Stef, >>>> >>>> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. >>> >>> Do you think so? >>> I do not think that we can base our infrastructure on something that only one person understand and can modify. >>> You will tell that this is the same for Morphic but this is not true. >>> >>> Stef >>> >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> > -- 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

Dec. 31, 2011