April 2017 - Pharo-dev - lists.pharo.org

Pharo behind ALLSTOCKER marketplace
by Masashi UMEZAWA Aug. 17, 2017

Aug. 17, 2017

Hi all, >From Torsten, I've received a request to post about some technical details of ALLSTOCKER (http://pharo.org/success/AllStocker) . I hope these notes will be interesting to Pharo web developers. - Seaside / Teapot We are using Seaside as a main framework for ALLSTOCKER marketplace. Seaside's component architecture is great for extending application in an organized way. ALLSTOCKER prototype was originally composed of only 3 class categories. Now these were gradually grown to 70 categories. But we still feel that they are manageable. We also use Teapot for building Web-based API in a quick way. Recently we've built webhook handlers for integration with other services. - Templating with Mustaside We need a lot of responsive-design web pages for supporting various mobile devices. (It is important especially for Southeast Asian countries, where tablets are popular than PCs). We would like to adopt existing Twitter Bootstrap templates for saving time. So, Mustaside was our choice. http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside Before Mustaside, there were a lot of noisy #div: sends in our code. Now they are gone. - Localization Our business target is world-wide. So localization is very important topic. Currently ALLSTOCKER supports 4 languages and we will add Chinese languages soon. Translation strings are not only in Smalltalk code, but also in Mustache templates. So we selected Soup for extracting translatable strings in those templates. http://smalltalkhub.com/#!/~PharoExtras/Soup For managing translations, we use Gettext package. http://smalltalkhub.com/#!/~PharoExtras/Gettext - Databases For transactional data, we chose Glorp. Although there are mapping costs, we prefer RDB (Postgres). It is reliable for handling precious order-related data. However, for supporting complex search of machines, we use Neo4j - a graph database. It supports very powerful query language called Cypher. We can avoid complex table joins and get aggregated results faster. http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt - Keyword search ALLSTOCKER supports free keyword search. We selected Elasticsearch for search-engine. Elasticsearch has elaborated searching facilities and those are easily accessible via REST API. We have extended the existing Elasticsearch client for Pharo 5. https://github.com/newapplesho/elasticsearch-smalltalk - Deployment We are using AWS Elastic Load Balancer and running Nginx as a front-end web server. Two back-end Pharo images are running and load-balanced with sticky sessions. It was sort of difficult to find the appropriate simultaneous number of database connections and Pharo processes. We feel ALLSTOCKER is pretty stable for now, but we need to adjust more for expanding our services. Best regards, -- [:masashi | ^umezawa]

8 7

PharoSpur32Vm
by Nicolai Hess July 23, 2017

July 23, 2017

Where are the latest Pharo-spur-vms (32bit) are built? I don't see them on the build server, only the buildresults at http://files.pharo.org/vm/pharo-spur32/linux/ The latest builds on the buildserver are from the last year only. nicolai

9 27

macOS Sierra support
by Sven Van Caekenberghe July 15, 2017

July 15, 2017

Hi, Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. Thanks, Sven PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.

12 27

Re: [Pharo-dev] [Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)
by Eliot Miranda June 14, 2017

June 14, 2017

