March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 3.0] #30013

by stephane ducasse

>>>> >> >> It totally agree. >> However we could have cleaned the senders of those deprecated first, because DNUs will appear eventually. Ok then this is ok to me. > > normally the person who deprecates a method should fix all senders. > I was so sure that this is the case that I did not even check. yes > > Marcus

March 26, 2013

Re: [Pharo-project] GSoC13: Google Summer of Code started, your ideas please!

by Tudor Girba

I like this project proposal. A little addition would be to add type inference for code written in the inspector where we already have concrete types that we could leverage for development tools. Would you consider that? Cheers, Doru On Tue, Mar 26, 2013 at 10:51 AM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > Hi Janko, > > Here is another project proposition. > Programming tools for Pharo based on Type Inference > > > Level: intermediate/advanced > > Possible mentor: Camille Teruel > Possible second mentor: StÃ©phane Ducasse > > Description: Type inference mechanisms can be used to compute the types of > variables from the source code. This information is very interesting in the > context of a dynamically-typed language like Smalltalk. Several type > inference tools already exists for Smalltalk but the type information they > bring has not revealed all its potential yet. The student will have to > leverage this type information with new programming tools. > > Example of such tools are: > > - Code analysis tools: > - better "implementors of" and "senders of" lists > - dead code finder > - Development tools: > - type mismatch hints at compile time > - better code completion > > Technical details: > The student will have to analyze existing type inference tools and choose > an appropriate solution. Then he will have to learn how to build UIs with > Spec. > > Benefits for the Pharo community > > - New useful development tools > - Improvement of existing code base thank to these tools > > Benefits for the student > > - Use a highly reflective dynamic language > - Learn the basics of type inference > - Learn how to make UIs with Spec > - Have an impact on the code base of a large project > > > -- www.tudorgirba.com "Every thing has its own flow"

March 26, 2013

Re: [Pharo-project] GSoC13: Google Summer of Code started, your ideas please!

by Camille Teruel

Hi Janko, Here is another project proposition. Programming tools for Pharo based on Type Inference Level: intermediate/advanced Possible mentor: Camille Teruel Possible second mentor: StÃ©phane Ducasse Description: Type inference mechanisms can be used to compute the types of variables from the source code. This information is very interesting in the context of a dynamically-typed language like Smalltalk. Several type inference tools already exists for Smalltalk but the type information they bring has not revealed all its potential yet. The student will have to leverage this type information with new programming tools. Example of such tools are: Code analysis tools: better "implementors of" and "senders of" lists dead code finder Development tools: type mismatch hints at compile time better code completion Technical details: The student will have to analyze existing type inference tools and choose an appropriate solution. Then he will have to learn how to build UIs with Spec. Benefits for the Pharo community New useful development tools Improvement of existing code base thank to these tools Benefits for the student Use a highly reflective dynamic language Learn the basics of type inference Learn how to make UIs with Spec Have an impact on the code base of a large project

March 26, 2013

Re: [Pharo-project] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Yuriy Tymchuk

Ok, and what if we will change behavior a bit so if no definitions were found it will send the incoming message to enclosed object? This way it will work like phexample but will also allow to define some fancy DSL. On 26 Ð±ÐµÑ. 2013, at 07:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello > 2013/3/26 Camillo Bruni <camillobruni(a)gmail.com> > Definitely StateSpec looks more mature and can be used in a more flexible way. > But I am not a big fan of the pragma magic. Why? > It breaks all tools for me :/. If I see a message send I want to be able to: > - browse it, so I can see who implements it? > - debug it directly to get to the real method. > > SateSpec does indeed help writing readable code by allowing almost grammatically > correct sentences. However I don't think this is the way to program. I am a big > fan of stupid english: > > `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` > > If I want to figure out how the first one works, I can simply browse the > implementors of #should and/or #isKindOf: where is the StateSpec version I am > lost. I have to rely on "contains string literal" to get the sources, for me > that is very strange. > > I think main thing you want is easilly explore all available should syntax. And StateSpecs can be easilly adopted for such task. We can just move all methods with syntax pragmas to single class. So you can open this class and see what available. > > To get implementors of some "should expression" you should use senders search of syntax words instead of implementors. Syntax words in StateSpecs is just method literals ( <syntax: #(be an instance of:)>, #() is just array of symbols). > > Interesting that StateSpecs has more explicit syntax system. How you can explore in Phexample expression: > > object should be true > ? > > You have separate PheMatcher>>be and PheMatcher>>true methods and there is no places in code where you can see that this messages can and should be used together. > But with StateSpecs you should put pragma with explicit expression like: > > Equal>>true: anObject > <syntax: #(be true)> > ^self return: (IdentitySpec pattern: true) > > So with StateSpecs you have full syntax expression at one place which can be easy explored. > And for example to support Phexample mesage #beTrue you should just add another pragma: > > Equal>>true: anObject > <syntax: #(be true)> > <syntax: #(beTrue)> > ^self return: (IdentitySpec pattern: true) > > So with Phexample you can browse implementors of "single word should expressions". But with Phexample if you browse implementors of #be like messages you have no idea how it can be used. > In StateSpecs you should use senders. And with StateSpecs if you browse "any syntax word implementors" by senders seach you will see all possible usage cases. And if I move all methods with syntax pragmas to single class you can easilly see all possible expressions in one place. > > `foo should isKindOf: Bar` vs. `foo should be an instance of: Bar` > > With StateSpecs it should be > > foo should be a kind of: Bar > > And as I said before It is simple task to support all Phexample expressions by StateSpecs pragmas > > Best regards, > Denis >

