January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] Smalltalk website tricks

by Dimitris Chloupis

Does not render well on my iPad and has problems with multi touch, looks cool though :) On Thu, 21 Jan 2016 at 19:19, Craig Latta <craig(a)netjam.org> wrote: > > Hi-- > > I wrote a new website for Black Page Digital, my consultancy in > Amsterdam and San Francisco. It includes SqueakJS running in a 3D CSS > viewport, kinda cute. Please check it out, pass it on, and let me know > what you think! > > > http://thiscontext.com/2016/01/21/new-website-for-black-page-digital > > > thanks, > > -C > > -- > Craig Latta > Black Page Digital > postbus 10784 > 1001ET Amsterdam, Netherlands > craig(a)blackpagedigital.com > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > >

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

Hi Phil-- > ...prior art is not running on my environment. So, it is irrelevant > for my current activities. You weren't talking about your current activities before, you were talking about some allegedly innovative capability. At any rate, I do have versions of Context for Pharo and other Smalltalks, which I intend to release this year. I wanted to deal with SqueakJS after Squeak, then Pharo, then VisualWorks, etc. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo on Bountysource Salt

by Esteban A. Maringolo

I just became a Gold Supporter of the team and helped it reach its $100 minimum salt. I think if we promote it enough, we can get much much more than that. Regards! Esteban A. Maringolo 2016-01-21 6:45 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > We have set up a Pharo on the new Salt platform of bountysource: > > > https://salt.bountysource.com/teams/pharo > > This is an easy way to support pharo development. If you support > above a certain threshold, being a Salt supporter includes a > membership for the Pharo Association. > > > Marcus >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] GitHub API Bindings: new version

by Skip Lentz

Hi Thierry, I pushed a commit which provides GitHub class>>initializeAnonymously, so if you load from the master branch it should be there. I updated the first chapter of the docs too: https://balletie.github.io/GitHub/html-chap/index.html <https://balletie.github.io/GitHub/html-chap/index.html> > On Jan 21, 2016, at 2:00 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2016-01-21 13:49 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > Hi Thierry, > > Good question, and yes it is possible. > Itâs good that you raise this point, I will add a class side instance creation method for this to the GitHub class. > What is nice is that this lowers the barrier for people to try the bindings out. > > I was thing of being able to use it as a Metacello-based code delivery conduit, especially since if I combine that with GitFileTree loading from a zip approach, then it could become an all-in-memory approach (no git installation, no external filetree) > > Do note that you are rate-limited to 60 requests _per hour_ if you donât authenticate. So itâs not much. > > I'll keep that in mind if it takes many requests to get the full history. > > If you use some functionality which requires authentication (for example requesting the logged in user), > you will get a GHBadCredentialsError with a message âRequires authenticationâ. Makes sense to me. > > Yes, this would be perfect. > > Thanks! > > Thierry > > > Skip >> On Jan 21, 2016, at 1:37 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Skip, >> >> this is great; I think you have something important there, and I'm just sad to have far too much to do to contribute... I'd just have a question then: is it possible to use it in anonymous mode? I would like to explore if it could be used as a way to get delivery mode (read-only access) to packages with history/versionning (reusing GitFileTree `build MC metadata from git log` code). >> >> Regards, >> >> Thierry >> >> 2016-01-21 11:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: >> Hi everyone, >> >> I am announcing a new version for the API bindings to GitHub in Pharo. >> For documentation and information on how to load it, see the new project homepage: >> >> https://balletie.github.io/GitHub/ <https://balletie.github.io/GitHub/> (generated with Pillar. Plug for Damien and Cyril) >> >> For a list of changes in this release, follow this link: https://github.com/Balletie/GitHub/releases/tag/v0.5 <https://github.com/Balletie/GitHub/releases/tag/v0.5> >> >> To load absolutely everything, including the tests and the tool, evaluate: >> >> Metacello new >> baseline: 'GitHub'; >> repository: 'github://Balletie/GitHub:master' <>; >> load: #(tests tool) >> >> If you have loaded the tool, it can be opened via the world menu, under âToolsâ. >> >> Feedback welcome :) >> > >

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by phil＠highoctane.be

