Planet Smalltalk

May 26, 2016

Pharo Weekly - Pharo Newsletter May 2016

The big news of the month of course is that Pharo50 has been released! This is our most significant release yet. Here are some highlights:

  • The PharoVM is now based on Spur, the new memory management, and it brings with it a 35% speedup!
  • A new unified foreign function interface (UFFI) replaced.
  • …overall all 2400 issue tracker entries closed.

You can read the official announcement here:

http://pharo.org/news/pharo-5.0-released

Pharo Mooc

The Pharo Mooc saw a constant increase of participants with 2700 participants from more than 90 countries. It is entering its fourth week. More information
Pharo 6

With the stable release out, we have started a new development branch. As always, we slowed integrating changes while stabilizing the release, so this new development branch is seeing lots of changes that were held back.

As always, we do not ignore simple (even trivial) changes and have seen already many improvements related to typos, comments, cleanups… as well as some big-ticket items. One example here is support for immutable objects.

64bit Pharo: A Preview

The 64bit version of Pharo was able to run the whole image this week! Here is a screenshot:

8f398205-df62-4920-bd02-944282aff675.png

Sysmocom: Free Software for Mobile Communication

5faf528c-086b-4ab4-9bc0-b42d040726d2.jpg

Sysmocom is a leading provider of Free Software Mobile Communication solutions. In 2012 we have started a long term project to develop a complete ASN1, TCAP, MAP, CAP, GSM stack using the Pharo Object Environment. We have decided to use Pharo because of the increased productivity, the great tooling, the live inspection and if necessary modification of a running system to deploy a critical bugfix. Pharo has allowed us to focus on what is important.

The stack was used to uncover security and privacy issues inherent to the MAP protocol design in 2014/2015. We have used the stack to build a carrier-grade AuthenticationCenter (AuC) and helped a customer to move their production traffic off a proprietary system to ours. We look forward to move a HomeLocationRegister (HLR) into production this year.

Holger Freyther CEO. http://www.sysmocom.de

See http://www.pharo.org/success for more success stories.


Pharo Weekly - Register to the monthly report

Hi,

Some time ago we set up a very low traffic “Pharo Newsletter” Mailinglist.

The idea is that this gets:
	-> a mail for the release
	-> *one* mail at the end of the month with 2-4 topics

It seems to work well. We have until now send two monty mails and the
mail for the Pharo5 release.


If you want to be on it, here is a link to subscribe:

	http://pharo.us11.list-manage.com/subscribe?u=6f667565c2569234585a7be77&id=048680a940

If you follow all blogs, twitter + read all mails, there might not be anything new, but as things
get even hard to follow for me it might be a good way to keep up with the most important things
happening.

And: if you have an idea for content (e.g. highlighting a project or a success story), please get in
touch!

	Marcus

May 25, 2016

German Arduino - New PasswordsPro version available

Torsten Bergmann - Visualize Commit History

Hernán Morales Durand - Visualize commit history in Pharo

Overview This is another GraphViz post for Pharo Smalltalk. A few days ago I committed a working version of GraphBuilder. It was mostly coded by Lukas Renggli and I updated the package to work with the current Pharo images and added minor features (like displaying commit date in the nodes). Installation and Usage To install the package, open the Catalog Browser, select and install GraphViz, or

Torsten Bergmann - GitRepositoryScanner

A small tool to show local FileTree repositories in GTSpotter, as a way to add them into repositories list. Read more.

Torsten Bergmann - Panama Papers: a case for reproducible research, data activism and frictionless data

Want to step into the details of the Panama leak using Pharo? Then continue reading here.

May 24, 2016

Pharo Weekly - Pharo 64 bits… preview :)

Today Clément Béra helped Esteban Lorenzano porting the 32 to 64 bits bootstrap to Pharo. It looks like we have a Pharo 64 bits image on 64 bits VM running on Mac & Linux.
Here is the wonderful screenshot showing the amazing result:
Screen Shot 2016-05-24 at 3.19.23 PM-1.png

