December 2015 - Pharo-dev - lists.pharo.org

[IMPORTANT] Starting migration to Spur VM
by Esteban Lorenzano Jan. 15, 2016

Jan. 15, 2016

We will start migration to Spur today. To complete it, we will require some time, specially to adapt the CI and check everything is ok. Spur will allow us to do a big step forward in Pharo development, in the concrete you will see it immediately for this: - We have noticed a speed increment of 100% in tiny benchmarks (and according to Eliot, it will be at least 35% in general on the system). - No more GC stops (noticeable when running large systems) - We will be able to scale our systems up to 2G memory consumption without loosing performance. But, this will have some drawbacks in the first times: 1) VM will not be compatible between versions anymore: Pharo 5.0 will have a Pharo Spur VM associated (and they are not compatible). - There WILL NOT be a "non-spur" version of Pharo 5.0. Once completed the transitions, this will be the only one. 2) NativeBoost-FFI implementation has been replaced with a new implementation who relies in ThreadedFFIPlugin and IA32Plugin. While we worked a lot to do this transition as painless as possible and we achieve a good level of backward compatibility (most uses of #nbCall: should work out of the box), there are some problems we cannot solve: - there are some stuff not possible to compatibilise, notably: - Structures now need to inherit from FFIExternalStructure - Arrays now are now shadowed - in general is a bit slower (impossible to compete with ASM) but in general is not perceptible. - THERE WILL BE BUGS AND NON-IMPLEMENTED FEATURES: Current implementation is validated with Athens and even Roassal was working, but of course that does not covers all cases. 2.1) ASMJIT will be removed from system and put in a separated packages. NOTE: There will be a blog post explaining FFI-NB architecture during the week. 3) There are more or less 70 new failing tests, some of them important than we need to fix as soon as possible. Please, please, please, help us with them :) 4) In general we foresee the system will became unstable some weeks, before it gets back to normal. Please be patient. 5) You will need to adapt your Pharo 5.0 related apps and CI processes (to take care about new VM). Some programs will stop work at all (for example, I think Pharo-launcher will need to be adapted).

12 16

#sum:, #detectSum:, #sumNumbers:
by Max Leske Jan. 15, 2016

Jan. 15, 2016

Hi guys, Collection defines #sum:, #detectSum: and #sumNumbers:, all of which accomplish the same (in principal) but with subtle differences: #sum: - uses #inject:into: with #anyOne as the injected element and will thus fail for empty collections #detectSum: - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot slower when dealing with large numbers (primitive fails and number conversion is necessary) #sumNumbers: - same as #sum but doesnât fail for empty collections. Only good for numbers though. Benchmarks: [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun 42391 [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun 18096 Can we settle for a single implementation? Such as (modified from #sumNumbers:): newSum: aBlock ^ self inject: (self ifEmpty: [ 0 ] ifNotEmpty: [ self anyOne ]) into: [ :sum :each | sum + (aBlock value: each) ] This implementation combines the best of the three implementations I think. Benchmark: [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 BTW, there is also the message #sum, which suffers from the same problem as #sum: (the implementation is basically a copy). #sum could be implemented as sum ^ self sum: [ :x | x ] As for the name for the new method, I suggest #sum:. Cheers, Max

21 96

.filetree file?
by Alexandre Bergel Jan. 13, 2016

Jan. 13, 2016

Hi! When using Filetree, there is this file .filetree in the git folder. What should I do with it? add it to the repository or ignore it? cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 4

Adapting the launcher to Spur VM
by Damien Cassou Jan. 8, 2016

Jan. 8, 2016

Hi, from a Pharo image, can I detect if another image needs the Spur VM or not? Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

10 17

last opened window does not go away
by Andrei Chis Jan. 6, 2016

Jan. 6, 2016

Hi, In the latest Pharo image there is a rogue instance of GLMSystemWindow. If I do in the console the following code I get one instance: /pharo Pharo.image eval "GLMSystemWindow allInstances" an Array(a GLMSystemWindow(58720256)) There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. ./pharo Pharo.image eval "SystemWindow allSubInstances" an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? Cheers, Andrei

4 5

Repeatable VM crash
by Hilaire Jan. 5, 2016

Jan. 5, 2016

When playing with equality in a class hierarchy I have repeatable VM crash. It is today Pharo VM 3.9-7 from Jenkins and Pharo3. Am I using an out of date VM? Crashdump enclosed Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

5 16

Kafka protocol
by Robert Withers Jan. 4, 2016

Jan. 4, 2016

This would be awesome in Pharo: https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot…. Since we cannot yet call JARs, implementing the wire protocol and API proxies would really be huge from an enterprise pharo standpoint. If other folks are interested in working on this, I could help out. Each topic has many partitions and replicates for fail-over. Say #pharo has 101 partitions with 2 replicas each, totals 300 partitions and two failovers per partition. Incoming pharo events would be partition by some algorithm. The basic consumer talks to zookeeper to get topology and then talks to partitions with "fetchers" to put blocks of in-sequence events into a shed queue. Then single-thread process them in the application level consumer, by having it consume from the shared queue. The basic consumer reads from zookeeper then writes to various partitions. regards, robert

5 10

NeoJSON: parsing mapped nil fields
by Skip Lentz Jan. 4, 2016

Jan. 4, 2016

Hi all, When parsing with NeoJSON, Iâm experiencing some problems. If I parse a JSON representation using NeoJSONReader>>next (i.e. not according to a schema), it parses nil fields just fine. But when I explicitly set a value schema, it wonât parse it in the case it is nil (or ânullâ in JSON). Is there a way to let it return nil in the case the parser encounters ânullâ, and otherwise serialize it as a value schema (e.g. a Point class). Taking the example from the paper (https://github.com/svenvc/docs/blob/master/neo/neo-json-paper.md <https://github.com/svenvc/docs/blob/master/neo/neo-json-paper.md>): (NeoJSONReader on: ânull' readStream) mapInstVarsFor: Point; nextAs: Point. Is there a way to adapt the above snippet so that it evaluates to ânilâ instead of resulting in an error? I ask because I am parsing an API response which sometimes contains a ânullâ field, and sometimes a JSON object for that field. Thanks.

2 4

EyeInspector with subclasses of ProtoObject
by Esteban A. Maringolo Jan. 3, 2016

Jan. 3, 2016

I'm dealing with the MessageArchiver of GLORP which is a subclass of ProtoObject and handles the "transparent" creation of expressions vÃa a DNU resolution. The problem I'm facing is that the EyeInspector expects the value in its value holder to respond to #basicSize, and because MessageArchiver inherits from ProtoObject it doesn't understand it. The problem is here: EyeInspector>>#variableFieldsToShow "Answers the indexes of the variable fields of the object to show. Shorten the list for very long collection (cf limit1 and limit2)" |bSize| bSize := self objectVariableSize. ^ bSize <= (self limit1 + self limit2) ifTrue: [1 to: bSize] ifFalse: [(1 to: self limit1) , (bSize - self limit2 + 1 to: bSize)]. If I implement #basicSize in MessageArchiver things go bananas. If I doesn't, and because #objectVariableSize is sent to MessageAchiver "proxy", bSize ends up with an instance of the MessageArchiver instead of an integer. I implemented #inspectorClass in MessageArchiver class to return EyeBasicInspector, but it is the same. Question: Is it documented what I should define/override in my classes to support EyeInspector? Regards, Esteban A. Maringolo pd: Stack trace =========== UndefinedObject(Object)>>error: MessageArchiver>>mustBeBoolean EyeBasicInspector(EyeInspector)>>variableFieldsToShow EyeBasicInspector(EyeInspector)>>addVariableFields: EyeBasicInspector(EyeInspector)>>generateElements EyeBasicInspector(EyeInspector)>>updateList EyeBasicInspector(EyeInspector)>>objectChanged [ self objectChanged ] in EyeBasicInspector(EyeAbstractInspector)>>initializePresenter in Block: [ self objectChanged ] BlockClosure>>cull: BlockClosure>>cull:cull: BlockClosure>>cull:cull:cull: BlockClosure>>cull:cull:cull:cull:

8 26

Preview of new FFI?
by Pierce Ng Jan. 1, 2016

Jan. 1, 2016

Hi, (For Esteban perhaps...) Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 work with SQLcipher (for transparent database encryption) but don't want to spend any effort refactoring if I need to redo for the new FFI. Pierce

5 8