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

Re: [Pharo-project] WTF -> instVar called 'behaviors' in first slot

by Mariano Martinez Peck

On Wed, May 16, 2012 at 1:50 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Wed, May 16, 2012 at 12:45 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > Any idea what can happen? > > Have you tried doing a full recompilation of all subclasses? > > yes, in fact, i even tried doing a Compiler recompileAll. I had the same thought as you hahahaha > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > -- Mariano http://marianopeck.wordpress.com

May 16, 2012

Re: [Pharo-project] WTF -> instVar called 'behaviors' in first slot

by Damien Cassou

On Wed, May 16, 2012 at 12:45 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Any idea what can happen? Have you tried doing a full recompilation of all subclasses? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 16, 2012

Re: [Pharo-project] WTF -> instVar called 'behaviors' in first slot

by Camillo Bruni

any direct users of #instVarAt: maybe? On 2012-05-16, at 12:45, Mariano Martinez Peck wrote: > Hi guys. Today we had something really strange with Pharo 2.0. We are serializing FLPackage: > > Object subclass: #FLPackage > instanceVariableNames: 'extensionMethods behaviors mustInitialize preLoadActions postLoadActions additionalObjects' > classVariableNames: 'MustInitializeByDefault' > poolDictionaries: '' > category: 'FuelPackageLoader' > > That definition, where 'extensionMethods' is before 'behaviors' it works perfect. However, when just switching the oder to: > > Object subclass: #FLPackage > instanceVariableNames: 'behaviors extensionMethods mustInitialize preLoadActions postLoadActions additionalObjects' > classVariableNames: 'MustInitializeByDefault' > poolDictionaries: '' > category: 'FuelPackageLoader' > > > The serialization of PharoCore fails because a problem with a metaclass of HTTPSocket. > > Any idea what can happen? > > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

May 16, 2012

Re: [Pharo-project] [squeak-dev] Re: Implementors of...

by Camillo Bruni

you're partly right igor :) that's why I added the cmd-click and cmd-shift-click to the code panels for browsing implementors / senders of without choosing a menu. the one problem that remains is that shout only gives you back the tokens with limited semantic annotations. hence you don't know if something belongs to a multi-keyword selector or not. => that will change once we have full AST nodes around On 2012-05-16, at 02:46, Igor Stasenko wrote: > i don't understand one thing: > we have shout, and it parses the source code to highlight it correctly, > which means that it knows where each keyword selector starts, > where it ends.. > still we cannot navigate the code just by clicking on selector part or > to variable name. > the most annoying is when you have nested sends.. and sender/implementors often > fail to work.. > > > On 16 May 2012 01:55, Chris Muller <asqueaker(a)gmail.com> wrote: >>> In Nautilus, unlike old Browser it now works for multiple keywords, so >>> things are improving. >> >> Mm, I think it was Dan Ingalls who made browsing senders/implementors >> of multi-argument keyword messages in the code pane working since the >> 1990's. >> >> It works with even gross effort -- in the attached picture I made a >> sloppy selection of #objectWithOid:ifFound:ifAbsent and press >> Command+M to get implementors in spite of all of the intermediate code >> it knows what I wanted. >> >>> The main drawback from usability point of view: it is an implicit >>> feature, invisible to newbie and other out of the context. >> >> I was using Squeak for more than 5 years when someone told me about it >> -- Once discovered, it's great, productivity has been a bit higher >> ever since. People should know about it if they don't already.. >> >> >> >>> Though in term of number of actions necessary to reach information, >>> I'm not sure it's a clear win. >>> There's a balance between simplicity and efficiency. >>> Isn't it also a step backward in promotion of keyboard navigation over >>> mouse navigation? >>> >>> Nicolas >>> >>>> >>>> Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) >>>> (right now I am more in a "bugs fix" phase that "add new features" one ^^) >>>> >>>> Ben >>>> >>>> >>>> >>>> On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: >>>> >>>>> Tried from Nautilus: >>>>> >>>>> Why when asking 'implementors of ' in the method menu, I only got the >>>>> implementor of this method. >>>>> >>>>> Am I doing something wrong? >>>>> >>>>> Look like the browser need a lot of love. >>>>> >>>>> Hilaire >>>>> >>>>> -- >>>>> Dr. Geo -- http://www.drgeo.eu >>>>> >>>>> >>>> >>>> >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 16, 2012

[Pharo-project] WTF -> instVar called 'behaviors' in first slot

by Mariano Martinez Peck