Torsten Bergmann - Pharo 64 bit in preparation

Pharo 64 bits image on 64 bits VM running on Mac & Linux. Yay!!! Read more.

Smalltalk Jobs - Smalltalk Jobs – 5/24/16

From the ESUG mailing list.

Hi all,
If you are a Smalltalker, preferably also skilled in Java or other
languages this might be interesting for you.
UML, web services are nice if they are in your skill set as well.
Basic mastery of Dutch is nice, English is mandatory, this is for a
project at least till the end of this year in Amsterdam.
Get in touch with me if you are interested, but since they are in a
hurry: please ASAP.
Thanks,
Rob Vens


Rob Vens can be contacted firstname dot lastname at reflektis.com.


Filed under: Employment

May 23, 2016

Göran Krampe - Spry Performance

When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn't prevent us from playing around and learning something!

In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now... let's go!

Startup time

Spry is pretty fast starting up which obviously has to do with Spry not doing much at all when starting :)

So a trivial hello world being run using hashbang, executed 1000 times from another bash script, takes substantially less time than the same in Python. Useful benchmark? Not really, but obviously we can do scripting with Spry and at least not paying much for startup times! Here are the two trivial scripts and the bash script running them 1000 times:

``` bash

!/usr/bin/env spry

echo "Hello world" ```

``` bash

!/usr/bin/env python

print "Hello World" ```

``` sh

!/bin/bash

Run a trivial hashbang Spry script 1000 times

for run in {1..1000} do ./hello.sy done ```

If we run the above, first for hello.sy and then hello.py, as reported by time: ``` bash

Spry

real 0m4.071s user 0m0.740s sys 0m0.428s

Python

real 0m13.812s user 0m8.904s sys 0m2.324s

Empty shell script for comparison

real 0m2.505s user 0m0.024s sys 0m0.176s ```

Hum! So a trivial Spry script is 3-10x quicker depending on what you count (real clock vs cpu time etc), and... no, it's not output to stdout that is the issue, even a "silent" program that just concatenates "hello" with "world" suffers similarly in Python.

We can of course also compile this into a binary by embedding the Spry source code in a Nim program - it's actually trival to do. The 5th line below could of course be a full script. Since the Spry interpreter is modular we can pick some base modules to include, in this case the IO module is needed for echo to work so we add it to the interpreter on line 3:

nimrod import spryvm, modules/spryio let spry = newInterpreter() spry.addIO() discard spry.eval """[ echo "Hello World" ]""" ..and then we build a binary using nim c -d:release hello.nim and if we run that instead from the same bash loop we get: real 0m0.840s user 0m0.028s sys 0m0.096s

Of course Python can do lots of similar tricks, so I am not making any claims! But still very neat. And oh, we didn't even try comparing to Pharo here :) Startup times is definitely not a strength of Smalltalk systems in general, typically due to lack of minimal images etc.

40 million ints

I wanted to create some fat collection and do some loops over it. Spry has a universal ordered collection called a Block. Smalltalk has it's workhorse OrderedCollection. Nodejs has an Array. Let's stuff one with 40 million integers and then sum them up!

NOTE: The first numbers published were a bit off and I also realized an issue with Cog and LargeIntegers so this article is adjusted.

Pharo 4 with the Cog VM:

  • Populating the collection: 3 seconds
  • Sum the collection using iteration: 15 seconds
  • Populating the collection with 1s only: 2 seconds
  • Sum the collection of 1s (staying within SmallInteger) using iteration: 0.6 seconds!

NodeJS 4.4.1:

  • Populating the collection: 0.6 seconds! (weird! sometimes much slower)
  • Sum the collection using iteration: 3 seconds
  • Sum the collection using reduce: 1.2 seconds