March 26, 2013

Re: [Pharo-project] GSoC13: Google Summer of Code started, your ideas please!

by Janko MivÅ¡ek

Hi Serge, I also think SciSmalltalk project is important for us so please put it into a our GSoC idea template, then I'll put it on the ideas page. Best regards Janko Dne 10. 03. 2013 15:44, piÅ¡e Serge Stinckwich: > Dear all, > > I would like to propose something related to SciSmalltalk: > https://github.com/SergeStinckwich/SciSmalltalk > This is really important if we want Smalltalk to be accepted in the > scientific community. > I want to submit a project that will only focus on ODE (Ordinary > Differential Equation) solving. > Some preliminary works has already be done in this direction. > > I would like to know if a GSOC student could be hosted in a lab ? > > Regards, > > On Sat, Mar 9, 2013 at 1:03 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> Dear Smalltalkers, >> >> Time for your cool project ideas on this year Smalltalk GSoC! >> >> For now just express any idea you have here on the mailing list. Later >> we will together develop it to be in complete format together with two >> mentors needed. Deadline is end of Mart, so we have three weeks of time. >> To see how fully developed ideas look like please look at 2012 ones at: >> http://gsoc2012.esug.org/ideas. >> >> Note also that students yourselves can propose a GSoC project. So if you >> like to be a student on this year GSoC and have a nice idea, don't be >> shy and propose it here! The community will listen you and guide to the >> really nicely proposed project. Last year 6 student proposed projects >> were accepted and finished successfully! >> >> For the community, start looking around for students. Think about how to >> approach the universities near by you, do you know who to contact >> there, etc. >> >> We are namely preparing an application to this year Smalltalk Google >> Summer of Code under ESUG umbrella, as last year. If accepted, Google >> will pay few stipendiums to students on our Smalltalk projects. >> >> More on our special Smalltalk GSoC 2013 website: >> >> http://gsoc2013.esug.org >> >> I'm specially inviting mentors of all past GSoCs to rejoin the mentors >> mailing list, where we discuss all details about this year GSoC: >> >> http://groups.google.com/group/smalltalk-gsoc-mentors >> >> While students interested on GSoC please join a special Smalltalk GSoC >> mailing list for you: >> >> http://groups.google.com/group/smalltalk-gsoc-students >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 26, 2013

Re: [Pharo-project] [update 3.0] #30013

by Marcus Denker

On Mar 26, 2013, at 9:12 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 mars 2013, at 08:51, Camillo Bruni wrote: > >> >> On 2013-03-26, at 08:24, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> why do we unload deprecated20 now >> >> but it was deprecated in 2.0, so you keep it in 1 version => 2.0 >> and remove it in the next version => 3.0. > > It totally agree. > However we could have cleaned the senders of those deprecated first, because DNUs will appear eventually. normally the person who deprecates a method should fix all senders. I was so sure that this is the case that I did not even check. Marcus

March 26, 2013

Re: [Pharo-project] https://pharo.fogbugz.com : can I have an account there?

by Usman Bhatti

