November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ConfigurationOfMocketry + Help

by laurent laffont

On Mon, Nov 29, 2010 at 10:20 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > Hello, I am very glad to your work. > > I try configuration in pharo1.1. Loaded without problem. And Mocketry tests > green. > > Why you add SMock to Core group? > Because I'm ignorant :) What is SMock exactly ? Indeed I've never used Mocketry but I want to package existing mocking frameworks for Pharo. > SMock only needed for MocketryTests. And if you need mocks just use > Mocketry. > I think SMock should has separate configuration > You mean ConfigurationOfSMock ? > > I added you to Mocketry project. > Thank you Laurent > > Best regards, > Denis > > 2010/11/29 laurent laffont <laurent.laffont(a)gmail.com> > > Hi, >> >> I've created a ConfigurationOfMocketry + HelpSystem help (package >> Mocketry-Help). >> >> Actually all is my personnal repository >> http://www.squeaksource.com/LaurentLSandbox. >> >> Johan, Denis can you check these packages ? Then I will >> put ConfigurationOfMocketry in MetacelloRepository. >> >> Can I commit Mocketry package with Help in Mocketry repository ? >> >> Cheers, >> >> Laurent Laffont >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ >> > >

Nov. 30, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Alexander LazareviÄ

This is great Marcus! Alex 2010/11/29 Marcus Denker <marcus.denker(a)inria.fr> > Hi, > > So we finally have a Hudson: > > http://pharo-ic.lille.inria.fr/ > > - one Linux Builder Slave machine > - Builds and runs tests of Core 1.1 > - loads updates and runs tests Core 1.2 > > For now, it builds once per day. Starting tomorrow, 1.2 will be build > automatically after an update. > > More to come... (e.g. builds of the full release, One-Click... Mac > Slave...) > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Nov. 30, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Stefan Marr

Hi Eliot: On 29 Nov 2010, at 23:31, Eliot Miranda wrote: > Is there an easy way to have change sets filed out with LF instead of the horribly incompatible CR? > > Are conversion scipts of help? I depend on the following: Turns out, an error that lead me to believe there are problems with LF changesets had another cause. (a missing line end at the end of the file) So, now I guess, the only thing to do to avoiding the CR line endings in change sets is to convince you guys that CR is not the standard line ending on OS X, and completely outdated in general. I would like to suggest to change the behavior of the line-end guessing in MultiByteFileStream to that end. Thanks 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

Nov. 29, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Tudor Girba

Excellent! Doru On 29 Nov 2010, at 23:03, Marcus Denker wrote: > Hi, > > So we finally have a Hudson: > > http://pharo-ic.lille.inria.fr/ > > - one Linux Builder Slave machine > - Builds and runs tests of Core 1.1 > - loads updates and runs tests Core 1.2 > > For now, it builds once per day. Starting tomorrow, 1.2 will be build > automatically after an update. > > More to come... (e.g. builds of the full release, One-Click... Mac Slave...) > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- www.tudorgirba.com "Every thing has its own flow."

Nov. 29, 2010

[Pharo-project] Issue 3358 in pharo: Another fix for SourceReference

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin.VanRyseghem.Pharo New issue 3358 by Benjamin.VanRyseghem.Pharo: Another fix for SourceReference http://code.google.com/p/pharo/issues/detail?id=3358 Just a little fix which replace 'historical' by '<historical>' Attachments: FixSourceReference.1.cs 1.3 KB

Nov. 29, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Eliot Miranda

On Mon, Nov 29, 2010 at 1:55 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > Is there an easy way to have change sets filed out with LF instead of the > horribly incompatible CR? > Are conversion scipts of help? I depend on the following: /Users/eliot/bin/crdiff /Users/eliot/bin/crtolf /Users/eliot/bin/crfinddefine /Users/eliot/bin/crvi /Users/eliot/bin/crgrep /Users/eliot/bin/lftocr /Users/eliot/bin/crmore Let me know and I can tar 'em up. > And well, how do I convince the import to accept my change sets? > > Related to that, what is the status of this GSoC Project > http://gsoc2010.esug.org/projects/git-mercurial > is that related to http://www.squeaksource.com/Git? > > Thanks a lot > 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 > > >

Nov. 29, 2010

Re: [Pharo-project] Block semantics ....

by Eliot Miranda