Python 2.7.10:

  • Populating the collection: 7 seconds
  • Sum the collection using iteration: 4 seconds
  • Sum the collection using interation with lambda: 4 seconds!
  • Using sum function: 0.3 seconds!

Spry:

  • Populating the collection: 72 seconds (cough)
  • Sum the collection using iteration: 101 seconds (cough, cough)

Spry with activation record reuse:

  • Populating the collection: 32 seconds (better)
  • Sum the collection using iteration: 60 seconds (better)

Ehum...

NOTES

  • So Cog kicks proverbial ass when not spilling into LargeIntegers! Impressed.
  • NodeJS is fast, we know that, but Cog beats it on the iteration which was interesting. But NodejS populating in 0.6 seconds? Weird! Sometimes it took 10 seconds, it was almost like NodeJS had some odd "warm caching" going on.
  • Spry... is slow :) But a bit of activation record reuse definitely improved it by 2x.
  • Python is definitely surprising me! Wow, especially populating in 7 seconds and summing with lambda in 4? Impressive.

If we spend some time profiling Spry we can quickly conclude that the main bottleneck is the lack of a binding phase in Spry - or in other words - every time we run a block, we lookup all words! Unless I am reading the profile wrong I think the endless lookups make up almost half the execution time. So that needs fixing. And I also will move to a stackless interpreter down the line, and that should give us a bit more.

And what about Python's sum function that did it in whopping 0.3 seconds? Yep, definitely the way to go with an optimized primitive function for this, which brings me to...

Spry Secret Weapon

The secret weapon of Spry!

One core idea of Spry is to make a Smalltalk-ish language with its inner machinery implemented in Nim using Nim data types. So the collection work horse in Spry, the block is just a Nim seq under the hood. This is very important.

Combined with a very simple way of making Nim primitives we can quickly cobble up a 6 line primitive word called sum that will sum up the ints in a block. We simply use the fact that we know the block consists only of integers. I am guessing the sum function of Python does something similar.

Here is the code heavily commented:

```

nimPrim is a Nim macro to make Spry primitives

First argument is the word to bind, second is if

this is an infix word (first argument on the left)

and finally how many arguments the primitive expects.

nimPrim("sum", true, 1): # The local variable spry refers to the Interpreter # evalArgInfix(spry) is a function call that returns # the infix argument evaluated at the call site. # We then cast this to a SeqComposite which is the # abstract super type of Blocks. let blk = SeqComposite(evalArgInfix(spry)) var sum = 0 # This is Nim iteration over the nodes member # of the SeqComposite, a seq of Nodes. for each in blk.nodes:

# We cast the node to IntVal since we know
# it's an int, and then we can get the value member
# which is a regular Nim int.
sum = sum + IntVal(each).value

# All Spry functions returns Nodes so we wrap the int # as a Node using newValue() which will wrap it as an # IntVal. return newValue(sum) ``` It's worth noting that almost all primitive words in Spry are written using this same pattern - so there are lots of examples to look at! Of course this is a bit of "cheating" but it's also interesting to see how easy it is for us to drop down to Nim in Spry. We create a new word bound to a primitive function in exactly 6 lines of code.

So how fast is Spry using this primitive word? It sums up in blazing 0.15 seconds, about 100x faster than Cog and 10x faster than NodeJS for summing up. And yeah, even 2x faster than Python!

And yes, we can easily make this primitive smarter to handle blocks with a mix of ints and floats and a proper exception if there is something else in there - then it ends up being 17 lines of code, and still almost as fast, 0.17-0.18 seconds! I love you Nim.

In summary, Cog - which is what I am most interested in comparing with - is fast but my personal goal is to get Spry within 5x slower in general speed - and that will be a good number for a pure interpreter vs an advanced JIT. And if we throw in primitive words - which is not hard - Spry can be very fast!

May 22, 2016

Torsten Bergmann - Sysmocom

Free Software for Mobile Communication in Pharo. Read more.

