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

Re: [Pharo-project] A challenge for all who cares

by Igor Stasenko

On 21 February 2012 02:40, Guido Stepken <gstepken(a)googlemail.com> wrote: > I predicted it! > Predicted what? That you will repeat same things which you said half year ago? Again, Guido, why you think you are the only one who knows about issues on which you constantly pointing out? I knew about this stuff long ago (in 2007), when i first met squeak. Pharo didn't even existed at that time. Now you think that all bad things are magically disappear/get fixed once magnificient Guido will point on them? I don't want to disappoint you, but some things on the landscape tend to change slower than you expect. > http://forum.world.st/Hanging-connects-exhausted-resources-memory-leaks-boc… > > You want me as experienced software architect and project manager predict > more about Pharo's future (or doom), or are you willing to listen and learn? > > You will debug Pharo/Squeak until your 90 years old, because you (the Pharo > team) is not able to address bugs systematically. This is fact! > > Look e.g. at LUAJit. Stable, used by estimated 10 mio users of WORLD OF > WARCRAFT, Wikipedia, portable, rockstable. > > Pharo???? Unstable, nobody uses it, academic brainfuck. And Dr. Geo will > soon be implemented in JavaScript, i think, the better solution, other apps > will disappear soon, like CMSBOX, ... doom! > > My prediction, if you don't develop the development process any further!!! > > tnx 4 understanding, > > Guido Stepken > > Am 21.02.2012 01:10 schrieb "Igor Stasenko" <siguctua(a)gmail.com>: > >> On 20 February 2012 23:55, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > Le 20 fÃ©vrier 2012 23:06, Guido Stepken <gstepken(a)googlemail.com> a >> > Ã©crit : >> >> Am 20.02.2012 21:30, schrieb Nicolas Cellier: >> >> >> >>> What, what, the right development process wouldn't solve such a >> >>> trivial problem ? >> >>> Guido, try to inspect yourself with all your introspection tools and >> >>> development process know how, because I have the feeling that despite >> >>> the many answers you got, you still face a message not understood >> >>> problem ;) >> >>> >> >>> Nicolas >> >> >> >> >> >> Nicolas, i *know*, there must be a solution! Cannot be, that i klick >> >> into a >> >> menu and *directly* run into error messages. >> >> >> >> Think! >> >> >> >> Develop the development process! Don't argue! >> >> >> >> tnx, Guido Stepken >> >> >> > >> > Guido, you take a bug in a hacked Cuis image to demonstrate that Pharo >> > development process is wrong... >> > So how could I possibly argue if you don't use logic. >> >> Because it is much easier to keep saying "you're wrong/you doing it wrong" >> than do anything towards fixing it by yourself. >> >> > >> > That's a pity, because for once we had something pretty close to a >> > true bug report... >> > but the bug doesn't even show in a Cuis image, I just took my not so >> > precious time to check. >> > >> > That doesn't matter because I have no doubt that you are not >> > interested at all in bug reporting/fixing. >> > When I unwind your long stack of message sends, I see the same good >> > political slogan, develop the development process. >> > Well very nice, you found yourself initiated with higher level >> > functions, but beware, in Haskell like in Guido, there is no way to >> > detect an infinite recursion, even if we seriously suspect one. >> > >> >> Can't wait till Guido will start learning quantum mechanics. >> I can hear his "you doing it wrong" echoing from future :) >> >> > Nicolas >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 21, 2012

Re: [Pharo-project] Airbrake for Pharo

by Camillo Bruni

