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

Re: [Pharo-project] glamour and pharo

by Stefan Marr

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. Happy new year 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] 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). > > I read: > > " Health is like freedom, we understand their importance when we lost it " Yes. My younger sister got a cancer two years ago and if that does not make me think about life then I would be a real idiot. :) Stef

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

> 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. > 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? You want me to shut up 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. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

>>> >> >> I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. > > Nice argument for your students reading this thread: > http://memegenerator.net/instance/12779750. Why other should be stupid axiomatically? >> But, what do you mean by slow? How did you benchmark it? > > No, but if you look at the code you will see many extra steps: > > 1. It tests if a registry is there: Why would that be necessary in an > object-oriented implementation? > > 2. It tests if the registry is empty: Why would that be necessary in > an object-oriented implementation? > > 3. It enters a critical section of a monitor: This is rarely useful > and the slowest kind of concurrency control available in Pharo (a > Mutex would be enough for what it is used for, and instantiate > multiple semaphores and queues), and btw the lazy initialization of > the monitor is the prime example of a race condition. > > 4. It creates a copy of the collection of all the subscriptions: This > is rarely useful and wouldn't be necessary if an immutable data > structure was used. > > 5. It iterates over all announcements, it doesn't even try to group > announcements of the same kind. > > 6. It wraps each announcement delivery into a curtailed block. It does > that even for those that are never actually announced. > > 7. It then tests each announcement if it matches, again it doesn't > even try to group the announcements of the same kind. Aside, the match > test was changed so that it doesn't allow instance-based announcements > anymore, breaking some of my code. > > 8. It then wraps the actual notification into an exception handler. > Again, this is rarely useful and should probably rather be something > pluggable. > > 9. It then culls the announcement and announcer into the block. Not > sure why the announcer is useful, after all the block was registered > with the announcer at some point. > > So all these 9 steps are not really necessary (or even wanted) in most > case. I doubt that any of them makes the code faster. I am glad that > the code works for you even if all of this new functionality is > untested. And good luck with the race condition :-) Why did you discuss that with igor and henrik? I mean ***discuss*** not taking the working hypotheses that they are idiot writing dull codeâ¦ >> There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. > 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. Stef

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

>> >> except that it changes the perception of blocks arguments and usage. > > I do not understand. you see the not this argument because the first should be xzk >>>> > Subclass of what? Perhaps we should just set a case study and I try to show something. But first, I would need to understand what the concern is. Could you help me with it? what is not clear to me is: when I code oo I get messages and each method is a potential hook for extension when I code component (because GL is that a component model) the ports are the extension points. How such extension points works in presence of subclassing. Then how the methods (because GL is coding in OO) which are the de facto hooks interact with the ports one. >>> 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. >> >> Because if alex can build a model and a little UI for basic image and wrap it with a better UI for glamouroust then >> we all win. Now if there is no UI for basic then the people like me that are always coding in alpha and working a lot >> with metacello will get zero benefit. >> >> I think that the plan is the following: >> - make the best IDE you can and that the people use it like hell >> - make sure that you force pharo to always load it >> - for the moment we are focusing on cleaning below. Now the challenge is that we need tools too. > > Sounds ok :). It's much better than the "sad" remark :). You know that I always say that. I even ask veronica to participate to the glamour chapter because I want more. But this is on another level. and I still have my doubts about glamour :) I think that building models and code that does not rely on glamour is the best way to make sure that it can work in both world. > But, I thought the whole idea of one Pharo image was to get some decent tools in there for the benefit of the infrastructural work as well. Am I wrong? Yes > > Cheers, > Doru > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > >

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