Hi Esteban, Hi Igor, Hi All, On Fri, Mar 10, 2017 at 7:35 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Iâm tumbling into an error in Pharo, because we use callbacks intensively, > in Athens(cairo)-to-World conversion in particular, and people is sending > always their crash reportsâ¦ we made the whole conversion a lot more robust > since problems started to arise, but now I hit a wall I cannot solve: I > think problem is in something in callbacks. > > And problem is showing very easy on 64bits (while in 32bits it takes time > and is more random). > I responded in the "image not opening" thread, but it's the same problem. I really want to hear what y'all think because I'll happily implement a fix, but I want to know which one y'all think is a good idea. Here's my reply (edits between [ & ] to add information): On Mon, Mar 13, 2017 at 9:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: I'm pretty confident [I know] this is to do with bugs in the Athens surface code which assumes that callbacks can be made in the existing copyBits and warpBits primitive. They can't do this safely because a GC (scavenge) can happen during a callback, which then causes chaos when the copyBits primitive tries to access objects that have been moved under its feet. I've done work to fix callbacks so that when there is a failure it is the copyBits primitive that fails, instead of apparently the callback return primitive. One of the apparent effects of this fix is to stop the screen opening up too small; another is getting the background colour right, and yet another is eliminating bogus pixels in the VGTigerDemo demo. But more work is required to fix the copyBits and warpBits primitives. There are a few approaches one might take: a) fixing the primitive so that it saves and restores oops around the callbacks using the external oop table [InterpreterProxy>>addGCRoot: & removeGCRoot:]. That's a pain but possible. [It's a pain because all the derived pointers (the start of the destForm, sourceForm, halftoneForm and colorMapTable) must be recomputed also, and of course most of the time the objects don't move; we only scavenge about once every 2 seconds in normal running] b) fixing the primitive so that it pins the objects it needs before ever invoking a callback [this is a pain because pinning an object causes it to be tenured to old space if it is in new space; objects can't be pinned in new space, so instead the pin operation forwards the new space object to an old space copy if required and answers its location in old space, so a putative withPinnedObjectsDo: operation for the copyBits primitive looks like withPinnedFormsDo: aBlock <inline: #always> self cppIf: SPURVM & false ifTrue: [| bitBltOopWasPinned destWasPinned sourceWasPinned halftoneWasPinned | (bitBltOopWasPinned := interpreterProxy isPinned: bitBltOop) ifFalse: [bitBltOop := interpreterProxy pinObject: bitBltOop]. (destWasPinned := interpreterProxy isPinned: destForm) ifFalse: [destForm := interpreterProxy pinObject: destForm]. (sourceWasPinned := interpreterProxy isPinned: sourceForm) ifFalse: [sourceForm := interpreterProxy pinObject: sourceForm]. (halftoneWasPinned := interpreterProxy isPinned: halftoneForm) ifFalse: [halftoneForm := interpreterProxy pinObject: halftoneForm]. aBlock value. bitBltOopWasPinned ifFalse: [interpreterProxy unpinObject: bitBltOop]. destWasPinned ifFalse: [interpreterProxy unpinObject: destForm]. sourceWasPinned ifFalse: [interpreterProxy unpinObject: sourceForm]. halftoneWasPinned ifFalse: [interpreterProxy unpinObject: halftoneForm]] ifFalse: [aBlock value] and tenuring objects to old space is not ideal because they are only collected by a full GC, so doing this would at least tenure the bitBltOop which is very likely to be in new space] c) fixing the primitive so that it uses the scavenge and fullGC counters in the VM to detect if a GC occurred during one of the callbacks and would fail the primitive [if it detected that a GC had occurred in any of the surface functions]. The primitive would then simply be retried. d) ? I like c) as it's very lightweight, but it has issues. It is fine to use for callbacks *before* cop[yBits and warpBits move any bits (the lockSurface and querySurface functions). But it's potentially erroneous after the unlockSurface primitive. For example, a primitive which does an xor with the screen can't simply be retried as the first, falling pass, would have updated the destination bits but not displayed them via unlockSurface. But I think it could be arranged that no objects are accessed after unlockSurface, which should naturally be the last call in the primitive (or do I mean showSurface?). So the approach would be to check for GCs occurring during querySurface and lockSurface, failing if so, and then caching any and all state needed by unlockSurface and showSurface in local variables. This way no object state is accessed to make the unlockSurface and showSurface calls, and no bits are moved before the queryDurface and lockSurface calls. If we used a failure code such as #'object may move' then the primitives could answer this when a GC during callbacks is detected and then the primitive could be retried only when required. [Come on folks, please comment. I want to know which idea you like best. We could fix this quickly. But right now it feels like I'm talking to myself.] > Here is the easiest way to reproduce it (in mac): > > wget files.pharo.org/get-files/60/pharo64-mac-latest.zip > wget files.pharo.org/get-files/60/pharo64.zip > wget files.pharo.org/get-files/60/sources.zip > unzip pharo64-mac-latest.zip > unzip pharo64.zip > unzip sources.zip > ./Pharo.app/Contents/MacOS/Pharo ./Pharo64-60438.image eval "VGTigerDemo > runDemo" > > eventually (like 5-6 seconds after, if not immediately), you will have a > stack like this: > > SmallInteger(Object)>>primitiveFailed: > SmallInteger(Object)>>primitiveFailed > SmallInteger(VMCallbackContext64)>>primSignal:andReturnAs:fromContext: > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > VGTigerDemo>>runDemo > VGTigerDemo class>>runDemo > UndefinedObject>>DoIt > OpalCompiler>>evaluate > OpalCompiler(AbstractCompiler)>>evaluate: > [ result := Smalltalk compiler evaluate: aStream. > self hasSessionChanged > ifFalse: [ self stdout > print: result; > lf ] ] in EvaluateCommandLineHandler>>evaluate: > in Block: [ result := Smalltalk compiler evaluate: aStream.... > BlockClosure>>on:do: > EvaluateCommandLineHandler>>evaluate: > EvaluateCommandLineHandler>>evaluateArguments > EvaluateCommandLineHandler>>activate > EvaluateCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ aCommandLinehandler activateWith: commandLine ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in > Block: [ aCommandLinehandler activateWith: commandLine ] > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > [ self > handleArgument: > (self arguments > ifEmpty: [ '' ] > ifNotEmpty: [ :arguments | arguments first ]) ] in > PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ > self... > BlockClosure>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activate > PharoCommandLineHandler>>activate > PharoCommandLineHandler class(CommandLineHandler class)>>activateWith: > [ super activateWith: aCommandLine ] in PharoCommandLineHandler > class>>activateWith: in Block: [ super activateWith: aCommandLine ] > > Any idea? > > thanks! > Esteban -- _,,,^..^,,,_ best, Eliot

