Monthly Archives: December 2017

FreeCell resurrection

Hi,

I fixed the old FreeCell code from Squeak to be able to run on Pharo 6 and 7.
How to load:
Metacello new
  baseline: ‘FreeCell’;
  repository: ‘github://pavel-krivanek/FreeCell/src’;
  load.
How to run:
FreeCell open.
Cheers,
— Pavel
Advertisements

Best wishes for 2018

Only a few days left for 2017. Thanks to all who helped shaping Pharos future.
May the lighthouse be with you in 2018 as well:

World backgroundImage:
(ZnEasy
getJpeg: ‘https://spotlight.it-notes.ru/wp-content/uploads/2017/08/02c48424be88ee36d5300ad89033fd82.jpg’)
layout: #scaled

Have fun!

Bye

Torsten Bergmann

OpenSSL-Pharo in Windows

Hi all,

OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a fresh 32-bit
Pharo 6.1 zip package downloaded from pharo.org. On Windows this library uses
libeay.dll which is bundled with the Pharo VM.

Metacello new
baseline: ‘OpenSSL’;
smalltalkhubUser: ‘PierceNg’ project: ‘OpenSSL-Pharo’;
load.

And now I have added #macModuleName to the library and tested it successfully
with 64-bit Pharo on my Mac that runs Sierra.

Pierce Ng

Miner game in Bloc

Developed by students from FIT CTU in Prague and supervised by Prof. R. Pergl.

 

 

Pharo Smalltalk: Un Entorno de Programación Subversiva

Hi all,

It has been published the video of the Pharo introduction talk (titled “Pharo Smalltalk: Un Entorno de Programación Subversiva”) we organized from Osoco for the Madrid Software Crafters meetup.
Both, video and slides are in spanish:
Cheers,
Rafael Luque

Glorp on Github…

Hi Everyone,

I’ve migrated Glorp v130, including GlorpSQLite, from smalltalkhub to
github using Peter Uhnak’s excellent git-migration tool, see:
https://github.com/pharo-rdbms

To load Glorp:

Metacello new
repository: ‘github://pharo-rdbms/src’;
baseline: ‘Glorp’;
load.

To load Glorp with the UDBC SQLite drivers:

Metacello new
repository: ‘github://pharo-rdbms/src’;
baseline: ‘GlorpSQLite’;
load.

I’m not familiar with the other drivers, so I’m happy to help, but would
like some assistance before migrating the other drivers.

If I don’t hear any complaints in the next week I’ll eventually get
around to modifying the ConfigurationOfGlorp on smalltalkhub to use the
github version for Pharo 6.1 and 7.0.  Older versions of Pharo will
continue to load Glorp from smalltalkhub.

If there’s an official account that should own this project, I’m more
than happy to hand it over.

Cheers,
Alistair

Calypso tool suite new release

Hello.

I glad announce new Calypso version. It is a big refactoring on navigation model and browser pluggability.
Now I start document new design and will post progress on it.
Notice: this version is not adopted for TelePharo and Cargo. It will be done soon.
Best regards,
Denis

Nested JSON REST

> I guess part of what I’m interested in are patterns for hooking
> NeoJSON up to parse a REST response into objects to build a wrapper
> around a REST service. I see a chapter in Enterprise Pharo, which I’ll
> get to that soon.  Perhaps I was premature asking before reading that,
> but its good to have a few paths to explore.

Here is a recent example http://forum.world.st/Another-example-of-invoking-a-REST-JSON-web-service-resolving-User-Agent-strings-tt5017489.html

Thanks Sven.  That helped a lot.   I’d like to report success.
It may be useful to others to see how to progressively build up to parsing a Nested JSON REST
1. First parse the JSON into simple Dictionaries…
(ZnClient new
    enforceHttpSuccess: true;
    accept: ZnMimeType applicationJson;
    contentReader: [ :entity | NeoJSONReader fromString: entity contents ];
get) inspect.
==>Dictionary(
      ‘success’ ==> true
      ‘message’ ==> ”
      ‘result ‘ ==> an Array(a Dictionary(‘BaseCurrency’->’BTC’ ‘BaseCurrencyLong’->’Bitcoin’)
… a Dictionary(‘BaseCurrency’->’ETH’ ‘BaseCurrencyLong’->’Ethereum’)
2. Then parse the first level response into a real object…
Object subclass: #BittrexResponse
    instanceVariableNames: ‘success message result’
    classVariableNames: ”
    package: ‘Bittrex’
(ZnClient new
   enforceHttpSuccess: true;
   accept: ZnMimeType applicationJson;
   contentReader: [ :entity |
       (NeoJSONReader on: entity readStream)
mapInstVarsFor: BittrexResponse ;
         nextAs: BittrexResponse ];
      get) inspect.
==>BittrexResponse
      success => true
      message => ”
      result => an Array(a Dictionary(‘BaseCurrency’->’BTC’ ‘BaseCurrencyLong’->’Bitcoin’)
… a Dictionary(‘BaseCurrency’->’ETH’ ‘BaseCurrencyLong’->’Ethereum’)
Or alternatively…
(ZnClient new
   enforceHttpSuccess: true;
   accept: ZnMimeType applicationJson;
   contentReader: [ :entity | |reader|
   reader := (NeoJSONReader on: entity readStream).
   reader for: BittrexResponse do: [:m|
           m mapInstVar: #success.
           m mapInstVar: #message.
           m mapInstVar: #result ].
    reader nextAs: BittrexResponse ];
   get) inspect.
==>BittrexResponse
      success => true
      message => ”
      result => an Array(a Dictionary(‘BaseCurrency’->’BTC’ ‘BaseCurrencyLong’->’Bitcoin’)
… a Dictionary(‘BaseCurrency’->’ETH’ ‘BaseCurrencyLong’->’Ethereum’)
3. Finally parse into real objects the nested level holding the data you really want…
Object subclass: #Market
    instanceVariableNames: ‘MarketCurrency BaseCurrency MarketCurrencyLong BaseCurrencyLong MinTradeSize MarketName IsActive Created Notice IsSponsored LogoUrl’
   classVariableNames: ”
   package: ‘Bittrex’
(ZnClient new
   enforceHttpSuccess: true;
   accept: ZnMimeType applicationJson;
   contentReader: [ :entity | |reader|
   reader := (NeoJSONReader on: entity readStream).
   reader for: BittrexResponse do: [:m|
            m mapInstVar: #success.
            m mapInstVar: #message.
           (m mapInstVar: #result) valueSchema: #ArrayOfMarkets].
           reader for: #ArrayOfMarkets customDo: [ :mapping | mapping listOfElementSchema: Market ].
reader mapInstVarsFor: Market.
      reader nextAs: BittrexResponse ];
   get) inspect.

==>BittrexResponse
      success => true
      message => ”
      result => an Array(a Market(LTC) a Market(DOGE) a Market(VTC) a Market(PPC) a Market(FTC) a Market(RDD)
… Market(POWR) a Market(BTG) a Market(BTG) a Market(BTG) a Market(ADA) a Market(ENG) a Market(ENG))
WhooHoo!
A couple of things remaining:
* The instance variables of Market currently start with an upper-case to match the JSON fields.
  Lower-casing the first letter breaks things.
  What strategies can be used to conform here to Smalltalk conventions?
  Or is it easy enough to live with it?
* In various posts I’ve seen mention of a class-side method #neoJsonMapping:
   but there is no explanation of this in the Enterprise Book.
   How might #neoJsonMapping: come into the picture for my use case above?
cheers -ben

About REST clients

Hi Ben,

I’ve made a few REST Clients

http://smalltalkhub.com/#!/~pdebruic/Stripe
http://smalltalkhub.com/#!/~pdebruic/Tropo
http://smalltalkhub.com/#!/~pdebruic/SegmentIO

And the elasticsearch one but its been advanced mostly lately by Sho Yoshida
(https://github.com/newapplesho) here
https://github.com/newapplesho/elasticsearch-smalltalk

He has also made REST clients for Twilio, AWS, SendGrid, Salesforce, and
Mixpanel among others.

Norbert Hartl made one for Mandrill (Mailchimps transactional email service)
http://smalltalkhub.com/#!/~NorbertHartl/Mandrill

And Francois Stephany made one for Postmark (another transactional email
service) http://smalltalkhub.com/#!/~PharoExtras/Postmark

So those are some examples of different approaches.

I also started/made a cross platform web client wrapper (just wraps calls to
ZnClient or WebClient on Squeak)
http://smalltalkhub.com/#!/~pdebruic/HTTPAPIClient

But IIRC I only used it in the Stripe API client.

Hope this gives you some ideas about how to approach your own solution

Paul

GT Mondrian: Mondrian on top of Block

Hi,

We are happy to announce, a graph visualization engine built on top of Bloc.

It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE.

The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc.
The solution was to split the mondrian-doctypical edge implementation in graph visualization libraries into two distinct concepts:
• Line is an element that draws the connections.
• Edge defines constraints imposed by connections between elements.


Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What’s more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span.

 
The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo.
The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here:
If you download the GT code through Iceberg, the documentation can be experienced live by inspecting:
‘./pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar’ asFileReference
The Feenk team