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

Re: [Pharo-project] moose job on jenkins

by Camillo Bruni

On 2013-03-19, at 00:52, Ben Coman <btc(a)openInWorld.com> wrote: > Maybe this can be arranged in a lock-step fashion. Updated VMs test against last green image. > Updated image tests against last green VM. that is sort of already happening: (still needs to upgraded to 3.0): - https://ci.inria.fr/pharo/job/Pharo-2.0-Regression-Tests/ - https://ci.inria.fr/pharo/view/VM/job/PharoVM-tests/ - https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/ > Camillo Bruni wrote: >> On 2013-03-18, at 07:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> >>> Hi Camillo, >>> >>> Thanks for the remarks. >>> >>> We (or at least I :)) want to use the latest of everything :). Moose switched to developing on bleeding edge about 7 years ago, and the only thing that still remained fixed was the VM. >>> >>> Now, we work with the latest VM and like that we can check integration and give feedback. I guess this is particularly important now that you chose Moose to be one of the benchmarks for the VM stability. >>> >>> If it will really not work, we will use the stable one, but at the moment, it works :) >>> >> >> ok, so you are fully aware ;), indeed that will help us certainly to find >> bugs in the VM! >> >> >> >>> Cheers, >>> Doru >>> >>> >>> On Mar 17, 2013, at 11:20 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> >>>> Nice! good to see ;) >>>> >>>> Some little remarks: >>>> >>>> - `wget --quiet -qO` can be simplified as `wget --quiet -O -` since -q is just the short form for --quiet ;) >>>> - I would not use the ciPharoVMLatest.sh but ciPharoVM.sh since Latest might break unexpectedly whereas ciPharoVM.sh points to latest stable release >>>> >>>> best cami >>>> >>>> On 2013-03-17, at 22:02, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I put together a little description of how we built the Moose job on Jenkins using the CommandLine infrastructure. Perhaps it is useful for other people as well: >>>>> http://www.tudorgirba.com/blog/moose-4-8-on-jenkins >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Be rather willing to give than demanding to get." >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> >> >> >> >> > >

March 19, 2013

Re: [Pharo-project] [Esug-list] [ANN] Pharo 2.0

by Ben Coman

