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

Catalog statistics (Who know this projects?)
by Esteban Lorenzano Aug. 22, 2017

Aug. 22, 2017

Soâ¦ I took a couple of minutes to do a small list of project description status: >From a total of 379 projects currently in the catalog, just 115 have a description and/or keywords associated. Which means 264 are mysterious projects nobody can guess what are they about. I was thinking most of this projects would be in Unsorted (or Pharo 3), but I found that many are also on Pharo 5 and 4â¦. which is frankly unacceptable :) Even very important projects like Seaside or Garage and Glorp are not documented. So, please peopleâ¦ take a look at your projects and PLEASE, provide a description and proper keywordsâ¦ Nobody can guess what is Aconcagua (besides a cool mountain in south america), or Telescope, etc., etc., etc. Here the list of non-documented projects: http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main --- 'A4BP' 'Aconcagua' 'BootstrapMagritte' 'Chalten' 'CommandShell' 'Cormas' 'DependencyAnalyser' 'FamixJS' 'FontAwesome' 'Garage' 'GarageConnectionPool' 'GarageGlorp' 'Glorp' 'Grease' 'IniModules' 'Kendrick' 'Magritte3' 'MagritteMagic' 'MetaBoardBoard' 'MyFirstWebApp' 'NBOpenGL' 'NeoJSON' 'OSProcess' 'PetitParser' 'Phexample' 'Pier3' 'Pier3AddOns' 'ProcessWrapper' 'RewriteTool' 'Seaside3' 'SimplePersistence' 'Ston' 'Telescope' 'Woden' âXtreams' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main --- 'AconcaguaDeluxe' 'AthensSVG' 'Autotest' 'CPanel' 'CreativeCommonsLive' 'DevFlow' 'EventRecorder' 'ExtendedNumberParser' 'ExternalWebBrowser2' 'FixedDecimal' 'Ghost' 'GraphViz' 'Gravatar' 'Hubcap' 'Infinity' 'Mandrill' 'Mathex' 'MemoryMonitor' 'MinimalConnectors' 'Mocketry' 'MongoTalk' 'NBSQLite3' 'NumericalMethods' 'ODBC' 'OSOSX' 'OSWindows' 'PackageDependenciesAnalysis' 'PharoLauncher' 'PlagueDoctor' 'Pomodoro' 'RemoteAnnouncement' 'SandstoneDb' 'Scheduler' 'ScriptManager' 'Shapes' 'SmallUML' 'Spreadsheet' 'Spy' 'StateSpecs' 'SuffixConditionals' 'Teachable' 'TestMock' 'Trees' 'Twilio' 'Vidi' 'VistaCursors' 'Viva' 'WiringPi' 'WorkingSet' 'XBase' 'sQuick' âsQuick_new' http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main --- 'Actalk' 'Arduino' 'BabyMock2' 'CTranslator' 'DBPedia' 'DigitalOcean' 'Forum' 'Fuel' 'GTDebugger' 'GTInspector' 'GTInspectorCore' 'GTPlayground' 'GTPlaygroundCore' 'GTSpotter' 'GToolkit' 'GlamourCore' 'GlorpDBX' 'GraphET' 'InstanceEncoder' 'Marina' 'Mechanize' 'Memcached' 'Moose' 'Pastell' 'PharoOnlineHelp' 'ProfStef' 'PythonParser' 'RFB' 'Roassal3d' 'SQLite3' 'Smallapack' 'SmalltalkHub' 'Snapshotcello' 'SortFunctions' 'Spotlight' 'Stamp' 'Tide' 'VersionBrowser' âVersionner' http://www.squeaksource.com/MetacelloRepository --- 'AXAnnouncements' 'Adore' 'Aida' 'Ajp' 'Algernon' 'Alien' 'Amers' 'Announcements' 'AutomaticMethodCategorizer' 'BetaNineIPAddress' 'CAnalyzer' 'CairoGraphics' 'CampSmalltalkLondon' 'Cecinestpasunepomme' 'CharacterMap' 'Chronos' 'CloudforkAWS' 'Cog' 'Connectors' 'ContextS' 'Control' 'Country' 'Countryside' 'DBXBrowser' 'DBXTools' 'DependencyBrowser' 'DependencyView' 'EnhancedOmniBrowser' 'ExternalIconFamily' 'ExternalWebBrowser' 'FileMan' 'FileTree' 'Filesystem' 'GemTools' 'Gitocello' 'Glamour' 'Gofer' 'GoferProjectLoader' 'GoogleAnalytics' 'HPDF' 'HealthReportProducer' 'HelpSystem' 'ICal' 'InstancesBrowser' 'JQueryWidgetBox' 'JavaScriptAnalyzer' 'Jejak' 'Keymapping' 'Kozen' 'KyotoTycoonClient' 'MaBase' 'MaClientServer' 'Magma' 'Magmafy' 'Magritte' 'Magritte2' 'Magritte3AddOns' 'MagritteAddOns2' 'Metacello' 'MetacelloBrowser' 'MetacelloPreview' 'MockGemStone' 'Mondrian' 'Money' 'MonticelloRedirect' 'Murmansk' 'Nagare' 'NativeBoost' 'Neo4reSt' 'NewECompletion' 'NewInspector' 'NewOCompletion' 'Nile' 'NotificationsArea' 'O2' 'OCompletion' 'OPAX' 'ObjectMetaTools' 'OmniBrowser' 'OmniBrowserLukas' 'Orca' 'PagedReader' 'Pharo' 'PharoMorphicExtras' 'PharoNonCore' 'Phriak' 'Pier' 'Pier2' 'PierAddOns' 'PierAddOns2' 'PostMark' 'ProcessModel' 'Quaternion' 'REPL' 'Raphael' 'RatPack' 'RefactoringBrowser' 'RefactoringTools' 'RoelTyper' 'SIXX' 'SPort2' 'SandcastleThemes' 'Scamper' 'Scribo' 'Seafox' 'Seaside' 'Seaside28' 'Seaside28Examples' 'Seaside30' 'SeasideJSON' 'SeasideRest' 'SeasideTesting' 'SharedWorkspace' 'Shout' 'SimpleApplescript' 'SoapOpera' 'SpellingServices' 'SpyForO2' 'Sqnappy' 'SqueakCheck' 'SqueakDBX' 'SqueakFS' 'SqueakSource' 'StOMP' 'Stripe' 'SunnysidePlanning2' 'SwaLint' 'Swazoo2' 'TODO' 'TimerDaemon' 'Tuio' 'VMMaker' 'Waterfall' 'WebClient' 'WebTester' 'XMLRPC' 'XMLSupport' 'Zodiac'