May 21, 2016

Pharo Weekly - Pharo 60 Development is starting

60027
18253 formatter misplaces some block comments
https://pharo.fogbugz.com/f/cases/18253

18267 Add Class comments to Refactoring-Core-Model classes
https://pharo.fogbugz.com/f/cases/18267

18284 SmallFloat64 identityHash is answering bad value
https://pharo.fogbugz.com/f/cases/18284

60025
18078 FileSystem>>ModificationTime
https://pharo.fogbugz.com/f/cases/18078

18185 privSaveImageWithCleanup should yield Processor during waiting
https://pharo.fogbugz.com/f/cases/18185

18275 Improve tests coverage of Matrix
https://pharo.fogbugz.com/f/cases/18275

60024
18044 Use iconNamed: instead of relying on DNU [Nautilus]
https://pharo.fogbugz.com/f/cases/18044

18238 PluggableTextMorph is not well update on theme change.
https://pharo.fogbugz.com/f/cases/18238

18227 TestRunner use component lacking/with incomplete #themeChanged
https://pharo.fogbugz.com/f/cases/18227

60023
18240 PluggableButtonMorph does not update his text color on themeChanged
https://pharo.fogbugz.com/f/cases/18240

18276 Update glamorousBrowse and testRunner icons
https://pharo.fogbugz.com/f/cases/18276

60022
18274 improve testing of UUID and remove createStringStartingAt:for:
https://pharo.fogbugz.com/f/cases/18274

18132 BlockClosure>>bench prints time instead of frequency when it runs for more than benchtime
https://pharo.fogbugz.com/f/cases/18132

18192 InputEventFetcher class>>#deinstall uses deprecated startup API
https://pharo.fogbugz.com/f/cases/18192

18268 Add Class comments to Refactoring-Core-Conditions classes
https://pharo.fogbugz.com/f/cases/18268
60021
18264 WriteBarrierTest are failing. Maybe put on “expected” for now
https://pharo.fogbugz.com/f/cases/18264

16084 introduce pragma “ignoreUnimplementedCalls:”
https://pharo.fogbugz.com/f/cases/16084

18262 safe usage of optional StartupPreferencesLoader in the PharoCommandLineHandler
https://pharo.fogbugz.com/f/cases/18262
60020
18248 TextAction>>rubActOnClick:for:in:editor: missing
https://pharo.fogbugz.com/f/cases/18248

18270 add #themeChanged method for GLMTabLabelBrick
https://pharo.fogbugz.com/f/cases/18270

18266 OCClassScope should ask class directly to find variable
https://pharo.fogbugz.com/f/cases/18266

60019
18245 StringMorph and Label morph lack #themeChanged
https://pharo.fogbugz.com/f/cases/18245
60018
18256 move HTTPProgress to the Network-Kernel package
https://pharo.fogbugz.com/f/cases/18256

18255 Improve documentation and tests for Integer methods for digits access
https://pharo.fogbugz.com/f/cases/18255

17802 Convenient methods for Message and MessageSend
https://pharo.fogbugz.com/f/cases/17802

18260 UUID tests should be moved to Tests package
https://pharo.fogbugz.com/f/cases/18260
60017
17451 Introducing Immutability
https://pharo.fogbugz.com/f/cases/17451

60016

http://files.pharo.org/image/60/60016.zip

60015
18039 Missing testing methods on vmParameter
https://pharo.fogbugz.com/f/cases/18039

18250 Fuel has no platform for Pharo 6.0
https://pharo.fogbugz.com/f/cases/18250

18235 isClassOrTrait is false for Metaclasses
https://pharo.fogbugz.com/f/cases/18235

60014
18047 Use iconNamed: instead of relying on DNU [Spec]
https://pharo.fogbugz.com/f/cases/18047

60013
18197 Text asUrl makes the package Network-Url dependent on Text
https://pharo.fogbugz.com/f/cases/18197