Hi guys. Today we had something really strange with Pharo 2.0. We are serializing FLPackage: Object subclass: #FLPackage instanceVariableNames: 'extensionMethods behaviors mustInitialize preLoadActions postLoadActions additionalObjects' classVariableNames: 'MustInitializeByDefault' poolDictionaries: '' category: 'FuelPackageLoader' That definition, where 'extensionMethods' is before 'behaviors' it works perfect. However, when just switching the oder to: Object subclass: #FLPackage instanceVariableNames: 'behaviors extensionMethods mustInitialize preLoadActions postLoadActions additionalObjects' classVariableNames: 'MustInitializeByDefault' poolDictionaries: '' category: 'FuelPackageLoader' The serialization of PharoCore fails because a problem with a metaclass of HTTPSocket. Any idea what can happen? thanks -- Mariano http://marianopeck.wordpress.com

May 16, 2012

Re: [Pharo-project] Smalltalkhub needs your quick in the ass :)

by nicolas petton

2012/5/16 Stefan Marr <smalltalk(a)stefan-marr.de> > Hi Nico: > > On 16 May 2012, at 10:48, nicolas petton wrote: > > > - Smalltalkhub *will be SEO friendly* and have static version for > crawlers > Well, you are very brief, and I might misunderstand you, but: > IMHO that approach did not work out for the kind of Flash pages we built > back then. > Not only is the loading animation a reminiscence of dark times, > but the overall approach has prove to be unmaintainable, in my experience. > > Since we have the example GitHub: > To my understanding, their approach is the other way around, and seems to > work a lot better. > They have static pages, and these static pages are _augmented_ with AJAX > to give human users a better experience. > > So, seems to me a lot different to what we did back then with Flash, and > what looks like your current approach. > My current approach is very similar to what Twitter and some other modern web apps do. The UI is built on the client-side, and pages (will be) built on the server for fallback (including bookmarkable urls and everything). > > Anyway, nice project, and it looks visually very polished :) > Thank you :) Nico

May 16, 2012

Re: [Pharo-project] OpenID/OAuth library (was SSO - CAS Client in Smalltalk ?)

by Janko MivÅ¡ek

Dne 15. 05. 2012 16:41, piÅ¡e Yanni Chiu: > On 15/05/12 3:00 AM, Janko MivÅ¡ek wrote: >> Dne 15. 05. 2012 00:01, piÅ¡e StÃ©phane Ducasse: >> >>>> Just FYI, me and Cloudfork guys are just finishing the OpenID 2.0/OAuth >>>> 2.0 support for Iliad and Aida, based on Cloudfork SSO [1]. On Pharo >>>> and >>>> VW. On Pharo Zync with Zodiak SSL is used. Current goal is to develop a >>>> Google Docs API support. >>> is the library available as a library? I mean not linked to aida or >>> iliad? >> Idea actually is to have WebCloudSSO library as independent as possible, >> but not without some web server/web framework, because OpenID/OAuth rely >> heavily on HTTP redirects. >> >> WebCloudSSO library currently works on Aida, now I'll start adapting it >> to Iliad, later someone can adapt it to Seaside or even to plain web >> server like Zync. Maybe it will even come under Cloudfork trademark at >> the end, we will see. Cloudfork otherwise already have a Seaside OpenID >> example. > Have I understood this right? You started with CloudforkSSO, "ported" it > to Iliad and Aida (i.e. WebCloudSSO), and in future WebCloudSSO may > merge back into CloudforkSSO. Was it just easier/faster to do it this > way, rather than split the Seaside dependent parts out of CloudforkSSO? WebCloudSSO uses and extends a bit updated original Cloudfork. I therefore didn't replace it. Separate package was chosen to more freely experiment and add OpenID/OAuth functionality to Aida and Iliad, now when WebCloudSSO stabilises, it is time to propose a merge back to Cloudfork. My idea and proposal is to have one "trademark" for all cloud related support and for all web frameworks. And Cloudfork is actually very good library, portable to many Smalltalks, so let me thank Jan van de Sandt and Ernest Micklei on this occasion for their excellent work! > Is there any additional OpenID/OAuth functionality in WebCloudSSO, > beyond what was in CloudforkSSO? Yes, OAuth 2.0 support, which is not in CloudforkSSO yet (just OAuth 1.0 there). An few OpenID 2.0 changes. Two main classes are added: OpenIDAuthenticator OAuthAuthorizator Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by Esteban Lorenzano

