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

Re: [Pharo-project] [3.0] 9 issues need reviews

by Marcus Denker

On Mar 26, 2013, at 1:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > marcus we should change the first list of bugs because > - there are far too many options in the filter > - we should propose a categorisation > It took me 10 min to find how I can et the list of issue that have been resolved. > For me this is obvious: Klick on 3.0 Integration, done. Marcus

March 26, 2013

Re: [Pharo-project] [3.0] 9 issues need reviews

by Marcus Denker

>>>> >>>> >>> now 15 issues need a review. >>> >> >> now 18 issues need a review. > > How do I see them? Because right now I do not see anything just a long list of issues tagged with if time permits. It should look somewhat like this if you follow the link: Marcus

March 26, 2013

Re: [Pharo-project] [3.0] 9 issues need reviews

by StÃ©phane Ducasse

marcus we should change the first list of bugs because - there are far too many options in the filter - we should propose a categorisation It took me 10 min to find how I can et the list of issue that have been resolved. Stef >> >>> Hi, >>> >>> Even with the integrations of saturday, there was a lot done that need >>> attention: >>> >>> >>> https://pharo.fogbugz.com/f/filters/22/3-0-Integration >>> >>> 6 are ready to be integrated, >>> 9 need a code review. >>> >> now 15 issues need a review. >> > > now 18 issues need a review. > > Marcus > >

March 26, 2013

Re: [Pharo-project] [3.0] 9 issues need reviews

by StÃ©phane Ducasse

On Mar 26, 2013, at 8:38 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Mar 25, 2013, at 8:29 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Mar 24, 2013, at 7:23 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Hi, >>> >>> Even with the integrations of saturday, there was a lot done that need >>> attention: >>> >>> >>> https://pharo.fogbugz.com/f/filters/22/3-0-Integration >>> >>> 6 are ready to be integrated, >>> 9 need a code review. >>> >> now 15 issues need a review. >> > > now 18 issues need a review. How do I see them? Because right now I do not see anything just a long list of issues tagged with if time permits.

March 26, 2013

Re: [Pharo-project] [Pharo-users] More GSoC ideas wanted, 3 days left ....

by stephane ducasse

Janko Can you put andrei chis and nicolas passerini for Debugger improvment projects. I know that alexandre should propose a couple of topics around roassal. I could come up with a couple of other topics. Here is one: > Ideas so far: http://gsoc2013.esug.org/ideas > > To propose an idea just respond to this post by fulfilling this idea > template: > > Title: Better rewriting rule tool > Level: (beginner, intermediate, advanced) Intermediate > Possible mentor: (if already known) Stephane Ducasse > Possible second mentor: (if already known) Andre Hora > > Description The refactoring browser is based on a powerful rewrite engine which transforms AST. However it is quite cumbersome to write rewrite rules. There is a need to build a tool to help programmers defining their own transformation. > Technical Details > > Benefits to the Student learning AST learning AST transofrmation learning AST pattern matching User interface definition > Benefits to the Community A tool that is cruelly missing. > > Best regards > Serge and Janko, > your this year GSoC admins > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

March 26, 2013

Re: [Pharo-project] [Pharo-users] More GSoC ideas wanted, 3 days left ....

by Guillermo Polito

Title: VM simulator in Pharo Level: advanced Possible mentor: Esteban Lorenzano Possible second mentor: Guillermo Polito Description: The VM simulator is a very useful tool when it comes to understand the VM behavior and debugging. However, it does not work in Pharo since long time due to API changes in the core of the system. This project is about bringing the simulator back to life in Pharo to enhance the VM debugging activities. Technical Details: The VM simulator must be ported (or better adapted) and supported by tests. Benefits to the Student: - learn a VM architecture using a higher level language such as Slang to build a VM - understand how several VM components work by debugging and testing them Benefits to the Community: The community will have a tool to debug the VM and be able to evolve it easily. On Tue, Mar 26, 2013 at 12:36 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si>wrote: > Dear Pharoers, > > Ideas are slowly coming, 14 so far, but this is way below the 30+ in > previous years. So, stretch your brain, come with some more ideas, which > will be interesting for potential students and of course useful for our > community. Students you are again welcome to propose such idea by your > own. One student idea for now! > > Ideas so far: http://gsoc2013.esug.org/ideas > > To propose an idea just respond to this post by fulfilling this idea > template: > > Title: > > Level: (beginner, intermediate, advanced) > > Possible mentor: (if already known) > > Possible second mentor: (if already known) > > Description > > Technical Details > > Benefits to the Student > > Benefits to the Community > > Best regards > Serge and Janko, > your this year GSoC admins > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

March 26, 2013

[Pharo-project] More GSoC ideas wanted, 3 days left ....

by Janko MivÅ¡ek