18251 add 50 repo for now so we can merge
https://pharo.fogbugz.com/f/cases/18251

60011
18200 TextAction calls unimplemented method #cull:cull:cull:cull:cull:
https://pharo.fogbugz.com/f/cases/18200

18199 “close all debuggers” could also be in the taskbar context menu
https://pharo.fogbugz.com/f/cases/18199

60010
18229 Allow String>>#repeat: to repeat a string 0 times
https://pharo.fogbugz.com/f/cases/18229

60009
18191 remove FFI classes from ReleaseTest>>#testKeyClassesArePresentInStartupList
https://pharo.fogbugz.com/f/cases/18191

18201 Reflectivity depends on Relfectivity-Tools
https://pharo.fogbugz.com/f/cases/18201

60008
18015 TApplyingOnClassSide class heirarchy speedup
https://pharo.fogbugz.com/f/cases/18015
60007
17896 MorphTreeMorph have trouble to update his theme
https://pharo.fogbugz.com/f/cases/17896

60006

18230 Critic Browser window title set to nil after deselecting a rule
https://pharo.fogbugz.com/f/cases/18230
60005
18173 fix #allClasses for RBBrowserEnvironments
https://pharo.fogbugz.com/f/cases/18173

60004
17938 Show abstract classes in ClassWidget with emphasis 2
https://pharo.fogbugz.com/f/cases/17938

60003
18129 ThemeIcons should store icons in an IdentityDictionarry
https://pharo.fogbugz.com/f/cases/18129

60002
18148 NEC should guess global variables
https://pharo.fogbugz.com/f/cases/18148

60001
18193 TxText cleaning
https://pharo.fogbugz.com/f/cases/18193


Torsten Bergmann - HashIds

Generate short unique ids from integers also for Smalltalk. Read more

Torsten Bergmann - OpenSmalltalk virtual machine repo

The virtual machine used for open source Smalltalks like Squeak and Pharo is now moved from Subversion to GitHub.

Read about the details.

May 20, 2016

Torsten Bergmann - TokyoDB

I did not know yet about this project from Esteban:

TokyoDB is a Pharo wrapper for Tokyo Cabinet.

May 18, 2016

Torsten Bergmann - Pharo 6 development

As Pharo 5.0 is now available for download the work on Pharo 6.0 directly started. There are already nice things in the pipe like Immutability

Torsten Bergmann - Virtual Machines and Managed Runtimes

Want to learn about virtual machine programming? Then have a look here.

May 17, 2016

The Weekly Squeak - Virtual Machines and Managed Runtimes

DeutschInLineCache

Mario Wolczko writes:

In early 2015 I was honored to be invited to develop and present a graduate course on Virtual Machines at UC Berkeley. The result is CS294-113: Virtual Machines and Managed Runtimes, which was presented in the Fall of 2015.

This page contains the materials from that course. All materials are Copyright © Oracle and Mario Wolczko, 2015-6, except as noted. The materials can be used non-commercially under the following Creative Commons license:

Virtual Machines and Managed Runtimes

Acknowledgements

I’d like to express my thanks to the following:

  • Patrick Li, my T.A. for the course. Patrick devised the Feeny language used in the exercises, wrote the Lab exercises and the model answers, and did all the grading,
  • Prof. Jonathan Bachrach for the invitation to give the course,
  • The guest speakers (in order of appearance): Peter Deutsch, Allan Schiffman, David Ungar, Cliff Click, Lars Bak, Carl Friedrich Bolz, Thomas Würthinger and Michael Van De Vanter,
  • My management at Oracle Labs for supporting this effort,
  • Michael Haupt for sharing his VM course material,
  • Christian Wimmer for assistance with Truffle, and
  • All the students who participated, for their patience, enthusiasm, attention, questions, efforts and feedback.

 


Cincom Smalltalk - Smalltalk Digest: May Edition

