- Pharo-dev - lists.pharo.org

Fwd: [Pharo-users] [SummerTalk] Refactoring in Pharo

by Damien Cassou

---------- Forwarded message ---------- From: Mark Rizun <mrizun(a)gmail.com> Date: Mon, Jun 2, 2014 at 4:19 PM Subject: [Pharo-users] [SummerTalk] Refactoring in Pharo To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Hi guys! I'm happy to announce you, that I will be working on SummerTalk project entitled "Refactoring in Pharo" with RMoD. Obviously, it's about refactoring system in Pharo. The goal of this project is to improve existing refactrings in Pharo and add some new ones. If you are interested in this topic please visit my blog for more details: http://myfuncoding.blogspot.com/ After some work is done, I'll publish info here and on my blog. Also, source code will be available on my smalltalkhub, and it's going to be soon ;) Thoughts and feedback are welcome. Cheers, Mark -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 2, 2014

Re: [Pharo-dev] String deduplication

by Chris Muller

This is a normal pattern in application-development. For example, Todd Blanchard's HTML validating parser grabs a huge chunk of HTML, and all the parts are simply referenced by position within that big String. On Mon, Jun 2, 2014 at 8:26 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Le 30 mai 2014 Ã 09:39, Philippe Marschall a Ã©crit : > >> Hi >> >> This is an idea I stole from somebody else. The assumption is that you have a lot of Strings in the image that are equal. We could therefore remove the duplicates and make all the objects refer to the same instance. > > > I worked on a String optimisation for a Java virtual machine dedicated to small hardwares. > A string was represented by an array of bytes (UTF8 or ASCII encoding), a start position, and the number of characters of the string. > It allows to reuse the internal byte array for different strings but the String object was different for each String. > With this approach, you are able to save a lot of memory (but with some CPU overhead) and you don't have a problems because you have different String objects for each String. > > ex: b1: 'Hello World! It's a sunny day' > > 'Hello World! It's a sunny day' : start = 0, count = 29, value b1 > 'Hello' : start = 0, count = 5, value b1 > 'Hello World!' : start = 0, count = 12, value b1 > 'World': start = 6, count = 5, value b1 > > > I don't see how it may be applied to Smalltalk and it makes sense. > > Christophe. >

June 2, 2014

Re: [Pharo-dev] GPU accelerated GUI

by J. Vuletich (mail lists)

Quoting Ben Coman <btc(a)openinworld.com>: > Esteban A. Maringolo wrote: > >> I don't know how long will it take to revamp Morphic, last time I saw a >> demo of it at Smalltalks conference (~circa 2007/8), it was really >> promising, but didn't hear about it again. Regards, Esteban A. >> Maringolo > > > It seems Juan was concerned about his new methods being patented by > someone else.Â Maybe we'll see more again publically soon. > http://forum.world.st/Morphic-3-defensive-disclosure-td4727197.html > > cheers -ben > Â > > Â Thanks Ben. That's true, the most important ideas are already protected. I hope to have a working version before the end of this year. There will be some performance impact, mostly due to the use of Float geometry instead of SmallInteger. Hopefully Eliot's Spur with immediate Floats will compensate for that. But I have done some benchmarks, and the Morphic 3 graphics engine is twice as fast as Cairo, and almost as fast as AGG (Anti-Grain Geometry). Cheers, Juan Vuletich

June 2, 2014

Re: [Pharo-dev] GPU accelerated GUI

by J. Vuletich (mail lists)

Hi Esteban, Quoting "Esteban A. Maringolo" <emaringolo(a)gmail.com>: > I couldn't tell exactly, I haven't used Cuis in the last year or so, > but at that time (Pharo 2 was new) it was the faster of the three > brothers (Pharo/Squeak/Cuis). > > Maybe that changed lately and Cuis got slower too. Apparently it is > very easy to bloat Morphic. > > Regards, > > > Esteban A. Maringolo > We are _not_ bloating Morphic in Cuis. Just download a recent image and see for yourself. > > 2014-06-01 21:07 GMT-03:00 darrinm <darrin(a)massena.com>: >>> You get a Cuis image and it's super fast. >> >> What machine are you running on? I just gave the 2009 image of Cuis a try on >> my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just >> dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or >> less which probably half what I see with Pharo. >> >> Is the VM a factor? Should I try a different one? >> >> Thanks. >> >> >> >> -- >> View this message in context: >> http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> Cheers, Juan Vuletich

June 2, 2014

Re: [Pharo-dev] GPU accelerated GUI

by J. Vuletich (mail lists)