That is a really impressive amount of work. I really feel like I am betting on a good horse here - a young colt with some great years of racing ahead. cheers -ben stephane ducasse wrote: > For those of you that want to know a bit more: http://code.google.com/p/pharo/w/edit/ActionsInPharo20 > > > Here is a log of all the actions done in 2.0. The idea is not to replicate the bug tracker, as it is easy to get a complete list [http://code.google.com/p/pharo/issues/list?can=1&q=milestone%3D2.0 here]. > Instead, the idea is to have a list of the major improvements with some explanations. > > ==UI== > We started a long term effort on the Pharo UI. > > * *Spec: a new way to build UI.* We started to rethink the way we build user interfaces in Pharo. Spec has been developed by Benjamin van Ryseghem under the guidance of StÃ©phane Ducasse. Spec is based on a declarative syntax to specify user interfaces and on valueHolder port composition. Spec supports widgets definition, reuse and composition. New widgets can be created by composing existing widgets. Many existing tools have been reimplemented using Spec. We wrote a tutorial for Spec. Spec will be used for the UIPainter that we will develop for Pharo 3.0. In Pharo 3.0 we will revisit and improve Spec. One of the idea is that Spec should be independent of Morphic so that we can use it to build native tools or with Amber. > > * *Widget enhancements.* Several important widgets were greatly enhanced. This effort was led by Benjamin van Ryseghem. For example, multiple selection and single selection lists were unified. A new widget list has been developed from scratch and it exhibits massive speed improvements. > > * *Layout improvements/cleanups.* We improved the protocol used for creating LayoutFrame. We cleaned its implementation and simplify clients code. Now instance of layoutFrame are systematically well initialized. Clients do not need to check against nil values and a new protocol avoids to be forced to specify rectangle when only one number is required. > > * *Keybindings.* Keybindings is a new library developed by Guillermo Polito to manage key bindings. We started to use it to define widgets keybinding as well as menu shortcut. In Pharo 3.0 we will systematically rewrite all the hard-coded bindings with it and write a documentation. It supports: > * source code navigation > * running tests > * basic refactoring > * creating classes > * and many more shortcuts: see "Shortcuts Description" in the window menu (triangle on the top right) in Nautilus > > * *New icons (famfam).* Pharo now uses new icons. We are looking for designers that could help us to define the UI look of the future Pharo versions. > > * *"Growl" style notifications.* To avoid to get UI blocked by simple notifications, Pharo now uses a growl like notification systems. > > * *Revamp progress bar.* We started to rewrite the progress bar framework. We introduced the Job class and notification to specify progress bar. > > * *Rectangle intersection improvements.* Rectangle intersection is a central part for UI redrawing and invalidating screen regions. Rectangle intersection is then an important functionality. We started to address the problem of the non-specification of the intersection of non overlapping rectangles. We introduced the intersect:ifNone protocol. As a side effect this improves the damage recording mechanisms and provide a faster system. > > ==Developer tools== > > * *Nautilus browser.* Nautilus, a new code browser has been developed by B. van Ryseghem. It supports: in place hierarchy, groups, refactorings, multiple views, icon navigation and many other features. Nautilus has a plugin infrastructure so everybody can use existing plugin or write new ones. Nautilus is fully navigable using shortcut. In Pharo 3.0 we plan to rewrite Nautilus using Spec. > > * *Critics browser.* From Pharo 2.0 on we want to systematically run rule checking rules. We revisited the SmallLint rules to customize them to Pharo and we better documented them. We developed a new browser that will helps you to apply SmallLint rules. In particular it supports the notion of todos. We can mark an issue as a false positive or as todos and get the bar green. We wrote a complete chapter on the Critics Browser. We will start to work on an infrastructure to systematically evaluate SmallLint rules on the projects published in the Pharo distribution. > > * *Omnipresence of the Refactoring Engine.* We believe that Pharo itself should use the best tools it has to change itself. This is why we decided to introduce the Refactoring Engine and SmallLint rule checkers. Note that this move to integrate extra tool is not against our vision to produce a minimal core. Once we have fast fuel based package loading we will be able to remove Metacello from the core. > > * *Improved version diff browsing.* We improved the diff and merging tool. > > * *Spotlight.* Spotlight is a ubiquitous tool to find classes and methods. You can activate it just press shift+enter. > > * *Revamp E/O Completion and smart chars.* In the past, smart characters (automatically closing parenthesis, single quote...) did not play well with auto completeion. In addition, they were duplicated functionality between two automatic ecompletion algorithms. In Pharo 2.0 we unified the two algorithms under a single umbrella and integrate them smoothly with smart-characters. > > * *Interactive navigation using "ctrl/cmd+click" over classes/methods.* Now Pharo supports the interactive navigation of source code using cmd/ctrl-click on selectors and class names in the source-code [implementors, senders, users]. > > * *Shout themes.* Several syntax highlighting themes have been defined. > > * *Andreas profiler.* As a tribute to Andreas Raab, we included an alternate profiler developed by Andreas. > > ==Networking== > > * *New version of Zinc.* Zinc is developed by Sven Van Caekenberghe. New versions of Zinc the http client/server library has been integrated. > > * *Zodiac (SSL).* Zodiac is an extension of Zinc to support SSL connections. > > ==System== > > * *System Announcer.* Pharo had a change notification system. A change notification system is important because tools can register to events to update or react without getting coupled with the system. The problem was that the previous change notification broadcasted only symbols and not plain objects. It was limiting the power that we can get about first class objects. In addition not all the events were raised and competing with Announcements (announcements raised plain objects). In Pharo 2.0, we redefined system events as Announcements, introduced a System Announcer whose responsibility is to raise announcement for all the events and removed the old SystemChangeNotifier. This sets up the basis for the future communication between tools. > > * *RPackage replacing PackageInfo.* PackageInfo is a way to identify if a method belongs to a package. The implementation is based on dynamic queries. Such queries it leads to problems to produce new generation browser and tools. We defined a new implementation of the package management of Pharo. The idea is to represent package as real objects. In Pharo3.0 we will continue to remove the dependency to PackageInfo. > > * *Manifest: Package metadata.* We introduce the notion of package metadata. Package metadata are used to manage all false positives or todos of SmallLint so that you do not have to check all the time rule results. Each package can now have a class named ManifestNameOfXPackageNameX. It will be the place to add documentation and other information. > > * *Command line tools / Headless mode.* We really want to make sure that Pharo can be used in non interactive mode and that we can pass scripts to it on the command-line. For this reason we continued to work on making sure that Pharo can be used headless. In particular we introduced a new way to handle command line parameters. See `pharoVM my.image --help` and `pharoVM my.image --list` > * st Handle .st source files > * Fuel Handle fuel files > * config Install and inspect Metacello Configurations from the command line > * save Rename the image and changes file > * test Run tests from command line > * update Load updates > * printVersion Print image version > * eval Evaluate directly passed-in one line script > > * *Native boost.* NativeBoost is a library that generates assembly code on the fly. It is used to generate FFI calls. By default [http://www.esug.org/wiki/pier/Conferences/2011/Schedule-And-Talks/Native-bo… NativeBoost] is included mostly for future use. In Pharo3.0 vector graphics will be used and Nativeboost will be used to invoke the graphics primitives. > > * *Ring metamodel.* Ring is a new meta model introduced in Pharo 1.4. It is used to represent code that is not currently executed. Ring has an API that is polymorphic with a subpart of the core executing entities of Pharo (Class and CompiledMethod). This has the nice property that the tools that manipulate such entities can also manipulate ring objects. Hence Ring supports of image browsing. In Pharo 3.0 we will rewrite certain tools to use ring and deprecate some abstractions like pseudo-classes and file packages. > > > * *Fuel.* Fuel is one of the fastest and versatile object serializer. In Pharo 2.0, we decided to use fuel as a default serializer. In particular, on error the execution stack is saved now in fuel format. Therefore it is possible to reopen a debugger on a similar image for debugging purpose. > > * *Freetype fonts.* We offer now a better handling of freetype fonts and their management. > > * *Metacello: a universal package map.* Metacello is a framework to describe is included in the default image. In the future Pharo will be managed by Metacello. The idea also is that once we have fast fuel based package loading we will be able to remove Metacello from the core. > > > ==Kernel== > > * *New object-oriented and powerful filesystem.* The old library to support file was dated and cumbersome to use. This version of Pharo uses FileSystem a new framework developed by Colin Putney. We revisited and integrated deeply into Pharo core. A full chapter is available in the new book http://rmod.lille.inria.fr/pbe2/. The work includes a complete removal of FileDirectory. There is a compatibility package to support the transition. Enjoy the new and clean API. > > * *DateAndTime refactoring.* All the DateAndTime internals are now UTC-based. This prevents bugs in certain edge-cases where the image is moved through different time-zones, most prominently for daylight saving time. > > ==VM== > * Latests cog builds > * SSLPlugin > * FilePlugin enhancements > * SocketPlugin fixes > * Included libraries: freetype2, cairo > > ==Large Cleanups== > * *FileDirectory removal.* FileDirectory the old file system has been removed. It is packaged as a separate package to support migration to Pharo2.0. > > * *Deprecation of old serialization framework.* *ReferenceStream* and *SmartRefStream* are removed. In addition, *DataStream* is cleaned to be only used by Monticello. For a general purpose serializer, use *[http://rmod.lille.inria.fr/web/pier/software/Fuel Fuel]* instead. > > * *Large amount of bugs fixes.* You already guessed in addition we integrated *a lot* of small improvements, cleanups and bug fixes. > > ==Continuous Integration== > * *Zeroconf scripts.* Weren't you fed up not be able to install Pharo from a single command line or to pass it arguments? Using a nice debugger and an interactive environment development does not mean that Pharo developers do not value automatic scripts and love command line. Yes we do and we want the best of both worlds! Since Pharo 2.0, Pharo supports a way to define and handle command line argument and offer zero conf scripts. We even wrote a chapter on them. > Here is a nice start with a zero-conf bash scripts: `wget --quiet -O - http://files.pharo.org/script/ciPharo20PharoVM.sh | bash` > > * *CI for everything.* A new infrastructure to support continuous integration is now in place. > * First new images and vms are mirrored under http://files.pharo.org/ > * Second the key parts of pharo are automatically built on [https://ci.inria.fr/pharo/] > * Third community project can be hosted at [http://ci.inria.fr/pharo-contribution/] > > > >

