- Pharo-dev - lists.pharo.org

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

by Lukas Renggli

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

Dec. 31, 2011

[Pharo-project] glamour and pharo

by Tudor Girba

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

[Pharo-project] Where did the Promise go?

by Stefan Marr

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

Re: [Pharo-project] string hash collisions?

by StÃ©phane Ducasse

I would really like to see if we are attackable like that (I skim through the slides). Levente I'm also interested in your other attack. Stef On Dec 30, 2011, at 5:45 PM, Levente Uzonyi wrote: > On Fri, 30 Dec 2011, Levente Uzonyi wrote: > >> On Fri, 30 Dec 2011, Philippe Marschall wrote: >> >>> Hi >>> As you probably noted string hash collisions are all the rage these days [1]. Has anybody looked into whether this applies to Pharo as well? >> >> I'm sure it does. > > Ok, I read the slides. Pharo is vulnerable, but the hash function is more complex than those in PHP, Java, etc. (though it has only 28 bits), so I guess it's a bit harder to find enough strings with clashing hashes. > > > Levente > >> >> >> Levente >> >>> [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html >>> Cheers >>> Philippe >> >> >

Dec. 30, 2011

Re: [Pharo-project] Pharo surpasses 1 Million downloads ;-)

by StÃ©phane Ducasse

:) Stef On Dec 30, 2011, at 4:58 PM, Sean P. DeNigris wrote: > I just happened to notice this on Squeaksource. Pretty cool. > Project Downloads > Pharo 1365087 > > -- > View this message in context: http://forum.world.st/Pharo-surpasses-1-Million-downloads-tp4246065p4246065… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Frank Shearar