Hi Darrin, Quoting darrinm <darrin(a)massena.com>: >> You get a Cuis image and it's super fast. > > What machine are you running on? I just gave the 2009 image of Cuis a try on > my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just > dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or > less which probably half what I see with Pharo. > > Is the VM a factor? Should I try a different one? > > Thanks. I don't have a Mac at hand right now, but on this I5 Windows 7 notebook, dragging Cuis windows (full content, not just a frame) is smoother and more free of artifacts than doing the same with native Windows windows (for example, file explorers). You might try with the latest Cog VM. In any case, the speed advantage of Cuis morphic can better be seen by opening a FileList on a very large file and scrolling, or scrolling very large lists, or resizing browser windows (with all layout being recalculated 'live'). In any case, you are welcome to continue this discussion at http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org , the Cuis mail list. Cheers, Juan Vuletich

June 2, 2014

Re: [Pharo-dev] String deduplication

by Christophe Demarey

Le 30 mai 2014 Ã 09:39, Philippe Marschall a Ã©crit : > Hi > > This is an idea I stole from somebody else. The assumption is that you have a lot of Strings in the image that are equal. We could therefore remove the duplicates and make all the objects refer to the same instance. I worked on a String optimisation for a Java virtual machine dedicated to small hardwares. A string was represented by an array of bytes (UTF8 or ASCII encoding), a start position, and the number of characters of the string. It allows to reuse the internal byte array for different strings but the String object was different for each String. With this approach, you are able to save a lot of memory (but with some CPU overhead) and you don't have a problems because you have different String objects for each String. ex: b1: 'Hello World! It's a sunny day' 'Hello World! It's a sunny day' : start = 0, count = 29, value b1 'Hello' : start = 0, count = 5, value b1 'Hello World!' : start = 0, count = 12, value b1 'World': start = 6, count = 5, value b1 I don't see how it may be applied to Smalltalk and it makes sense. Christophe.

June 2, 2014

Re: [Pharo-dev] Advice for a newb

by Nicolas Cellier