Lukas if you want you can improve the OB tutorial that we wrote and that was for PBE2 book. Now publishing an obsolete chapter is useless and I do not have the knowledge to change it. So if you want just ask us. Do not modify the one on git because the current version is on svn but we can add you on our server in less than a minute. Stef On Jan 1, 2012, at 11:07 PM, Lukas Renggli wrote: > OB is supported in Pharo 1.3. In fact, Colin and I have spent a lot of > time during the past months improving OB: laying the ground work for > multi-selection/trees, redesigned the rendering platforms (tool > builder, polymorph, web, ...; drag & drop, resizable panes), , etc.

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by Lukas Renggli

>>> To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). >> >> The size is the least problem. >> >> More annoying is that the code quickly gets out of sync and >> non-changes are added to the history. Both of these problems are >> already visible today. >> >> Additionally, over time people will change/add/remove features that >> get integrated without proper review. I just had a look at the >> announcement framework in Pharo 1.4 today, it is unbelievable how a >> tiny framework could degrade to a bloated, untested and dead slow pile >> of mud in just a few years :-( > > I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. Nice argument for your students reading this thread: http://memegenerator.net/instance/12779750. > But, what do you mean by slow? How did you benchmark it? No, but if you look at the code you will see many extra steps: 1. It tests if a registry is there: Why would that be necessary in an object-oriented implementation? 2. It tests if the registry is empty: Why would that be necessary in an object-oriented implementation? 3. It enters a critical section of a monitor: This is rarely useful and the slowest kind of concurrency control available in Pharo (a Mutex would be enough for what it is used for, and instantiate multiple semaphores and queues), and btw the lazy initialization of the monitor is the prime example of a race condition. 4. It creates a copy of the collection of all the subscriptions: This is rarely useful and wouldn't be necessary if an immutable data structure was used. 5. It iterates over all announcements, it doesn't even try to group announcements of the same kind. 6. It wraps each announcement delivery into a curtailed block. It does that even for those that are never actually announced. 7. It then tests each announcement if it matches, again it doesn't even try to group the announcements of the same kind. Aside, the match test was changed so that it doesn't allow instance-based announcements anymore, breaking some of my code. 8. It then wraps the actual notification into an exception handler. Again, this is rarely useful and should probably rather be something pluggable. 9. It then culls the announcement and announcer into the block. Not sure why the announcer is useful, after all the block was registered with the announcer at some point. So all these 9 steps are not really necessary (or even wanted) in most case. I doubt that any of them makes the code faster. I am glad that the code works for you even if all of this new functionality is untested. And good luck with the race condition :-) > There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. Do you really believe that stripping away unwanted material works? No other open source project in the whole world does it like that, everybody builds distributions on top of a smaller core: Linux, GCC, Gnome, FireFox, ... Even in the supermarket, you typically don't get a vegetable hamper if you just want a some potatoes. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 2, 2012

Re: [Pharo-project] glamour and pharo

by StÃ©phane Ducasse

Lukas please read this mail until the end before replying :) I want a tool suite that can work on another environment being it remote. I want to be able to refactor the code of the compiler that it is another image from this one. We need to be able to act on other cores. It does not look totally a stupid requirement. for RB this is simple :) If we cannot discuss and build something with you and that you stand on your position without taking time to see that we need to have it fully parametrized so that we could ideally refactor remote code, then what is left for us to do? Ok we take responsibilities for the changes we do. This is not the best solution for us but if we are forced then we do it. Even if adapting configurationOf can take my energy. Since we are a bit stupid we will do mistakes and may be you will be right but does it matter? Because at the end this is what we can do that count. The correct approach would have been to really try to see that the original design of RB is not immutable, it can be changed, it was not done for remote or other system refactoring. I saw that you fixed some of the problems I reported like directly accessing Smalltalk globals where it should not. Now instead of too often shooting at us negatively you would simply try to understand that: - moving implies breaking - the state of the system is still spaghetti code (how come that we should deprecate a method that generate accessor implemented on scrollbar!!!). - testing is important but on time (for example 1.3 was release as RC during at least 3 months and you complained because you tried it after 1.3 was out). - you can be sardonic if this helps you but I do not see the added value on the long term. > Additionally, over time people will change/add/remove features that > get integrated without proper review. I just had a look at the > announcement framework in Pharo 1.4 today, it is unbelievable how a > tiny framework could degrade to a bloated, untested and dead slow pile > of mud in just a few years :-( You cannot say that. This is insultant for the time and effort igor and henrik spent on it. Why do you think that announcement should stay a system that anybody can write in 2 hours, not dealing with weak registry? Now a gift for you. When you write impersonal mails this is easier to piss on people (Even if I decided that such little flood of nasty thoughts will not reach me). Avoid impersonal mails, put the human in the center of the loop. When you want to say "stef you are idiot because" just write it. Do the same say "Igor is a fucking idiot because he bloated Announcement" or "Henrik writes muddy and untested code". (writing this one made me laugh when I remember that igor and henrik stayed until 10 in the evening writing tests and improving announcement). > 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. Lukas do you want to be our andreas? Because to me this is what you are doing. Been smart and aggressive for the sake of it. You can do it if you have to pass by this stage but you could act in a much more friendly way and gain positive feeling in addition. You could be the pharo heros and have fun with us killing dragons - because this is what we did last thursday with the fucking event loop with igor. > This only makes it harder to have a modular system. And people that want to use > another refactoring engine (or another version thereof) are excluded, > because existing code depends on the included version. Again look at > where the announcements are used and how people work around to use > their own implementation. 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. Now tell us how you want to interact with us. Think about it because this is the new year resolution. What I would like is - I have no problem to remove RB from the image. But I need to be able to change it. for RPackage (you know the bad code I'm writing because the system is so well done). I need to change it also because I want to be able to plug into another image and refactor it remotely. I hope nick will start for real on that. - So if you want to communicate in a humane way with us. No problem, we can and we are happy to have fun with you. Now I do not want to get your frustration on my shoulders. I'm doing Pharo to build a better world and you know it. Stef

Jan. 2, 2012

Re: [Pharo-project] Happy new year!

by Dario Trussardi

Ciao, > 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). I read: " Health is like freedom, we understand their importance when we lost it " > Then lot of fun and business. Happy new year! Dario

Jan. 2, 2012

Re: [Pharo-project] string hash collisions?

by Andres Valloud

Part of why those attacks are so easy is that the factor for the multiplicative hash function is very poor (i.e.: 33, 31, etc). There is nothing spectacular about this reasoning, those "cool looking" factors chosen using the digital (finger) method should have been stamped out a long time ago. The hashing book I wrote has a ton of additional details on how to choose a factor properly if you want to use multiplicative hash functions, see here: http://www.lulu.com/spotlight/avsmalltalkbooks Of course you can avoid all that trouble by using a crypto hash, at the cost of the (mostly unnecessary) crypto hashing. The authors suggest using a randomized hash function, but how do persistent hash tables survive across invocations of the randomizer? Moreover, I suspect the following: 1. The multiplicative hash function they show as "improved" in Perl 5.8.1 seems to use effectively 1025 as a factor which is generally terrible (slide 77). 2. How is the seed determined? What criteria are used to guarantee it is a good seed value? 3. It is likely you can still abuse the hash function with series of null bytes, or by constructing strings that abuse that poor hash function into producing tons of collisions mod 2^x, x < 32. To sum it up... 1. If you use multiplicative hash functions, then you must choose the factor properly. Go read the literature. 2. If you are expecting attackers, consider making it difficult to find collisions in your hash function. A way to make it REALLY hard is to use a crypto hash. But the applicability depends on the application. Generally speaking, making something like a crypto hash function the default hash function is a bad idea. 3. Just "randomizing" a hash function can be as useful as "randomizing" a random number generator. Obfuscation is not equivalent to a fix. Without a clear understanding of why the results have to be good, chances are the results will be poor. On 12/30/11 7:58 , 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? > > [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html > > Cheers > Philippe > >

Jan. 2, 2012