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

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

by Holger Hans Peter Freyther

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 Camille Teruel

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. > > 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

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

by Frank Shearar

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). 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

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

by Camille Teruel

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. 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. 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

Re: [Pharo-project] Fwd: Some question and request for Athens

by Tudor Girba

Indeed, I second the newbie question: how do we set TrueType fonts :)? Doru On Tue, Mar 26, 2013 at 11:29 AM, Tristan Bourgois < tristan.bourgois(a)gmail.com> wrote: > 2013/3/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > > > > Begin forwarded message: > > > > From: Igor Stasenko <siguctua(a)gmail.com> > > Subject: Re: Some question and request for Athens > > Date: March 25, 2013 2:57:33 PM GMT+01:00 > > To: Tristan Bourgois <tristan.bourgois(a)gmail.com> > > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, LE PORS Eric > > <eric.lepors(a)fr.thalesgroup.com> > > > > On 25 March 2013 11:45, Tristan Bourgois <tristan.bourgois(a)gmail.com> > wrote: > > > > Hi Igor! > > > > I have some questions and request for Athens :) > > > > 1 Do exist a possibility in Athens to draw a Surface on a Surface? > > For example : > > aSurf drawSurface: anOtherSurface at: aPosition > > (I need it for draw image on a surface) > > > > > > yes. You can use Forms or surfaces as paints so they act like 2D > textures: > > > > canvas setPaint: someSurface. > > canvas drawShape: myRect. > > Thanks that's works fine :) > > > > > 2 About my first question, I try to draw a png image on a Surface and > > I get some strange behavior. When nothing is applied on my first > > surface and draw the image in a rectangle path I crash the VM! > > This an example I tried and crash my VM: > > > > |surf pharoLogo ref path patternPaint| > > surf := AthensCairoSurface extent: 600@600. > > > > ref := 'pharo.png' asFileReference. > > pharoLogo := AthensCairoSurface createFromFile: ref fullName > ifFailed:[nil]. > > > > surf drawDuring: [:can| > > surf clear. > > patternPaint := can setPaint: pharoLogo. > > patternPaint setExtend: #None. > > can drawShape: (0@0 extent: pharoLogo extent). > > ]. > > Display getCanvas drawImage: surf asForm at: 0@0. > > > > If you need more information about the crash and my environment ask it :) > > > > weird... it should be working fine. > > I try it on a new clean image and again get a VM crash. > > > 3. Do exist something in Athens to create some text and get the extent > > of the text? I tried to draw text but I only succeed to draw a text > > without font (only width) and I don't found how to get the extent of > > this text :( This is really important for the next of the porting > > because I'm blocking on that and the textModel is not necessary for > > the next of my work because they already have a layoutManager for the > > text. > > > > You can use freetype to measure text extent. Please look how i doing it > with > > AthensTextScanner. > > Because the default methods of freetype using rounding for font size(s), > > which is not really nice. > > I added more precise methods, which do not do any rounding and using > > them for measuring > > text extent. > > > > Try this: > > > > text := 'asdsdgs' asText. > > lines := (AthensTextComposer scan: text for: AthensTextScanner new) > lines. > > > > lines first width. > > > > will give you the width. > > > > (but for that to work, your default font should be TTF font) > > Sorry for the newbie question but how I can change the default font to TTF > font? > > > Thanks Igor :) > > > > Tristan > > > > PS: The porting advance as well :) I have animation and that's really > > amazing :) > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 26, 2013

Re: [Pharo-project] Fwd: Some question and request for Athens

by Tristan Bourgois