The May edition of The Cincom Smalltalk Digest is available now.

May 16, 2016

Cincom Smalltalk - “Hunt for Treasure” – The Quest Continues

Last year, Christian Haider, a Cincom Smalltalk™ partner, and Helge Nowak presented the open data project, "Schatzkarte," at the code.talks conference.

May 15, 2016

Pharo Weekly - Pharo packages for ArchLinux

Hi,

I've updated Pharo packages for ArchLinux. Could you please update
install procedure on http://pharo.org/gnu-linux-installation ?


Install Pharo launcher + Spur + old VM using command line:
  $ yaourt pharo-launcher

then run:
  $ pharo-launcher

(or look into your desktop menu for Pharo Launcher)

Note: PharoLauncher is automatically configured to run Pharo images
with right VM.


More informations on packages:
- pharo-launcher: https://aur.archlinux.org/packages/pharo-launcher/
- pharo-spur-vm: https://aur.archlinux.org/packages/pharo-spur-vm/
- pharo-vm (old VM): https://aur.archlinux.org/packages/pharo-vm/


Thanks for Pharo 5 :)

Laurent Laffont



May 14, 2016

Pharo Weekly - Pharo 50 last enhancements

50757
18203 Welcome window does not show content at startup
https://pharo.fogbugz.com/f/cases/18203

18208 Add changelog to welcome browser
https://pharo.fogbugz.com/f/cases/18208

50756
18203 Welcome window does not show content at startup
https://pharo.fogbugz.com/f/cases/18203

18204 typo in Explore Pharo Environment chapter
https://pharo.fogbugz.com/f/cases/18204

18205 typo in chapter “Learn Pharo Smalltalk”
https://pharo.fogbugz.com/f/cases/18205


May 13, 2016

Göran Krampe - Spry vs Allen

Allen Wirfs-Brock wrote down a bullet list of what he thought actually made it possible for the Alan Kay team to create Smalltalk, and many other ground breaking things, at Xerox PARC in the 70s. Let's take a look at his bullets one by one and see how it applies to Spry and my puny little effort around it :)

Look 20 years into the future

That's obviously hard to do, but I am trying a little bit by questioning every little thing that many consider not being even relevant or possible to question. Some examples are:

  • Why we can't do OO in some new novel ways
  • Why we are so stuck in having source code in files
  • Why we still only share code instead of sharing live objects
  • Why our IDEs still can't do things like backwards debugging or modifying code while running

Everyone is so busy "doing stuff" that noone takes the time to actually reflect. Can we really not create a development system in which I can see exactly what is going on? Is there really no more powerful ways to do debugging?

So I may not look into the future, but most good ideas come from someone doing something unexpected, weird, impossible or downright stupid. In Spry I want us to try a few of those :)

Extrapolate technologies

I don't really dare, but I think it's safe to say that Virtual Reality is probably going to be accessible everywhere. JavaScript has hopefully waned but leaving behind a new much lower threshold to programming being the norm, not the exception. Everyone wants to be able to program. Hardware is basically free, very capable and everywhere. People tend to think that the web is taking over everything, but I don't think its that simple - I think diversity is going to be much higher due to new companies creating new kinds of devices. Many more devices.

How does this affect choices in Spry? Well, I tend to not let performance considerations hinder various ideas. I also focus pretty hard on mobility of code and data, since I think we should be able to find a lot more models of computing in the area of distributed systems.

Finally I do think DSLs in different shapes or forms will play a big part in the future - so Spry should have excellent capabilities for that.

I also want Spry to be modular on most levels, while still being fairly simple.

Focus on people

The Smalltalk team was focused on user interfaces, education and children. With Spry "people" means primarily "developers".

I don't think 20 years will remove the need for writing code, but the pressure for fast results will be immensely higher. I also think the boundaries of computing will be much fuzzier and that we will need to have more advanced tools to create and mold code into doing what we want. Things will run on many devices, distributed in novel ways reaching places in our lives we can not really imagine.