15 22

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

Epicea and #name in #behaviorAffectedName
by Torsten Bergmann July 6, 2017

July 6, 2017

Hi, in latest Pharo 6 image 60494 I run into some trouble today where the deprecation warning dialog popped up and repeated itself unstoppable due to Epicea. It is hard to reproduce but what I found out was that I had a class modification (represented by EpClassModification) which run into a state where "newClass" was nil and therefore in EpClassModification>>#behaviorAffectedName the message #name was sent to nil. So #name was found in Object and as we all know we deprecated it now which lead to the deprecation dialog, leading to the deprecation dialog, leading to the deprecation dialog, ... Nearly all implementors of Epiceas #behaviorAffectedName send #name which is ok if there is a valid object it is sent to. I do not know if we should protect them somehow in case something goes wrong (like having nil in newClass) or if we should keep this untouched. At least I wanted to inform because I do not know if this later gets others into trouble too and losing their changes because Epicea does not record. Thanks T.

2 1

Fwd: [Vm-dev] multiple crashes on macOS Sierra
by Eliot Miranda July 3, 2017

July 3, 2017

---------- Forwarded message ---------- From: Tobias Pape <Das.Linux(a)gmx.de> Date: Mon, May 29, 2017 at 12:09 AM Subject: Re: [Vm-dev] multiple crashes on macOS Sierra To: John McIntosh <johnmci(a)smalltalkconsulting.com> Cc: Squeak Virtual Machine Development Discussion < vm-dev(a)lists.squeakfoundation.org> Hi John, all > On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added > > > NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) > location:[theEvent locationInWindow] > modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) > timestamp:[theEvent timestamp] > windowNumber:[theEvent windowNumber] > context:nil > characters:@"" > charactersIgnoringModifiers:@"" > isARepeat:NO > keyCode:[theEvent keyCode]]); > > in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent That's correct. > > However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/ library/content/documentation/Cocoa/Conceptual/MemoryMgmt/ Articles/mmRules.html > > + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() I read this https://developer.apple.com/reference/appkit/nsevent/ 1533943-keyeventwithtype?language=objc and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. I now understand that I should only autorelease alloc/inited stuff. So you may be right here. Fixed in 0f07ffbed Best regards -Tobias > > If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. [snip]

5 5

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

please test download for Pharo 6.0
by Esteban Lorenzano June 6, 2017

June 6, 2017

Hello, we are getting ready for release. please take a minute to review: http://pharo.org/STAGE.download <http://pharo.org/STAGE.download> (notice that zerconf download will not work because it is not yet movedâ¦ so #stable will download current stable version which is 5.0) cheers, Esteban

20 43

DebugSession: no exception raised when stepping out of the execution?
by tdupriez＠ens-paris-saclay.fr June 2, 2017

June 2, 2017

Hi, I'm working with DebugSession to see if I can implement something that would step into an execution until a given expression evaluates to a different value than the value it had at the beginning to quickly localise the precise point where an invariant is broken. But it appears that if the expression always evaluate to the same value, then the VM freezes. I simplified my program to just stepInto a debugSession indefinitely, and it makes the VM freeze, while I would rather expect an exception to be raised (something like "ReachedEndOfExecution"). Here is my example code. Beware, running it will freeze the VM. | program process context debugSession | program := [1+2]. process := program newProcess. context := process suspendedContext. debugSession := process newDebugSessionNamed: 'StepIntoForever' startedAt: context. [ true ] whileTrue: [ debugSession stepInto ]. Is there a way to have an exception be raised when a stepInto message is sent to a debugSession whose execution is finished, instead of just freezing the VM? Thomas

5 6

[ANN] Zeroconf stable will be moved tomorrow to 6.0 (as part of the release process)
by Esteban Lorenzano May 31, 2017

May 31, 2017

Hi, We will move stable to 6.0 and alpha to 7.0. So if you depend on something that can be affected by this, is the moment to update your scripts. cheers, Esteban

1 0