March 19, 2013

Re: [Pharo-project] moose job on jenkins

by Ben Coman

Maybe this can be arranged in a lock-step fashion. Updated VMs test against last green image. Updated image tests against last green VM. cheers -ben Camillo Bruni wrote: > On 2013-03-18, at 07:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >> Hi Camillo, >> >> Thanks for the remarks. >> >> We (or at least I :)) want to use the latest of everything :). Moose switched to developing on bleeding edge about 7 years ago, and the only thing that still remained fixed was the VM. >> >> Now, we work with the latest VM and like that we can check integration and give feedback. I guess this is particularly important now that you chose Moose to be one of the benchmarks for the VM stability. >> >> If it will really not work, we will use the stable one, but at the moment, it works :) >> > > ok, so you are fully aware ;), indeed that will help us certainly to find > bugs in the VM! > > > >> Cheers, >> Doru >> >> >> On Mar 17, 2013, at 11:20 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> >>> Nice! good to see ;) >>> >>> Some little remarks: >>> >>> - `wget --quiet -qO` can be simplified as `wget --quiet -O -` >>> since -q is just the short form for --quiet ;) >>> - I would not use the ciPharoVMLatest.sh but ciPharoVM.sh >>> since Latest might break unexpectedly whereas ciPharoVM.sh points to >>> latest stable release >>> >>> best cami >>> >>> On 2013-03-17, at 22:02, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> I put together a little description of how we built the Moose job on Jenkins using the CommandLine infrastructure. Perhaps it is useful for other people as well: >>>> http://www.tudorgirba.com/blog/moose-4-8-on-jenkins >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Be rather willing to give than demanding to get." >>>> >>>> >>>> >>>> >>>> >>> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> > > > >