Hi, On May 16, 2012, at 9:23 AM, Pavel Krivanek wrote: > On Tue, May 15, 2012 at 11:29 PM, StÃ©phane Ducasse > > I will quote GermÃ¡n (I hope he will not mind): "lot and lot of > things... Lot of new things each day. Not time to stabilize nothing. > Is needed such acceleration? ... My point is, I'm trying to move a > business with Smalltalk and the acceleration of Pharo is well know by > me (from other companies) and sooner or later, impact in my job and > I'm a very LITTLE software house can't migrate my products all the > time." well... as you quote German, I will quote myself answering GermÃ¡n (well... also translating from spanish and putting some context) :) I said something like: "No no no, that's not true" :) 99% of the changes affects infrastructure and/or replace old tools. Why your work should be affected by that? I migrated Seaside from 1.3 to 1.4 in 15'... and the "problem" was not Seaside-Pharo incompatibilities, but to adapt configuration to not load OB (just not choose those packages in the metacello config) Other frameworks like Magritte and Pier ran out of the box. (well... Magritte-Mophic needed a small adjust... and that was like 5') For more examples, my personal projects (I submitted 3 slides yesterday for two of them), are usually complex projects (both for web and desktop) and I migrated all of them in less than a morning work (I needed to update/modify my metacello configurations for that). So... as soon as I know... your feelings are just that: feelings. Not real facts. And maybe those feelings are because we (as a community) are growing and we need to adapt our communication processes to match current status. But I think that's a good think, not a bad one. > We simply have to accept that some developers can have this feelings > and try to find a way how to limit it. I think that some official > Pharo blog (maybe written by Esteban) would be very helpful. Some kind > of not very extensive technical information source that will help > people to stay in touch with Pharo progress. That will explain what is > being changed in Pharo and why. I think that developers than will see > the changes like positive not as alien ones. As I said above, I agree we need to improve our communication efforts. New times need new ways :) I think a developers blog is a good idea, but I cannot commit myself to produce one weekly blog post, for me a monthly post is more realistic... but I will talk with others and see how can we fulfill that. Also, maybe splitting list as Marcus said is a good step... best, Esteban

May 16, 2012

Re: [Pharo-project] Smalltalkhub needs your quick in the ass :)

by Stefan Marr

Hi Nico: On 16 May 2012, at 10:48, nicolas petton wrote: > - Smalltalkhub *will be SEO friendly* and have static version for crawlers Well, you are very brief, and I might misunderstand you, but: IMHO that approach did not work out for the kind of Flash pages we built back then. Not only is the loading animation a reminiscence of dark times, but the overall approach has prove to be unmaintainable, in my experience. Since we have the example GitHub: To my understanding, their approach is the other way around, and seems to work a lot better. They have static pages, and these static pages are _augmented_ with AJAX to give human users a better experience. So, seems to me a lot different to what we did back then with Flash, and what looks like your current approach. Anyway, nice project, and it looks visually very polished :) 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

May 16, 2012

Re: [Pharo-project] Pharo is exploding

by Janko MivÅ¡ek

Good balance between innovating/improving/changing and long-term confidence/stability/reliability is needed for a commercial tool. And both GermÃ¡n and Marcus are right, both in their own way. I'd certainly like for Pharo to progress further but on the other side I'd like to get a better confidence on it. This is as said always a balancing act and yes, better communication of new release's merits and changes would help here. For us "outsiders", that is, Pharo users and not internal developers, for us a long list of closed issues means just nothing. Release notes kind of Gemstone has [1] would be better. Here main changes are explained in more detail. Also blog posts like Mariano's and Esteban's are very valuable as well. [1] http://community.gemstone.com/download/attachments/6816350/GS64-ReleaseNote… Best regards Janko Dne 16. 05. 2012 09:23, piÅ¡e Pavel Krivanek: > On Tue, May 15, 2012 at 11:29 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>>> It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do >>>> seriuous development you won't beusing Pharo 2.0, will you? ;) >>> >>> I talked about that few days ago with GermÃ¡n. The problem is not in >>> using of unstable version. The problem is that it is very easy to stop >>> to be in touch with Pharo now and within one year when the current >>> unstable version will become stable the developers will face to very >>> different system. That is one of the reason why GermÃ¡n choose Cuis for >>> his current projects. Developers want simple predictable system. >> >> Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. >> And and and again again again and again who is concerned by RPackage vs PackageInfo, >> systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. >> I find that a totally false argument. > > I will quote GermÃ¡n (I hope he will not mind): "lot and lot of > things... Lot of new things each day. Not time to stabilize nothing. > Is needed such acceleration? ... My point is, I'm trying to move a > business with Smalltalk and the acceleration of Pharo is well know by > me (from other companies) and sooner or later, impact in my job and > I'm a very LITTLE software house can't migrate my products all the > time." > > We simply have to accept that some developers can have this feelings > and try to find a way how to limit it. I think that some official > Pharo blog (maybe written by Esteban) would be very helpful. Some kind > of not very extensive technical information source that will help > people to stay in touch with Pharo progress. That will explain what is > being changed in Pharo and why. I think that developers than will see > the changes like positive not as alien ones. > > -- Pavel > >>> I do not think that the way out from this is to slow down. On the >>> contrary. We simply have to do this era of a lot of big changes as >>> short as possible ;-) >> >> > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

May 16, 2012