2014-05-25 0:11 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > And by coincidence... > > > On Sat, May 24, 2014 at 3:05 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> >> >> On Fri, May 23, 2014 at 11:12 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> By all means use the change list for crash recovery, or even change >>>> sets. But unlike change sets, Monticello's updates provide support for any >>>> number of steps. Typically with a change set you have to manually reorder >>>> things. >>>> >>> >>> Yes >>> >>> >>> I've used change sets a lot in the past to pull off a number of >>>> "adventurous" system changes. But now I'm familiar with Monticello it >>>> feels like its by far the best way. >>>> >>> Yes but it depends which changes he is doing. Imagine a change that >>> break MC. >>> >> >> If it is possible to make the change in the image it is possible to make >> it in MC. One can always order the changes into a set of package versions >> that can be loaded, even if each package modifies only one method. One has >> the post-load script as a place to change things after snapshot >> manipulation, etc. I don't believe that MC can't operate on itself. We do >> this constantly in Squeak trunk. We have yet to break MC such that it >> can't be updated. >> > > Here is a case where MC has been broken (but please read down to the end): > > > Yep, I completely agree with what Eliot and David said. I value the update-stream very much, and I think it's a mistake to abandon such a golden feature. An image is not just made of code... Even in case we just use it for coding, some code is too experimental to be shared, too tiny to be published (it means maintaining many feature branches) but too valuable to throw away. For me, the best place for those is experiments is in image: - Because I have the right tools to list/find/browse those experiments, I don't want to store them in a file somewhere then forget about them. - Because I have the right tools to maintain those experiments up to date with trunk, I don't want them to rot somewhere on a hard disk. - Because I don't need to deal with load order again and again (I'm often messing with Kernel things), the discipline for building a reloadable configuration for a bunch of small things is not sustainable and has no value as long as it's just for myself. But as we can see, the update stream is not working magically. One has to put his hands in those configurations from time to time. Pharo is using a descendant of Squeak3.9 process rather than mcm, but the problem is more or less the same. It takes time to do it right... And I suspect that the official procedure aimed at making the process repeatable is bypassed sometimes. Because Pharo users value the "throw and rebuild your image" paradigm, the upgrade just has to succeed once, and it does not really matters if the team cheated, as long as they deliver fast. When the image will be truly rebuilt from scratch, this will be even less of a problem anyway. I've been upset (and frustrated) many times when wanting to use Pharo update stream, but now I take it as it is, I can perfectly understand that it's not a priority. My Pharo images are throwaway. Anyway, I experiment in Squeak. > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: Sat, May 24, 2014 at 3:06 PM > Subject: [squeak-dev] Re: What's up on build.squeak.org > To: The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > > > Ah, no, the build is still failing! > Since http://build.squeak.org/job/SqueakTrunk/834/ it's another problem > with: > > MCClassDefinition>>createClass > > I encountered this one while updating some of my old trunk images. > The definition changed in Monticello-cwp.589: > + inEnvironment: (CurrentEnvironment signal ifNil: > [superClass environment]) > - inEnvironment: (EnvironmentRequest signal ifNil: > [superClass environment]) > > But there is no EnvironmentRequest anymore when loading this definition, > so we signal nil, and the load fails. > We would have expected this, it's just be renamed in: > > Environments-cwp.47 > Time: 22 March 2014, 7:53:17.666 pm > Rename EnvironmentRequest to CurrentEnvironment and use it to > implement Environment class>>current. > > To be safe, the rename should have been performed in two stages: > 1) create the new class and migrate customers from the old to the new one. > 2) remove the old one > It would thus have required two updates.mcm and not a single one > (MC lacks a semantic #rename: so it does not work like in-image-tools) > Unfortunately, update-cwp.48 did perform the two operations at once... > > Curiously, if I take an artefact from build server and update, the upgrade > is then processing fine... Don't ask why. > Since no one complained, I told to myself that it was me not following the > standard process, I patched my images manually and restarted the upgrade. > But I now see that it's not just me, there is a CI machine too using > Squeak trunk (anyone else???) > > I have to cheat again with mcm surgery: > - publish an Environments-nice.47 that adds the CurrentEnvironment, but > not removes EnvironmentRequest > - patch update-cwp.48 to point to Environments-nice.47 rather than > Environments-cwp.47 > That'll be in a few minutes... > ----------End Forwarded message ---------- > > so the fix is.... package versions and updates. Yet another thing one can > do is edit updates after the fact. Very powerful. So here is a case where > a broken MC update is fixed after the fact. (and thank you Nicolas!) > > > 2014-05-24 22:58 GMT+02:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > > >> 2014-05-24 22:36 GMT+02:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >> Hi, >>> it seems that most of the builds are red for 2 months. >>> I checked the last artefact for squeak trunk: >>> http://build.squeak.org/job/SqueakTrunk/853/ >>> >>> It's still blocked with the [Warning signal: 'About to serialize an >>> empty package.'] >>> With this warning, a test never time out (I don't know why exactly, but >>> it seems that theProcess monitored by the timeout watchdog is already >>> suspended by the Warning) >>> As a result, the tests do never complete and are aborted after 20 >>> minutes... >>> >>> Chris has fixed the problem since, but it seems that the CI does not >>> upload latest trunk. >>> Why? >>> It seems to be the same problem as the TestRunner: updating triggers the >>> same [Warning signal: 'About to serialize an empty package.'] >>> Ah Chris, it's irony that it's you who precisely keep on fighting modal >>> UI ;) >>> >>> Now the question: how do we escape from this situation? >>> Shall I cheat and modify the update that is blocking? >>> >>> >>> So I decided to cheat: >> I brought update-eem.279 to the surgery block and reverted >> CommandLine-fbs.3 -> CommandLine-fbs.2 >> CommandLine-fbs.3 tried to be smart and workaround the Warning problem, >> but before it had a chance to load, it precisely triggered this Warning!!! >> Since this update is also bringing Chris fix, let's defer >> CommandLine-fbs.3 to next update (eem-280) and cross fingers... >> > > > > -- > best, > Eliot >

June 2, 2014

Re: [Pharo-dev] Pharo and Amber

by Damien Cassou

On Sun, Jun 1, 2014 at 11:19 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Is there an Amber-Pharo one click built with CI > to allow development with both (amber for client, > pharo on server). https://ci.inria.fr/pharo-contribution/job/Tide/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 2, 2014

Re: [Pharo-dev] ExternalPipe>>makePipe error

by Damien Cassou

On Mon, Jun 2, 2014 at 7:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > @Damien > That means your answer on SO won't work. And since the VM doesn't come with the OSProcess plugin (at least it's not in the Plugins directory), there's no easy way of solving this other than updating ConfigurationOfPythonParser, I guess. I will see if I can make a stable configuration that does not use gitfiletree -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 2, 2014

Re: [Pharo-dev] WhatsUp from: 2014-06-02 until: 2014-06-15

by Ben Coman

seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: > * PharoLaserGame tutorial. * Fine tuning some things is Pillar. > > > ### What's next, until 2014-06-15 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > > > * Just the same.

June 2, 2014