March 18, 2013

Re: [Pharo-project] Pharo 3

by Ben Coman

I wonder.... If the March/April integrations don't break any existing API, and the new debugger runs in parallel with the old one, then maybe that might be a 2.x release, and move to 3.0 only when PackageInfo and the old debugger are ripped out. (of course all dependent on additional load and human resource availability) cheers -ben Camille Teruel wrote: > Hello everyone, > > Since a picture worth a thousand words, here is a summary of the next actions > for Pharo 3: > > > > Note that some tasks in "Later" may be integrated before July. Here "Later" also > stands for "Not planned yet". > > Camille Teruel > > > >

March 18, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-18 until: 2013-03-31

by Guillermo Polito

On Mon, Mar 18, 2013 at 1:03 PM, <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: > > - Working on Hazelnut2 - Some pharo meetings - Some Keymappings cleansings, comments and renamings for 3.0 > > ### What's next, until 2013-03-31 (*): > > - More Hazelnut2 - Some Keymappings cleansings, comments and renamings for 3.0 - Keymappings 101 tuto in blog (for 2.0, cause in 3.0 the api coould change a bit :) - Some test dbxtalk in 2.0 and update configurations > (*) we'll be expecting results by then ;) > >

March 18, 2013

[Pharo-project] SqueakSSL Pharo Implementation Details

by Ron Teitelbaum