On 30 December 2011 10:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 December 2011 10:54, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 30 December 2011 09:49, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>>> >>>> >>>> On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>> On 29 December 2011 15:44, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >>>>> > I was wondering what is planned regarding packages available on >>>>> > SqueakSource >>>>> > and Pharo.Â More and more packages can't load in Pharo and it gets more >>>>> > and >>>>> > more frustrating not being able to load anything without having to >>>>> > add/modify methods/classes all over the place so those packages can load >>>>> > properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource >>>>> > in >>>>> > the future ? >>>>> > >>>>> > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for >>>>> > every >>>>> > package is adding more complexity than what is needed.Â I know backward >>>>> > compatibility was thrown away from the start to avoid compromises in >>>>> > Pharo >>>>> > but how do we take care of the fact that as each day passes, less and >>>>> > less >>>>> > stuff from SqueakSource is usable in Pharo ? >>>>> > >>>>> The recipe is simple: maintenance. >>>>> >>>>> If you really care, spend time maintaining packages you using. >>>>> If nobody cares to maintain the software, it is dead. >>>>> It is only a matter of time for it to get broken. >>>>> We cannot give any guarantee that something which worked fine 10 years >>>>> ago will keep working today, >>>>> without keeping everything unchanged. >>>>> >>>>> If you have a garden and planted a rose there, do you expect that 5 >>>>> years later it will still grow there, without you taking care of it? >>>> >>>> >>>> >>>> Igor, I think he is not criticizing that. What he points out is not the lack >>>> of maintenance but a clear way of knowing which project/packages are >>>> expected to work or not in Pharo. If you take a random package/project from >>>> SS there is no way to know that. Having a Pharo catalog/certified >>>> packages/projects would help here. >>>> >>> >>> Well, it is just another side of same problem. >>> If package maintainer wants its package to work without problems with Pharo, >>> usually, he takes care of everything, from checking if it works with >>> latest pharo up to >>> mentioning where and how it can be loaded/used. >>> And if people don't care about their stuff, it is just rots and dies. >>> >>> Any attempts to do that externally (by people who don't maintain own >>> projects directly) are futile and counterproductive. >>> Because it is fine, you can spend couple of hours verifying that some >>> software works ok today, >>> "certify" it and list it in some "catalogue". But then tomorrow >>> something will be changed and again package will be broken/stop >>> working >>> properly. >>> So unless you maintaining your software continuously, there's no other >>> way to guarantee that it works and will keep working in future. >>> Remember the SqueakMap and Universe? They meant to solve same problem. >>> But you cannot solve it automatically, >>> because putting a package into list of certified packages does not >>> guarantees that if today it works, it will keep working tomorrow. >> >> Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it >> should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo >> 1.3" point to immutable chunks of code. And of course they must be >> immutable, because otherwise your versioning's useless. >> >> Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD >> requires maintenance, right up until 1.4 enters code freeze. >> >> Once 1.4 is released, Foo 1.2 can be released, and you can safely know >> - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 >> can load cleanly and work correctly in Pharo 1.4. And so on. >> > > What you described here is a normal _maintenance_ process. Now if > there's no people who doing it, > how it can magically keep working? There's no any guarantees for that. > Because Pharo does not standing still, > it moves and evolves. Indeed, it is _precisely_ a normal maintenance process, which is why I'm surprised that people are even talking about it. If you're actually writing an application against Pharo's HEAD, well, be prepared to run to keep up. And if you want to use such an application, you're on the bleeding edge, so hopefully you have some bandages. Pharo - or any other application - might move and evolve, but each version marks - or should! - a frozen point in time, a stable mark. In other words, applications released against _particular_ Pharo versions _should not rot_. They might not load in the latest Pharo, but that's what support is for. And to your main point, I can only agree: there's no substitute for the need for people to support the application to keep it up to date. frank > My main point is that questions like "why it cannot be loaded?" should > be addressed to right person(s) who is responsible > for maintaining particular project. And if there's none, then you can > make it work by yourself but again, ask right questions > like "class is missing, what can i do" instead of "my beloved package > stops working what can you do". Vigourous agreement. Which means that SqueakMap (or whatever) should point to the responsible person/s (as it can), so the beloved user could pester the right person. You still need some kind of process to handle cases like a maintainer retiring, of course. Again, a solved problem in many communities. (Hey, maybe it's already solved in Pharo, too: I can't claim to know more than a dabbler. I don't want to sound like I'm pointing fingers.) frank >> frank >> > > > -- > Best regards, > Igor Stasenko. >

Dec. 30, 2011

Re: [Pharo-project] string hash collisions?

by Philippe Marschall

On 30.12.2011 18:29, Levente Uzonyi wrote: > On Fri, 30 Dec 2011, Levente Uzonyi wrote: > >> On Fri, 30 Dec 2011, Levente Uzonyi wrote: >> >>> On Fri, 30 Dec 2011, Philippe Marschall wrote: >>> >>>> Hi >>>> >>>> As you probably noted string hash collisions are all the rage these >>>> days [1]. Has anybody looked into whether this applies to Pharo as >>>> well? >>> >>> I'm sure it does. >> >> Ok, I read the slides. Pharo is vulnerable, but the hash function is >> more complex than those in PHP, Java, etc. (though it has only 28 >> bits), so I guess it's a bit harder to find enough strings with >> clashing hashes. > > I think I found an easy way to create a slightly different attack. I'll > test it against Seaside if I'll have time for it tomorrow. Thanks, I'd be interested in the results obviously. Cheers Philippe

Dec. 30, 2011

Re: [Pharo-project] string hash collisions?

by Levente Uzonyi

On Fri, 30 Dec 2011, Levente Uzonyi wrote: > On Fri, 30 Dec 2011, Levente Uzonyi wrote: > >> On Fri, 30 Dec 2011, Philippe Marschall wrote: >> >>> Hi >>> >>> As you probably noted string hash collisions are all the rage these days >>> [1]. Has anybody looked into whether this applies to Pharo as well? >> >> I'm sure it does. > > Ok, I read the slides. Pharo is vulnerable, but the hash function is more > complex than those in PHP, Java, etc. (though it has only 28 bits), so I > guess it's a bit harder to find enough strings with clashing hashes. I think I found an easy way to create a slightly different attack. I'll test it against Seaside if I'll have time for it tomorrow. Levente > > > Levente > >> >> >> Levente >> >>> >>> [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html >>> >>> Cheers >>> Philippe >>> >>> >>> >> >> > >

Dec. 30, 2011

Re: [Pharo-project] string hash collisions?

by Levente Uzonyi

On Fri, 30 Dec 2011, Levente Uzonyi wrote: > On Fri, 30 Dec 2011, Philippe Marschall wrote: > >> Hi >> >> As you probably noted string hash collisions are all the rage these days >> [1]. Has anybody looked into whether this applies to Pharo as well? > > I'm sure it does. Ok, I read the slides. Pharo is vulnerable, but the hash function is more complex than those in PHP, Java, etc. (though it has only 28 bits), so I guess it's a bit harder to find enough strings with clashing hashes. Levente > > > Levente > >> >> [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html >> >> Cheers >> Philippe >> >> >> > >

Dec. 30, 2011

Re: [Pharo-project] string hash collisions?

by Levente Uzonyi

On Fri, 30 Dec 2011, Philippe Marschall wrote: > Hi > > As you probably noted string hash collisions are all the rage these days [1]. > Has anybody looked into whether this applies to Pharo as well? I'm sure it does. Levente > > [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html > > Cheers > Philippe > > >

Dec. 30, 2011