6 11

ZnInvalidUTF8 on response from squeaksource
by Patrick R. May 22, 2017

May 22, 2017

Hi everyone, I have been working on bringing http://squeaksource.com/ical/ up to speed for Squeak and wanted to make sure that it also works for Pharo. Therefore, I have created a travis build job for Squeak and Pharo (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which pulls the source from squeaksource.com. Now the issue is that loading the package in Pharo fails with a GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this might be the result of the squeaksource page delivering the page as iso-8859-1 as it contains special characters. Any ideas on how to get this to work? I do not have access to the ical repository description and I would liek to avoid mirroring the whole repository on GitHub. Thanks and bests Patrick -- View this message in context: http://forum.world.st/ZnInvalidUTF8-on-response-from-squeaksource-tp4938787… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

6 14

First commit
by Evan Donahue May 7, 2017

May 7, 2017

Hello, I have just tried to submit my first patch to the main Pharo inbox. I submitted a patch for issue https://pharo.fogbugz.com/f/cases/17848 because it basically amounted to changing an error message and seemed like a good place to start figuring out how the submission process works. I saved my slice to the Pharo60Inbox, but when I typed my commit message and hit save, I did not see any confirmation. How can I tell if my slice was submitted or not? Thank you, Evan

4 5

./pharo --help returns exit code 1 on ubuntu
by Andrei Chis May 7, 2017

May 7, 2017

Hi, In an ubuntu installation with the latest vm and Pharo 6 image when executing `./pharo --help` I get an error code of 1. wget -O- get.pharo.org/vmLatest60 | bash wget -O- get.pharo.org/60 | bash ./pharo --help echo $? --> returns 1 On mac the error code is 0. Also when executing './pharo' or './pharo Pharo.image --help' or './pharo --version' the error code is 0 on both mac and linux. So it seems there is some issues with --help. Actually, it gives a usage warning, but still I'd expect to not return an error code. Usage: Pharo.app/Contents/MacOS/Pharo [<option>...] [<imageName> [<argument>...]] Pharo.app/Contents/MacOS/Pharo [<option>...] -- [<argument>...] Cheers, Andrei

3 5

Smalltalk Internet Browser
by askoh May 6, 2017

May 6, 2017

Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS. How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

15 36

GarageGlorp
by Stephane Ducasse May 2, 2017

May 2, 2017

Hi for a tutorial I wanted to load Glorp in Pharo 60 as described in the Glorp doc. Metacello new smalltalkhubUser: 'DBXTalk' project: 'Garage'; configuration: 'GarageGlorp'; version: #stable; load. I get an error stating that The symbolic version stable is not defined in the configuration for the ... for the platform. I changed the loading instruction to Metacello new smalltalkhubUser: 'DBXTalk' project: 'Garage'; configuration: 'GarageGlorp'; version: '0.2'; load. And it seems to work. May be we should publish a symbolic version for pharo 60. I do not think that I have commit right. Stef

2 4

Meanwhile in FogBugz: issue 20000
by Torsten Bergmann May 1, 2017

May 1, 2017

Hi, our community today hit the 20000 issues mark in FogBugz. https://pharo.fogbugz.com/f/cases/20000 And a good change to once again say THANK YOU, especially to the ones who care most on - updating the bug tracker - fixing issues - reviewing issues - integrating issues - doing also the boring tasks in caring about the bugtracker - pushing Pharo in the right direction Just wow and impressive! Pharo 6 will be another nice milestone in a lively open source Smalltalk system that we all wanted to see becoming a reality! Thx T. BTW: The issue 20000 is about clickable URLs in Help Browser. Currently we copy them to clipboard - as we do not have web browser support in the default image. I guess it is too late to push this package into the image due to the freeze. So this slices nonetheless tries to improve the situation by checking if the unified WebBrowser support package (which is available since a year [1]) is loaded or not. If it is loaded it opens a real web browser. So when Pharo 6 is released and someone may lament about not being able for the URLs to really work we can point him to load the "WebBrowser" package and he should be fine. [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-April/12072…

4 3