Hi All, I would really like to get more details here. The windows specific code is part of the SqueakSSL design. The idea is that each platform uses a native TLS implementation instead of using custom thrown code. If the Windows implementation is using non windows code, then what is it using for TLS? We are using SqueakSSL in production code. It works communicating between linux servers, and windows and mac clients. I would be interested not only in details but also in benchmarks. Ron > From: vm-dev-bounces(a)lists.squeakfoundation.org [mailto:vm-dev- > bounces(a)lists.squeakfoundation.org] On Behalf Of Frank Shearar > Sent: Monday, March 18, 2013 2:38 PM > > > On 12 March 2013 01:55, <commits(a)source.squeak.org> wrote: > > > > David T. Lewis uploaded a new version of VMMaker to project VM Maker: > > http://source.squeak.org/VMMaker/VMMaker-dtl.304.mcz > > > > ==================== Summary ==================== > > > > Name: VMMaker-dtl.304 > > Author: dtl > > Time: 11 March 2013, 9:54:49.662 pm > > UUID: 7381d88a-6574-4f47-9a1e-ad72ddc48520 > > Ancestors: VMMaker-dtl.303 > > > > VMMaker 4.10.14 > > > > Reference Mantis 0007751: Add SSL plugin Add Andreas Raab's > > SqueakSSLPlugin to the update map for source.squeak.org/VMMaker. > > Add SqueakSSLPlugin to the VMMakerTool defaultUnixSpec. > > > > Follow up required: Add platform sources to SVN from Andreas' respository at > http://code.google.com/p/squeakssl for from the oscog branch. > > > > =============== Diff against VMMaker-dtl.303 =============== > > I asked on the Pharo-dev mailing list about their SSL plugin; it seems it's > SqueakSSL with the Mac- and Windows-specific stuff ripped out. > Any chance of the various VM folk getting the same plugin in all the various VMs > so we don't diverge unnecessarily? > > frank

March 18, 2013

Re: [Pharo-project] [Lsehub-staff] 3.0 started

by StÃ©phane Ducasse

Thanks esteban. Where do you publish your update scripts because I would like to integrate some fixes in 3.0a Stef > Hi, > > Today with Marcus we started the 3.0 development. > Now it is on track, and even the jenkins jobs are working and with brand new staging system: https://ci.inria.fr/pharo/view/3.0/. > > Esteban

March 18, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-18 until: 2013-03-31

by Camillo Bruni

On 2013-03-18, at 13:03, 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: - issue cleanup on fogbugz - pharo 2.0 session - pharo 3.0 planning meeting - improvements on webdoc (now it's fully and properly REST based) > ### What's next, until 2013-03-31 (*): - finally pharo 3.0 issues - fix the monkey for 3.0 and fogbugz - finish exporting webdoc for 1.4 and 2.0 - get my language-side JIT on top of NativeBoost working :P

March 18, 2013

[Pharo-project] 3.0 started

by Esteban Lorenzano

Hi, Today with Marcus we started the 3.0 development. Now it is on track, and even the jenkins jobs are working and with brand new staging system: https://ci.inria.fr/pharo/view/3.0/. Esteban

March 18, 2013

Re: [Pharo-project] SSL plugin

by Frank Shearar

OK, fair enough. I'm just rather curious because I've only recently _needed_ SSL, and so it looks like Squeak will start to ship with the plugin. Seeing as both communities share most of the VM infrastructure, it makes sense to keep doing so. So if you guys are happy with the cross-platform-ness of your version of the plugin, it only makes sense to fold that upstream: Dave Lewis has already made steps in VMMaker, but hasn't yet moved source around. And of course the "canonical repository" at https://code.google.com/p/squeakssl/ no longer has a maintainer. frank On 18 March 2013 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > ye, well... that... I didn't remember :) but yes, camillo and me spent couple of days rewriting the plugin to use same library in all platforms (we did the same with the file plugin, btw). > > On Mar 18, 2013, at 5:50 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 18 March 2013 16:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Mar 18, 2013, at 5:41 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> is the same old plugin... but now it works (it was failing) and it builds automatically :) >>>> >>> >>> And I think we retired both the Mac and the Windows special implementations and >>> just use the Unix one on all three architectures. OpenSSL supports all. >> >> Right, because the Mac and Windows ones spoke to the respective >> special crypto libraries. Sounds sensible! (Also, if you support >> OpenSSL you support much more than just Mac, Linux & Windows - the >> BSDs use OpenSSL, for example.) >> >> frank >> >>> Marcus >>> >>>> Esteban >>>> >>>> On Mar 18, 2013, at 11:46 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>>>> Just so I can keep track of commonality between Squeak and Pharo, the >>>>> SSL plugin - is that Andreas' SqueakSSL plugin? >>>>> >>>>> frank >>>>> >>>> >>>> >>> >>> >> > >

March 18, 2013