I think for long-running / remote services this is what you want. I remember using django-sentry: https://github.com/dcramer/sentry for tracking remote errors... https://github.com/dcramer/sentry I prefer the interface of django-sentry over errbit, but otherwise I don't really see a bit diff. best cami On 2012-02-21, at 23:41, Igor Stasenko wrote: > On 22 February 2012 00:07, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Tue, Feb 21, 2012 at 11:04 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> On Tue, Feb 21, 2012 at 11:01 PM, Lawson English <lenglish5(a)cox.net> >>> wrote: >>>> >>>> Have you looked at Spoon lately? >>>> >>> >>> Yes, more than what you can imagine. My PhD topic is related to Spoon, I >>> have even checks its VM code and I have privatly discussed with Graig. >>> That being said, I don't see how Spoon can be related to what I am saying >>> in this email. >> >> >> Ok...maybe I got it now. Related to the stuff of moving contexts and stuff >> between images right? if that's the case, then I appreciate the hint :) >> >> Now I am still waiting for comments on the Airbrake. >> > > I like the concept. If it helps to distinguish between old (and > already fixed) bug and new one.. it is cool. > >>> >>> Thanks >>> >>>> >>>> L. >>>> >>>> >>>> On 2/21/12 2:48 PM, Mariano Martinez Peck wrote: >>>> >>>> Hi guys. In my post about "Moving contexts and debugger between images" >>>> Francois recommend me to take a look to http://airbrakeapp.com/ >>>> I recommend you to take a look to the project to get an idea what it is. >>>> I argued that it was not open-source but then "renemendoza" pointed me out >>>> an open-source project which is API compliant with airbrake: >>>> https://github.com/errbit/errbit >>>> >>>> I think it could be a nice project to see how we can integreate that with >>>> Pharo. Could a Pharo-based app use such a tool? For example, can we add >>>> PharoDebug.log, crash.dump, etc etc? Do we need to write a client for >>>> Pharo? >>>> >>>> Would be able to upload Fuel serialized contexts so that someone can then >>>> debug in another image (with the limitations that it has) ? >>>> >>>> Cheers >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Best regards, > Igor Stasenko. >

Feb. 21, 2012

Re: [Pharo-project] Nautilus Refactorings

by Camillo Bruni

On 2012-02-21, at 21:19, StÃ©phane Ducasse wrote: > Ben > > I like the suggestion of mariano and luc. > I discussed with them. > > - opening by default on packages is better because it does not force you to display the full > hierarchy. => add preference setting > > - could you try to see if you can just display the packages and hierarchy without swapping them? => add preference setting > > Stef >>> One last thing: when you type the name of a class somewhere and you do a cmd+b I think it would be much better if Nautilus open the "normal" browser and not "hierarchy" one. >> >> having cmd+h for hierarchy would be great :) >> >> +9999999 >> >> to open a hierarchy when you do cmd+b is bad for me beacuse: >> >> 1) 99% of the times I browse that way, I want to see that class, and 99% also the rest of the classes of that package, not the hierarchy >> 2) I am used to that since the last..mm 3 years ;) >> 3) Because it seems the hierarchy windows is slow in big cases [Object browse] timeToRun 19225 so it took me 20 seconds to open the window ;) >> >> Because of that, I much prefer cmd + to for a normal browse. I don't pretend all agree, so I would be very happy when you have the setting. Please let me know so that I can set it :) >> >> Cheers! >> >> >> >> Ben we should produce a configuration because this is important. >> What you can do is at least load the baseline and snapshot only when you will release on version for 1.4 and 1.5 >>> >>> >>> On Mon, Feb 20, 2012 at 8:38 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> To be honest, if it works, I do not want to lose my time on Configuration >>> >>> >>> It shouldn't be done by hand, but generated by a tool :) >>> >>> >>> Ben >>> >>> On Feb 20, 2012, at 8:06 PM, Mariano Martinez Peck wrote: >>> >>>> >>>> >>>> On Tue, Feb 14, 2012 at 6:39 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> Hello guys, >>>> >>>> I know a some of you are waiting for the integration of the RB engine into Nautilus. >>>> >>>> Some of them are already implemented, so if you wanna test them, here is the gofer script >>>> >>>> Gofer new >>>> url: 'http://ss3.gemstone.com/ss/Nautilus'; >>>> package: 'ConfigurationOfNautilus'; >>>> load. >>>> >>>> (Smalltalk at: #ConfigurationOfNautilusRefactoring) perform: #loadDefault >>>> >>>> >>>> >>>> >>>> So...that's the way of loading Nautilus with refactorings? Wouldn't it be better to include RB dependencis in ConfigurationOfNautilus and have a specific group there. So you can do for example >>>> >>>> ConfigurationOfNautilus project stableVersion load: 'WithRefactorings'. >>>> >>>> ? >>>> >>>> BTW, I checked the ConfigurationOfNautilusRefactoring and it looks you miss a critical feature of Metacello: project references :) From ConfigurationOfNautilusRefactoring you can directly depend on ConfigurationOfRB or ConfigurationOfNautilus rather than duplicating everything in there. Don't tell Stef you didn't read the chapter hahahaha >>>> >>>> >>>> >>>> It loads everything. >>>> >>>> For now I have only done some refactorings for classes, so if you popup the menu on a class, a new item named Refactoring should appear :) >>>> >>>> Moreover, the 'rename class' method is replaced by the RB one :) >>>> >>>> >>>> Thanks in advance for your feedback, and if you want to participate, you are more than welcome :) >>>> >>>> >>>> Ben >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Feb. 21, 2012

Re: [Pharo-project] Airbrake for Pharo

by Igor Stasenko

On 22 February 2012 00:07, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Tue, Feb 21, 2012 at 11:04 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Tue, Feb 21, 2012 at 11:01 PM, Lawson English <lenglish5(a)cox.net> >> wrote: >>> >>> Have you looked at Spoon lately? >>> >> >> Yes, more than what you can imagine. My PhD topic is related to Spoon, I >> have even checks its VM code and I have privatly discussed with Graig. >> That being said, I don't see how Spoon can be related to what I am saying >> in this email. > > > Ok...maybe I got it now. Related to the stuff of moving contexts and stuff > between images right? if that's the case, then I appreciate the hint :) > > Now I am still waiting for comments on the Airbrake. > I like the concept. If it helps to distinguish between old (and already fixed) bug and new one.. it is cool. >> >> Thanks >> >>> >>> L. >>> >>> >>> On 2/21/12 2:48 PM, Mariano Martinez Peck wrote: >>> >>> Hi guys. In my post about "Moving contexts and debugger between images" >>> Francois recommend me to take a look to http://airbrakeapp.com/ >>> I recommend you to take a look to the project to get an idea what it is. >>> I argued that it was not open-source but then "renemendoza" pointed me out >>> an open-source project which is API compliant with airbrake: >>> https://github.com/errbit/errbit >>> >>> I think it could be a nice project to see how we can integreate that with >>> Pharo. Could a Pharo-based app use such a tool?Â For example, can we add >>> PharoDebug.log, crash.dump, etc etc?Â Do we need to write a client for >>> Pharo? >>> >>> Would be able to upload Fuel serialized contexts so that someone can then >>> debug in another image (with the limitations that it has) ? >>> >>> Cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Feb. 21, 2012