On Thu, Jan 21, 2016 at 10:33 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > > Le 20 janv. 2016 Ã 20:09, Craig Latta a Ã©crit : > > > Hi all-- > > Phil writes: > > The point is not to clean but to start with an empty object engine and > > fill it in with the minimum required core. Currently, the image is > > the result of an evolutionary process and rebuilding it from zero was > > not possible. > > > Another approach is to modify the virtual machine so that it marks > methods as they are run, and modify the garbage collector to reclaim > methods that haven't been run. Then you can create systems that consist > of only what is necessary to run unit tests, effectively imprinting the > unit tests. You can interact with the target system from completely > independent one over a remote messaging network connection, so your unit > tests need not include graphics support, etc.[1] This seems much simpler > to me than making a virtual machine that can run multiple object > memories, and distributed object memories have several other important > uses too. > > > > Guillermo also implemented this kind of approach with Tornado. > "Tornado, a technique to dynamically tailor applications to only embed > code (classes and methods) they use. Tornado uses a run-fail-grow approach > to prepare an application for deployment. It launches minimal version of an > application and installs a minimal set of statements that will start the > user's application. This ap- plication is run and these statements are > executed. When the application fails because there are classes or methods > missing, the necessary code is installed. > *Extended results of Tornado: A Run-Fail-Grow approach for Dynamic > Application Tayloring (PDF Download Available)*. Available from: > https://www.researchgate.net/publication/278629977_Extended_results_of_Torn… > [accessed Jan 21, 2016]." > > But is not so easy ... > > > This makes it possible to audit the whole build process, create > > different base image for various purposes (very small, headless with > > no UI objects at all, using the object engine in a completely > > different way that is used today). > > > That makes the image the result of a fully reproducible process, from > > a file of zero bytes, to a file with a working image. > > > You can do all of these things with imprinted unit tests as well. > > Also, this allows to experiment with new low level mechanisms. This is > > currently not possible since it makes us like performing surgery on > > our own brain. > > > With remote messaging, which has been around for many years, you > can perform this surgery from afar. > > Not available in my Pharo environment. Which is what I use and care about. > > Also, the Oz-inspired system will help in exploring other image > > memories (small or large) and manipulate them as entities. At this > > point, this is also not common pratice. > > > This has been common practice since the introduction of the virtual > machine simulator in 1996. The remote facilities I mentioned all work > under simulation, too. > > Simulator not working under Pharo currently. Same issue. > > There's a lot of prior art here. > > Sure, but prior art is not running on my environment. So, it is irrelevant for my current activities. Phil > > -C > > [1] http://netjam.org/context > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > >

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by Guillermo Polito

Peter, The point is that âcleaning the imageâ is - not reproducible. A cleanup script may work with todayâs image but may not work with tomorrowâs one. - Itâs not only about cleaning. Imagine you observe that the tables keeping Unicode mappings are wrong. And there is no code to reproduce them. - it does not scale when it starts to become circular. For example, you want to refactor a part of morphic => but you are use morphic while the refactor is performed. We do that all the time, but at the cost of splitting and staging changes that require to be atomic, which adds more complexity to the process. Craig, Yes, Spoon was indeed an inspiration. However, some notes on top of your comments: - Oz/Espell's existing implementation works by introducing two object memories in the same VM, yes. However, the goal was to abstract Espellâs user from such detail and have other implementations such as a remote image one. For example, I wrote a prototype of Espell that manipulated an image loaded in the simulator. The result is that you had a high-level API provided by mirrors to manipulate an image without requiring a VM change. However it was also much slower, and required adapting the VM simulator to initialize it with an empty object memory, and being able to call primitives from outside the simulator while keeping the stack coherent. I dropped this prototype because it required a lot of engineering effort and at the same time Spur advanced really quickly, so I did not want to spend time in code that would soon be deprecated. I could however check if I can recover the code. - Also, I would not say that distributed object memories "are simpler" than keeping co-existing object memories, or not at least without exploring itâs flaws also :). A distributed object memory forces you to include in every peer that may receive code a distribution layer (at least sockets, class builder, compiler or serializer + dependencies). And we wanted to go further. We wanted to be able to easily manipulate an image that does not have those features. - The main point was to use the same infrastructure to build an image in an explicit manner (the bootstrap) as well as in an implicit on-demand manner (tornado). And I believe that the bootstrap is a more transparent process where we can control what happens. Guille > On 21 ene 2016, at 2:34 p.m., Craig Latta <craig(a)netjam.org> wrote: > > > Hi Christophe-- > >>> Another approach is to modify the virtual machine so that it marks >>> methods as they are run, and modify the garbage collector to reclaim >>> methods that haven't been run. Then you can create systems that >>> consist of only what is necessary to run unit tests, effectively >>> imprinting the unit tests. You can interact with the target system >>> from completely independent one over a remote messaging network >>> connection, so your unit tests need not include graphics support, >>> etc.[1] This seems much simpler to me than making a virtual machine >>> that can run multiple object memories, and distributed object >>> memories have several other important uses too. >> >> Guillermo also implemented this kind of approach with Tornado. > > Right, I read that in his PhD thesis. That's why I mentioned my > earlier work, when others claimed there was a precedent being set. > >> But is not so easy... > > Sure, I learned that first-hand when I did it. One important thing > I learned is that it's easier and more accurate to install code as a > side-effect of actually running it live, and not through analysis. It's > also useful to have the option of faulting code in when it's missing > from a running target, or pushing it in from a running source. > > > -C > > [1] http://netjam.org/context > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Jan. 21, 2016