On Mon, Nov 29, 2010 at 12:43 PM, James Ladd <james_ladd(a)hotmail.com> wrote: > Hi Eliot, > > I was suspecting you might respond, you really know your stuff. > > I think I'm more confused now that before but in a good way. > I have more information thank to you. > > My need to fully understand blocks is to implement them in Redline. > > Maybe it will be sufficient to 'limit' the use of a block with a > return to the method in which is was defined? > ie: Method A can define the block and send it as an argument, but once > method A has been exited, the block is no longer valid, at least not > the return part. > > Right. That's what one gets with nested functions in Pascal. One cannot return a nested function in Pascal because a nested function's lexical bindings are only valid within the enclosing activation. This allows the implementation to refer to its lexical bindings by reference, either with a "static chain" or a "display". The static chain is the common implementation technique now. The head of the static chain is a copy of the frame pointer of the next lexically-enclosing function, stored in the nested function and its activation. Any lexical binding can be reached by following the static chain. An alternative technique is a "display", which is essentially an array of frame pointers, one for each level of nesting, allowing implementing lexical binding access by a double indirection. But these are only "downward funargs" because they can only be passed down the stack. Smalltalk (and many other languages) provides "full upward funargs" becaue they can outlive their enclosing activation and be returned. > > Does this appear most 'like' how blocks are handled in Pharo? > > Sort of. The main difference is that in Smalltalks derived from Smalltalk-80 activation records are first-class objects and so can outlive their invocation. i.e. a Smalltalk activation is an object, /not/ space on a stack. Under the covers the VM /may/ choose to implement activations in a stack-like manner, lazily creating objects only when needed (which is what Cog and VisualWorks do), but that's a hidden optimization and conceptually creating an activation creates an object. So there is no conceptual problem having a block refer to its enclosing activation after that activation has returned, but obviously the attempt to return a second time must fail because the place to return to is already in use, or has already been returned from. However, apart from return, there is no need to refer to the outer activation to access lexical bindings. The scheme is to copy the values of lexical bindings that can't change while executing a block that refers to them (e.g. arguments and temps assigned to before a block is created but not afterwards), and move the lexical bindings that can change off teh stack into a heap-allocated Array. You can read about this in excruciating detail on my blog in http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/, http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compil… . BTW, the Wikipedia page on the Funarg problem<http://en.wikipedia.org/wiki/Funarg_problem>is a good starting point for a general discussion of closures in programming languages. HTH Eliot > > Rgs, James. > > >

Nov. 29, 2010

Re: [Pharo-project] [ANN] Hudson build server for Pharo

by Miguel CobÃ¡

El lun, 29-11-2010 a las 23:03 +0100, Marcus Denker escribiÃ³: > Hi, > > So we finally have a Hudson: > > http://pharo-ic.lille.inria.fr/ > > - one Linux Builder Slave machine > - Builds and runs tests of Core 1.1 > - loads updates and runs tests Core 1.2 > > For now, it builds once per day. Starting tomorrow, 1.2 will be build > automatically after an update. > > More to come... (e.g. builds of the full release, One-Click... Mac Slave...) Cool! One question, you have the pharo-project.org domain, why isn't this hudson a subdomain of that domain. Hosted on inria, but accessible by the official project domain? Anyway, very good news. I suppose that the download page of pharo will point to the latest successful build link of the hudson server very soon. Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Nov. 29, 2010

[Pharo-project] [ANN] Hudson build server for Pharo

by Marcus Denker

Hi, So we finally have a Hudson: http://pharo-ic.lille.inria.fr/ - one Linux Builder Slave machine - Builds and runs tests of Core 1.1 - loads updates and runs tests Core 1.2 For now, it builds once per day. Starting tomorrow, 1.2 will be build automatically after an update. More to come... (e.g. builds of the full release, One-Click... Mac Slave...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Nov. 29, 2010

[Pharo-project] Changesets with LF/CRLF instead of CR?

by Stefan Marr

Hi: Is there an easy way to have change sets filed out with LF instead of the horribly incompatible CR? And well, how do I convince the import to accept my change sets? Related to that, what is the status of this GSoC Project http://gsoc2010.esug.org/projects/git-mercurial is that related to http://www.squeaksource.com/Git? Thanks a lot 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

Nov. 29, 2010