Dear Pharoers, Ideas are slowly coming, 14 so far, but this is way below the 30+ in previous years. So, stretch your brain, come with some more ideas, which will be interesting for potential students and of course useful for our community. Students you are again welcome to propose such idea by your own. One student idea for now! Ideas so far: http://gsoc2013.esug.org/ideas To propose an idea just respond to this post by fulfilling this idea template: Title: Level: (beginner, intermediate, advanced) Possible mentor: (if already known) Possible second mentor: (if already known) Description Technical Details Benefits to the Student Benefits to the Community Best regards Serge and Janko, your this year GSoC admins -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 26, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by StÃ©phane Ducasse

I passed your mail to noury and luc because they got a lot of trouble with the socket code. On Mar 26, 2013, at 12:12 PM, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > Hi, > > I am porting a tooling class that I wrote on GST for my SIP and MGCP code > to Pharo. This class will create a socket and then fork a RX and TX process. > I have some issues with 'stopping' the socket. I have created an example > that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to > have more debug output with a re-compiled one). > > > | s rx | > s := Socket newUDP. > rx := [ > [s waitForData. s halt] > on: ConnectionClosed do: [ s halt] > ] fork. > "Wait for the process to hit the readSemaphore" > (Delay forSeconds: 3) wait. > s close. > > > My expectation is that I will get the ConnectionClosed signal or at least > that >>#waitForData will return once the socket is closed. This is based > on reading the comment of >>#waitForData. > > > The Socket>>#waitForData documentation reads like this: > "Wait for data to arrive. This method will block until > data is available or the socket is closed. If the socket is closed > a ConnectionClosed exception will be signaled." > > > I had a look at the socket plugin and the following is happening. First > aio is disabled, the state set to ThisEndClosed, then ::close is called > and in the above case the result is '0' and the following code will be > executed: > > else if (0 == result) > { > /* close completed synchronously */ > SOCKETSTATE(s)= Unconnected; > FPRINTF((stderr, "closeConnection: disconnected\n")); > SOCKET(s)= -1; > } > > > this means that my 'rx' process will happily wait on the readSemaphore > of the Socket and will never be woken up. > > > My question are probably: > > 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? > 2.) How should I terminate my RX process? > > kind regards > holger > > PS: The issue is probably socket specific and not related to UDP. >

March 26, 2013

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

by stephane ducasse

On Mar 26, 2013, at 12:05 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > That includes both Francisco Garau's and Santiago Bragagnolo's work on > Concrete Type Inference, yes we should build on top of them. I wish francisco would like to continue pushing his master with us but he is busy with banks :) > Roel Wuyt's RoelTyper and my own tiny > inference engine in SqueakCheck > (http://www.squeaksource.com/SqueakCheck/ and its ConfigurationOf > might well need fixing for Pharo). > > frank

March 26, 2013

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

by Frank Shearar

On 26 March 2013 11:11, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 mars 2013, at 12:05, Frank Shearar wrote: > >> On 26 March 2013 10:51, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>> On 26 mars 2013, at 11:02, Tudor Girba wrote: >>> >>> 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? >>> >>> >>> Do you mean that type information could be gathered on object inspection? >>> If so it's a cool idea and the same thing could be done with a debugger. >> >> As an example, since you know the actual type of all variables and >> method arguments, you can use that information when writing code in >> the debugger: you've just written a message send to some variable but >> that that variable's class doesn't understand that message, for >> instance. (This should be a warning, not an error.) >> >>> I just didn't want to force the student to develop new type inference >>> mechanisms because some solutions already exist in Pharo. >>> The project is more about making cool tools that use type information >>> provided by an existing solution. >> >> That includes both Francisco Garau's and Santiago Bragagnolo's work on >> Concrete Type Inference, Roel Wuyt's RoelTyper and my own tiny >> inference engine in SqueakCheck >> (http://www.squeaksource.com/SqueakCheck/ and its ConfigurationOf >> might well need fixing for Pharo). > > Thanks Frank, I wasn't aware of your engine, I will have a look on it. It's absolutely teeny: the summary of the project is that I add a TheoryTestCase, which runs the usual test* methods, and also finds methods marked with a <theory> pragma. A theory is a parameterised unit test, allowing you to throw randomly generated data at your theory. For instance you might check for right identity for #+: rightIdentity: x <theory> self assert: x class zero + x equals: x + x class zero and the engine (TheoryTyper) will see that you've sent #+ to x, and #zero to the class of x. It will look over the image to see what classes understand that mini protocol, and call the appropriate generator to throw data at the test. In this example, it'll generate Integers, Floats and ScaledDecimals. frank >> frank >> >>> Doing both tasks would be too much work for one student. >>> However, if the existing solutions don't fit the tool the student wants to >>> develop he is still free to improve them. >>> >>> >>> 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