On Sat, Mar 23, 2013 at 4:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > you can get account directly going to the monkey place: > > bugs.pharo.org When trying to create an account, I get invalid email address message. > > > Esteban > > On Mar 23, 2013, at 4:16 PM, Andrei Vasile Chis < > chisvasileandrei(a)gmail.com> wrote: > > > Can I also get an account? > > > > Cheers, > > Andrei > > > > On Fri, Mar 15, 2013 at 10:07 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >> > >> On 2013-03-15, at 21:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >>> Can I get an account, too? > >> > >> done > >> > >>> Doru > >>> > >>> > >>> On Mar 15, 2013, at 5:31 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >>> > >>>> > >>>> On 2013-03-15, at 17:25, "Esteban A. Maringolo" <emaringolo(a)gmail.com> > wrote: > >>>> > >>>>> Will the bugtracker be open one day? > >>>>> > >>>>> Can I have an account? > >>>> > >>>> you're in, request a new password when you connect and everything > should work. > >>>> > >>>>> > >>>>> Esteban A. Maringolo > >>>>> > >>>>> > >>>>> 2013/3/8 phil(a)highoctane.be <phil(a)highoctane.be>: > >>>>>> 'k thx. > >>>>>> > >>>>>> I do use FBZ since quite a while (v3), so good :-) > >>>>>> > >>>>>> 2013/3/8 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > >>>>>>> For now we are just migrating, but soon the doors will be open : > >>>>>>> > >>>>>>> Steps needed before official announcement: > >>>>>>> - Migrate all issues ( we are currently at 7026 issues migrated) > >>>>>>> - Deploy the Penelope website (to register easily to the issue > tracker and > >>>>>>> have a list of open issues) > >>>>>>> - Fix dependency between issues (blockedOn:) > >>>>>>> - Polish a bit statuses in fogbugz > >>>>>>> The plan is to announce it at the same time that the announcement > of > >>>>>>> Pharo2.0 release :) > >>>>>>> > >>>>>>> Ben > >>>>>>> > >>>>>>> On Mar 8, 2013, at 11:13 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >>>>>>> > >>>>>>> patience, patience :D, we will announce that pretty soon. > >>>>>>> until then you can still report on the old issue tracker. > >>>>>>> > >>>>>>> On 2013-03-08, at 10:51, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > >>>>>>> > >>>>>>> How to do? > >>>>>>> > >>>>>>> Guess bug reporting occurs there now. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Phil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "We cannot reach the flow of things unless we let go." > >>> > >>> > >>> > >>> > >> > >> > > > > >

March 26, 2013

Re: [Pharo-project] [update 3.0] #30013

by Sven Van Caekenberghe

On 26 Mar 2013, at 08:51, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-03-26, at 08:24, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> why do we unload deprecated20 now > > but it was deprecated in 2.0, so you keep it in 1 version => 2.0 > and remove it in the next version => 3.0. > > and the earlier we remove them the better can we adapt 3.0. no? I am with Camillo: deprecate it 1 release, remove it the next >> because for me we should unload 1.4 in 30 and 20 in 40alpha. >> Of course people can load it.

March 26, 2013

[Pharo-project] looking for media to illustrate one important idea :)

by Torsten Bergmann

What about Ants: - painstaking - hard-working - diligent You need many of them to clean the woods. Every contribution counts and they work together. http://www.slideshine.de/browser/uploads/94/Ameisen/Ameise%20mit%20Blatt.jpg Also remember the ant simulation in squeak ;)

March 26, 2013

Re: [Pharo-project] [update 3.0] #30013

by Camille Teruel

On 26 mars 2013, at 08:51, Camillo Bruni wrote: > > On 2013-03-26, at 08:24, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> why do we unload deprecated20 now > > but it was deprecated in 2.0, so you keep it in 1 version => 2.0 > and remove it in the next version => 3.0. It totally agree. However we could have cleaned the senders of those deprecated first, because DNUs will appear eventually. > > and the earlier we remove them the better can we adapt 3.0. no? > >> because for me we should unload 1.4 in 30 and 20 in 40alpha. >> Of course people can load it. >> >> >> >> On Mar 26, 2013, at 8:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> 10081 unload Deprecated20 in 3.0 >>> https://pharo.fogbugz.com/f/cases/10081 >> > >

March 26, 2013