Re: [Pharo-project] Netstyle experience (was Do not feed the trolls)

by Igor Stasenko

True. Again, there are two opposing forces: compatibility versus improvement. Sometimes it is very hard or even impossible to improve system without breaking compatibility. What i don't see, is how things which lying in front of us are related to any sort of academia research. They are completely practical: - improve event handling - move to new file system - provide better FFI - new compiler and so on. You know, Janko, polishing makes sense if you have something which looks fine and you know that it will serve you well in future. But polishing things which were lying broken in garage for years makes little sense. People might mistakenly think that we wanna change things solely for the sake of change. But it is not like that. We need these changes , need to fix our infrastructure, because without solid basement you cannot build anything good. On 21 February 2012 22:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi janko > >> More polishing and boring bug hunting tasks therefore and just a bit >> less fundamental rewritings like compiler etc. > > Did you ever look at one bug entry? > You see the bug entry does not magically empty itself. There are people like me and marcus > and a couple of others that are looking at reports, producing fixes... > >> Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the >> above priorities are much more important. > > Well this is not true: > Â Â Â Â - if you want to build the next generation of code coverage tools > Â Â Â Â - better tools > Â Â Â Â - without a good compiler we can also say bye bye to the next generation of optimization > Â Â Â Â do not think that Cog is the end of the story. It is just the start. > > then you need to be able to understand the code and be able to fix it. > So the compiler is important. > > Stef -- Best regards, Igor Stasenko.

Feb. 21, 2012

Re: [Pharo-project] remote debugging (was "Airbrake for Pharo")

by Craig Latta

Hi Mariano-- > Related to the stuff of moving contexts and stuff between images > right? Yeah. With Spoon you can debug processes whose contexts span multiple machines. Mostly the contexts stay where they are, though, and the debugger uses proxies on them. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Feb. 21, 2012

Re: [Pharo-project] Why do we use Pharo? a.k.a. rethinking Pharo marketing

by Esteban Lorenzano