I want to create and modify systems live as they run, as they are being used. Not just run locally, or as prototypes, but as they run live in deployment. Continuous deployment will probably evolve into 100% live online development. How will that affect developers? What tools do we need? How can we evolve a live system with confidence?

This implies we will have to create much more powerful ways to create, debug and modify code. We need to raise the abstraction levels, but perhaps a key to that is to create a homoiconic language that lends itself to introspection and self reference. Smalltalk didn't do that (only to some extent), nor did JavaScript. The Lisp family of languages did to some extent, but for various reasons never really took off. Hard to say why.

Create a vision

One vision is a globally shared live system of cooperating Spry objects. Like GemStone/S but on a global scale, and taken even further to the extreme. Today developers share code - dead code - via various package catalogs and copy/paste forums. The SaaS and PaaS etc are trying to create shared platforms, but it's still very much centered around the same coding model where we don't share actual functionality, but merely code and libraries to recreate the functionality on our own.

To be concrete - instead of downloading a library and create a small service that consumes a live feed of data and produces a stream of Spry objects, in Spry we would find not a library, but a live running existing service that we just hook into. The module is not dead code, but actually a live and running service.

This is homoiconicity driven all the way! During the years sharing of objects have been tried via various RPC-ish standards like CORBA or RMI, but those standards have always revolved around static early binding and separate specifications and have thus later been completely run over by late binding self describing technologies like REST-ful APIs using JSON and similar "soft" formats. Late binding and self description is key for how modern development is done to a large extent - experimentation.

Another vision is Spry being a language to serve as a new foundation for transferable portable active code. Kinda like a JavaScript that doesn't suck and that is homoiconic and thus easy to make tools for.

But in the end... I don't have any grand delusions about Spry - its all for fun and I just hope some of us will find it useful!

A Team of Dreamers and Doers

Obviously I don't have this. Yet. I hope that if I can make enough progress on my own - then people will join. And I stand on firm shoulders in the form of Nim which makes Spry suffering less of NiH (no pun intended). I hope that some Smalltalkers will eventually join, but I need a good solid language manual and perhaps even a reasonably interesting IDE to get any real traction.

Prototype the Vision

Spry has almost reached the point where we can start working on the fun stuff. The module system, serialization mechanisms and lossless AST improvements are all crucial steps towards this. Next step is getting the OO model working and do the Sophia integration to get a working image based system. After that I suspect its time to make a first IDE. I do have some plans and ideas for that too :)

Live Within the Prototype

I think this is definitely important. The existing REPL is just a crude first trivial step. But it will get better!

Make It Useful to You

I personally want to apply Spry in the domains of VR and IoT. Web systems is no longer that interesting to me, but if someone would like to evolve Spry compiled to js - I would be very grateful.

Amaze the World

Hopefully, eventually! :)

Pharo Weekly - Pharo 50 Released