Re: [Pharo-dev] [ANN] Pharo on Bountysource Salt

by Guillermo Polito

YES! One-click contribution! :D Just did it. Thanks * 42! > On 21 ene 2016, at 2:26 p.m., Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Jan 21, 2016 at 5:45 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> We have set up a Pharo on the new Salt platform of bountysource: >> >> >> https://salt.bountysource.com/teams/pharo >> >> This is an easy way to support pharo development. If you support >> above a certain threshold, being a Salt supporter includes a >> membership for the Pharo Association. > > I never heard of this before, but its very interesting. I really like > the fee structure - only charging when funds are cashed out**. So if > I might earn some credit by solving some bounties, then I can spend > them on bugs important to me without any transaction friction. > > Thought I'd do a quick background check [2] [3]... > > [1] https://www.bountysource.com/fees > [2] http://www.marketwired.com/press-release/bountysource-raises-11-million-fir… > [3] https://opensource.com/business/13/9/bountysource-CEO-interview > > ** but actually wow, what a business model !!! All those free funds > held... the bank interest probably pays all the operational costs, > plus profit before even they charge that 10% when cashing out. But I > consider that a reasonable trade off if it helps maintain the > credibility. > > cheers -ben >

Jan. 21, 2016

ESUG '16?

by Alexandre Bergel

Hi! Anyone know when ESUGâ16 will take place? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 21, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

Hi Christophe-- > > Another approach is to modify the virtual machine so that it marks > > methods as they are run, and modify the garbage collector to reclaim > > methods that haven't been run. Then you can create systems that > > consist of only what is necessary to run unit tests, effectively > > imprinting the unit tests. You can interact with the target system > > from completely independent one over a remote messaging network > > connection, so your unit tests need not include graphics support, > > etc.[1] This seems much simpler to me than making a virtual machine > > that can run multiple object memories, and distributed object > > memories have several other important uses too. > > Guillermo also implemented this kind of approach with Tornado. Right, I read that in his PhD thesis. That's why I mentioned my earlier work, when others claimed there was a precedent being set. > But is not so easy... Sure, I learned that first-hand when I did it. One important thing I learned is that it's easier and more accurate to install code as a side-effect of actually running it live, and not through analysis. It's also useful to have the option of faulting code in when it's missing from a running target, or pushing it in from a running source. -C [1] http://netjam.org/context -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016

Re: [Pharo-dev] Bad layoutFrame>>#hash

by Ben Coman

On Thu, Jan 21, 2016 at 6:18 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > What about something like this? I'm not very familiar with hashing. Could you explain the benefit of this approach? cheers -ben > > > ^self species hash hashComposer > add: leftFraction; > add: leftOffset; > add: topFraction; > add: topOffset; > add: rightOffset; > add: bottomFraction; > add: bottomOffset > > HashComposer>>#add: anObject > > ^hash := (hash + anObject hash) hashMultiply > > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont > Sent: Wednesday, January 13, 2016 8:34 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Bad layoutFrame>>#hash > > On 13-01-16 18:38, David Allouche wrote: >> Why did you use a single expression instead of using a temporary variable? I find it harder to understand. > > I did find it very slightly easier to understand. It is not a strong opinion however. > > The ideomatic smalltalk would be > > ^#(leftFraction leftOffset topFraction topOffset rightFraction rightOffset bottomFraction bottomOffset) > inject: self species hash into: [:hashValue :selector | > (hashValue + self perform: selector) hashMultiply ] > > but that would be slower. > > I would be tempted to add a binary message > > Integer>>+** aNumber > ^(aNumber +self hash) hashMultiply > > (I'd prefer +#*, but that doesn't parse) > > hash > ^self species hash +** > leftFraction +** leftOffset +** > topFraction +** topOffset +** > rightFraction +** rightOffset +** > bottomFraction +** bottomOffset > > > > Stephan > > >

Jan. 21, 2016