Hi, El 21/02/2012, a las 5:52p.m., StÃ©phane Ducasse escribiÃ³: > esteban > > - I want a talk presenting your application for the pharo conference you ask it, you have it... :) > > - yes you will work with igor to get FFI nb aligned cool! > - for Pharo for the enterprise: I started with Olivier Auverlot but I feel alone :) > we should have the DBXtalk chapter! Thanks guile! yes... maybe pharo conf. help to align this work Esteban > Stef > > On Feb 21, 2012, at 6:51 PM, Esteban Lorenzano wrote: > >> Hi, >> >> while I see many of your points, I disagree with some of them: >> >> We have a tool that allow us to deliver complete and powerful applications in 2-6 weeks (and even less): Pharo. >> >> Right now my small company (of myself :) ) is finishing (bah, doing some change requests) for an application for managing thousands of accounts and data. Application was made on Glamour+Magritte+MongoTalk+Some persistence and reporting tool made by myself, based on magritte. >> Customer is really happy, because now they can obtain reports of any kind instead the shit they have before (made in Delphi, but there is not a problem of delphi itself but the programmer using it) >> The time to develop from scratch this? Four weeks-man. And if we took off all the work I made to make MongoTalk work, reporting and some personal adjusts to glamour, it would be less than three weeks (is important to know, because that work does not need to be repeated...). >> (btw, I could do the same for the web, using Seaside) >> >> Also, we are working (not yet there, but almost), to accomplish several of the issues not completely done for enterprise: >> >> 1) we have DBXTalk, to RDBMS. Is slow, but that's a problem of FFI that we think it will be solved soon (with Threaded FFI) >> 1.1) we also have a growing set of packages for working with NoSQL (Mongo, Riak, Tokio) >> 2) we have UI components and powerful frameworks like Glamour, but I agree there is a lot more work needed there >> 3) we have ways to talk to outside world (FFI, NB)... but also I agree more work is needed there (for instance, I would like to embed pharo into other applications, not just call libraries from pharo) >> 3.1) we also have SOAP support (never tried, not sure it's status) >> 4) For remote: we have Ubiquitalk >> 5) authentication: not sure what you mean but we have cryptography and work for secure connections is on the way (with Zodiac) >> 6) reporting. Ok, not much here... but there is HPDF package and I will release my HPDFReport and CSVReport classes soon (they are very easy classes anyway, don't expect too much :) >> >> for... bach modules... not sure what are you meaning with that... >> >> So yes, many of this issues are not really finished or stable (and that's why I see your concerns)... but just think where we were last year. I'm really optimistic about the future. >> >> What we really, really need is a book: "Pharo for the Enterprise". Something like the JEE specification, explaining how enterprise customers can use Pharo for their business, right now is a bit confusing, I admit that. >> >> Other concern (but this is a no-point for discussion, I just wanted to say it :P): Java and C# are not easy at all to learn. They are hard and ugly and new programmers spend years learning it (if they ever learn it completely)... also it is uncomfortable for starters (look how much you need to have a simple "hello, world" there). You think preparing an image is hard? give a new programer a maven script and ask him to build an application with that. Or worst, ask him to add a new dependency... >> Industry uses those languages and not Smalltalk for many-many reasons... but this is not one of them. >> (Also... there is a lot of big industries still developing on COBOL. sadly) >> >> best, >> Esteban >> >> El 21/02/2012, a las 2:16p.m., Krishsmalltalk escribiÃ³: >> >>> >>> The choice is ours to make and define. >>> >>> Yes enterprise is boring for those wanting life on the edge: tech or anything alike... I would love to jump over to the other side... >>> >>> Its like the freedom of being Picasso vs being a commercial artist in a studio. >>> >>> Enterprise typically will use software that is stable and capable of being easily usable by newbies. It cares less for the edge of technology, which can be achieved by just a minimal subset of the developer community. Yes no new larger enterprise stuff will happen in COBOL or ilk... But java and c# have proven to be easier to train in freshers, capable of adapting and calling any of the new technology if required etc. The very facts we tout as major winners in smalltalk is actually dimly viewed by the bulk of managers in enterprise: dynamic typing to begin with. They love the fact that the junior dev cannot commit many blunders that smalltalk can carry. Image based runtime, packaging , source code mgmt in st, etc are amongst stuff few comprehend well. Also we lack any decent libraries to for many a task, including reporting, DBMS , soap and many other stuff which when required only the ingenous smalltalker can cobble it, not our general developer base. >>> >>> I can be specific with tons of example, that we need to push a clean rock stable kernel and winning platform like rails, that make it hugely possible for a small firm to push out completed apps in 2 to 6 weeks. It's like the construction industry, be able to pick all components of the software: authentication, DBMS / ORM , reporting, UI components, messaging, interfaces to outside world viz soap, FFI , Remote , batch modules, ... One can push in a long list... >>> >>> All this is important only if we want to succeed statistically and that enriches the community to then indulge even more in research, it's symbiotic in that way. The more success you get in the industry the more funding there will be to do fundamental research eventually, the more happier all levels of smalltalkers from the expert to the beginners will be. >>> >>> Modified Quote from Kung Fu panda: master oogway "enterprise .. No enterprise .. Who cares", what we do care for is the eventual adoption of smalltalk as an equal partner in the landscape of languages, platforms in the world, gives enough money for everyone around. Unequal if it must eventually.. >>> >>> >>> >>> On Feb 21, 2012, at 1:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On Feb 21, 2012, at 3:11 AM, Krishsmalltalk wrote: >>>> >>>>> Yes, >>>>> >>>>> Do not emphasize on one or few keywords. Malleable is better than plastic (can be off putting for any environment conscious) >>>>> >>>>> Adopt the Pharo motto: >>>>> >>>>> "Pharo shall be one of the best enterprise platform in 3 years." >>>> >>>> >>>> Isn't "Enterprise Plattform" another word for "boring and complicated" ?? >>>> >>>> Marcus >>>> >>>> >>>> -- >>>> Marcus Denker -- http://marcusdenker.de >>>> >>>> >>> >> >> > >