2013/3/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Begin forwarded message: > > From: Igor Stasenko <siguctua(a)gmail.com> > Subject: Re: Some question and request for Athens > Date: March 25, 2013 2:57:33 PM GMT+01:00 > To: Tristan Bourgois <tristan.bourgois(a)gmail.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, LE PORS Eric > <eric.lepors(a)fr.thalesgroup.com> > > On 25 March 2013 11:45, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: > > Hi Igor! > > I have some questions and request for Athens :) > > 1 Do exist a possibility in Athens to draw a Surface on a Surface? > For example : > aSurf drawSurface: anOtherSurface at: aPosition > (I need it for draw image on a surface) > > > yes. You can use Forms or surfaces as paints so they act like 2D textures: > > canvas setPaint: someSurface. > canvas drawShape: myRect. Thanks that's works fine :) > > 2 About my first question, I try to draw a png image on a Surface and > I get some strange behavior. When nothing is applied on my first > surface and draw the image in a rectangle path I crash the VM! > This an example I tried and crash my VM: > > |surf pharoLogo ref path patternPaint| > surf := AthensCairoSurface extent: 600@600. > > ref := 'pharo.png' asFileReference. > pharoLogo := AthensCairoSurface createFromFile: ref fullName ifFailed:[nil]. > > surf drawDuring: [:can| > surf clear. > patternPaint := can setPaint: pharoLogo. > patternPaint setExtend: #None. > can drawShape: (0@0 extent: pharoLogo extent). > ]. > Display getCanvas drawImage: surf asForm at: 0@0. > > If you need more information about the crash and my environment ask it :) > > weird... it should be working fine. I try it on a new clean image and again get a VM crash. > 3. Do exist something in Athens to create some text and get the extent > of the text? I tried to draw text but I only succeed to draw a text > without font (only width) and I don't found how to get the extent of > this text :( This is really important for the next of the porting > because I'm blocking on that and the textModel is not necessary for > the next of my work because they already have a layoutManager for the > text. > > You can use freetype to measure text extent. Please look how i doing it with > AthensTextScanner. > Because the default methods of freetype using rounding for font size(s), > which is not really nice. > I added more precise methods, which do not do any rounding and using > them for measuring > text extent. > > Try this: > > text := 'asdsdgs' asText. > lines := (AthensTextComposer scan: text for: AthensTextScanner new) lines. > > lines first width. > > will give you the width. > > (but for that to work, your default font should be TTF font) Sorry for the newbie question but how I can change the default font to TTF font? > Thanks Igor :) > > Tristan > > PS: The porting advance as well :) I have animation and that's really > amazing :) > > > > > -- > Best regards, > Igor Stasenko. > >

March 26, 2013

[Pharo-project] Bug about the multiplyBy with CairoMatrix

by Tristan Bourgois

Hi! I found a bug with the method multiplyBy in the class CairoMatrix. I think the bug come from the fact that you send to the primitive the self in the result field and also in the parameter field (I found the difference using the multiply method in VisualWorks and saw the difference on the graphics result of my work): self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self, AthensCairoMatrix * m , AthensCairoMatrix * self ) ) For example : a := AthensCairoMatrix new. c := AthensCairoMatrix new. c rotateByDegrees: 40. c translateBy: 50@50. a := a multiplyBy: c. a AthensCairoMatrix ( sx: 0.766044443118978 shx: 0.6427876096865393 shy: -0.6427876096865393 sy: 0.766044443118978 x: 6.1628416716219405 y: 70.44160264027587 ) If you just swap the 2nd field with the 3rd field the result change: self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self, AthensCairoMatrix * self , AthensCairoMatrix * m) ) a AthensCairoMatrix ( sx: 0.766044443118978 shx: 0.6427876096865393 shy: -0.6427876096865393 sy: 0.766044443118978 x: 50.0 y: 50.0 ) (the graphic result are good with the 2nd option and I have the same result with VisualWork) I think the problem come from this part of the doc of Cairo: "void cairo_matrix_multiply (cairo_matrix_t *result, const cairo_matrix_t *A, const cairo_matrix_t *B); Multiplies the affine transformations in a and b together and stores the result in result. The effect of the resulting transformation is to first apply the transformation in a to the coordinates and then apply the transformation in b to the coordinates." Because of Cairo change the result first with the new matrix A and store it in the result you change too the 2nd matrix after his application. I think to avoid some edge effect it will be more clean to send a new matrix for the result matrix and not "self". What do you think? Tristan.

March 26, 2013

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

by stephane ducasse

yes for example. Stef On Mar 26, 2013, at 11:02 AM, Tudor Girba <tudor(a)tudorgirba.com> 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? > > 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 stephane ducasse

Camille excellent idea!!! Stef On 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 >

March 26, 2013

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

by stephane ducasse

> > Another thing is: this is why I *beg* people to review fixes. > If nobody reviews, I just do what *I* think is right. This can be completely wrong, > of course. Yes but it takes time and we are few so we should not stress. I think that integrating big chunks is important too. I will come back to reviewing code :) Stef > > Marcus >

March 26, 2013