Dear World,
The time has come for Pharo 5.0
Sent-4523.png
This is our most significant release yet. Here are some highlights:
– The PharoVM is now based on Spur, the new memory management, and it brings with it a 35% speedup!
– A new unified foreign function interface (UFFI) replaced NativeBoost to provide a strong Spur-compatible framework for interfacing with the outside world.
– The Glamorous Toolkit now includes the GTDebugger to offer a moldable infrastructure that allows the developer to customize the debugger deeply.
– The underlying Reflectivity mechanism has reached maturity with multiple pieces coming together to empower developers to instrument their own systems. For example, we now have breakpoints implemented as just a simple extension of this mechanism.
– QualityAssistant is now part of the image to provide live feedback during development.
These are just the more prominent highlights, but the details are just as important. We have closed 2446 issues in Pharo 5. Take a moment to go through a more detailed recount of the progress: https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo50ChangeLogs.md.
Sent-4523-1.png
While the technical improvements are significant, just think of getting 30% faster out-of-the-box, still the most impressive fact is that the new code that got in the main Pharo 5.0 image was contributed by 100 people. Together we have touched 43% of the classes, and 20% of the methods. The following visualization rendered with Roassal in Pharo 5.0 is dedicated to this effort. The picture shows the touched classes and packages in gray, the authors and the links to the changed classes in red, and,  using an automatically generated visual id, you can spot authors that have worked on similar projects.
Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors of this release:
Abdelghani Alidra,  Clara Allende,  David Allouche,  Nicolas Anquetil,  Thibault Arloing,  Jean Baptiste Arnaud,  Mangesh Bendre,  Clement Bera,  Alexandre Bergel,  Torsten Bergmann,  Usman Bhatti,  Vincent Blondeau,  Johan Brichau,  Camillo Bruni,  Miguel Campusano, Damien Cassou,  Nicolas Cellier,  Danny Chan,  Andrei Chis,  Christopher Coat,  Ben Coman,  Bernardo Contreras,  Gabriel Omar Cotelli,  Tommaso Dal Sasso,  Paul De Bruicker,  Sean De Nigris,  Christophe Demarey,  Simon Denier,  Marcus Denker,  Martin Dias,  John Dougan,  Stephane Ducasse,  Stephan Eggermont,  Johan Fabry,  Sergio Fedi,  Cyril Ferlicot,  Holger Hans Peter Freyther,  Joshua Gargus,  Tudor Girba,  Thierry Goubier,  Kris Gybels,  Norbert Hartl,  Thomas Heniart,  Dale Henrichs,  Nicolai Hess,  Alejandro Infante,  Henrik Johansen, Goran Krampe,  Pavel Krivanek,  Juraj Kubelka,  Denis Kudriashov,  Matthieu Lacaton, Laurent Laffont,  Kevin Lanvin,  Jannik Laval,  Alexander Lazarević, Skip Lentz,  Max Leske,  Dave Lewis, Esteban Lorenzano,  Sheridan Mahoney,  Mariano Martinez Peck, Max Mattone,  John McIntosh,  Rene Meusel,  Eliot Miranda,  Henrik Nergaard,  Marion Noirbent,  Merwan Ouddane,  Nick Papoulias,  Nicolas Passerini,  Alain Plantec,  Guillermo Polito,  Damien Pollet,  Baptiste Quide,  Andreas Raab (RIP),  Alain Rastoul,  Stefan Reichhart,  Lukas Renggli,  Mark Rizun,  Michael Rueger,  Valentin Ryckewaert,  Ronie Salgado,  Udo Schneider,  Boris Spasojevic,  Igor Stasenko,  Roger Stebler,  Serge Stinckwich,  Aliaksei Syrel,  Camille Teruel,  Pablo Tesone,  Yuriy Tymchuk,  Peter Uhnak,  Masashi Umezawa,  Dion Stewart, Sven Van Caekenberghe,  Jan Van De Sandt,  Benjamin Van Ryseghem,  Toon Verwaest,  Franck Warlouzet.
(If you contributed with Pharo 5.0 development in any way and we missed your name, please send us a mail and we will add you).
Enjoy!
The Pharo Team

May 12, 2016

The Weekly Squeak - Squeak in Action

squeak in action

Chris Muller posted:

The mission-control app I’ve been working on this year appeared in a special episode of CBBC Newsround yesterday!

http://www.bbc.co.uk/newsround/36247103

The segment about Reserve Protection Agency with several screenshots of the app begins at time index 9:40 and runs until 12:25.  I recommend watching the entire episode, though, it’s a worthwhile message.

No one will know it is powered by Squeak but that’s okay, the important message is the one about the danger faced by rhinos as a species.


Torsten Bergmann - Pharo 5.0 - RELEASE

Lots of work in all the details for each member of our Pharo community - but now Pharo 5.0 is pushed out of the door. Great!!!