Feb. 21, 2012

Re: [Pharo-project] Pharo VM

by Esteban Lorenzano

cool! really good news :) El 21/02/2012, a las 7:11p.m., Igor Stasenko escribiÃ³: > On 21 February 2012 16:50, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> I'm asking because Stef mentioned that and I told it to a friend that >> should create and maintain Fedora packages for Pharo. So he naturally >> decided to wait.... >> > Here some news: > We finally got windows slave up and running. So, now we can build Vms > for all 3 platforms and test them. > > Now there are 2 things left before releasing updated VMs: > - test why windows VM crashing randomly > - create an job for building 1-click package. > > P.S. An automatic builds often detecting various discrepancies here > and there, since it doing everything from scratch every time, > which you usually don't do if run things manually. > Which is good, because it helps us to ensure that things we do are > reproducable, but it means having more work :) > > > > -- > Best regards, > Igor Stasenko. >

Feb. 21, 2012

Re: [Pharo-project] Pharo VM

by Guido Stepken

Thank you! Very much! Am 21.02.2012 23:11 schrieb "Igor Stasenko" <siguctua(a)gmail.com>: > On 21 February 2012 16:50, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > I'm asking because Stef mentioned that and I told it to a friend that > > should create and maintain Fedora packages for Pharo. So he naturally > > decided to wait.... > > > Here some news: > We finally got windows slave up and running. So, now we can build Vms > for all 3 platforms and test them. > > Now there are 2 things left before releasing updated VMs: > - test why windows VM crashing randomly > - create an job for building 1-click package. > > P.S. An automatic builds often detecting various discrepancies here > and there, since it doing everything from scratch every time, > which you usually don't do if run things manually. > Which is good, because it helps us to ensure that things we do are > reproducable, but it means having more work :) > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 21, 2012

Re: [Pharo-project] Pharo VM

by Igor Stasenko

On 21 February 2012 16:50, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > I'm asking because Stef mentioned that and I told it to a friend that > should create and maintain Fedora packages for Pharo. So he naturally > decided to wait.... > Here some news: We finally got windows slave up and running. So, now we can build Vms for all 3 platforms and test them. Now there are 2 things left before releasing updated VMs: - test why windows VM crashing randomly - create an job for building 1-click package. P.S. An automatic builds often detecting various discrepancies here and there, since it doing everything from scratch every time, which you usually don't do if run things manually. Which is good, because it helps us to ensure that things we do are reproducable, but it means having more work :) -- Best regards, Igor Stasenko.

Feb. 21, 2012