February 2016 - Pharo-users

minimal image load config question

by Robert Kuszinger

Hello! I'm trying to load my app (config) into the minimal image from the command line. pharo min.image config http://smalltalkhub.com/mc/RobertKuszinger/GcUploader/main ConfigurationOfGiscomKkt --install=stable --username=<mylogin> --password=<mypwd> After a few seconds of working it stops like this (longer version at the end if this email): [....] OrderedCollection(Collection)>>do:displayingProgress:every: OrderedCollection(Collection)>>do:displayingProgress: *Got startup errors: * * MessageNotUnderstood: Unicode class>>isUnifiedKanji:* Does anyone have any idea *what to check*? Is there something missing? Minimal image is from the Pharo website. I've tested my config on a brand new Pharo4 image and it loads well... Should I preload another config into the image? Thanks -------------------------------- [kuszi@kuszidell pharo-minimal]$ pharo --version 3.9-7 #1 Thu Jan 7 00:37:02 CET 2016 gcc 4.6.3 [Production ITHB VM] NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Jan 7 2016 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Jan 7 2016 https://github.com/pharo-project/pharo-vm.git Commit: bad6fa2684afcf1d7cdb485f11049a4a4290fbc8 Date: 2015-12-14 12:47:06 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15027 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /usr/share/pharo-vm/ [default: /usr/share/pharo-vm/] --------------------------------- MethodAddition>>writeSourceToLog MethodAddition>>createCompiledMethod MCMethodDefinition>>addMethodAdditionTo: [ :each | each addMethodAdditionTo: methodAdditions ] in MCPackageLoader>>basicLoadDefinitions in Block: [ :each | each addMethodAdditionTo: methodAddition...etc... [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. ProgressNotification signal: '' extra: (oldLabel := newLabel) ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] in [ :bar | labelBlock := aStringOrBlock isString ifTrue: [ bar label: aStringOrBlock. [ :dummyItem | aStringOrBlock ] ] ifFalse: [ aStringOrBlock ]. self do: [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. ProgressNotification signal: '' extra: (oldLabel := newLabel) ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] ] in OrderedCollection(Collection)>>do:displayingProgress:every: in Block: [ :each | ... OrderedCollection>>do: [ :bar | labelBlock := aStringOrBlock isString ifTrue: [ bar label: aStringOrBlock. [ :dummyItem | aStringOrBlock ] ] ifFalse: [ aStringOrBlock ]. self do: [ :each | | newLabel | "Special handling for first and last element" (count = 0 or: [ count + 1 = size or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) ifTrue: [ bar current: count. oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ]) ifFalse: [ bar label: newLabel. ProgressNotification signal: '' extra: (oldLabel := newLabel) ]. lastUpdate := Time millisecondClockValue ]. aBlock value: each. count := count + 1 ] ] in OrderedCollection(Collection)>>do:displayingProgress:every: in Block: [ :bar | ... BlockClosure>>cull: [ result := block cull: self ] in [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ result := block cull: self ] BlockClosure>>on:do: [ self prepareForRunning. [ result := block cull: self ] on: JobNotification do: [ :notification | notification handle: self ] ] in Job>>run in Block: [ ... BlockClosure>>ensure: Job>>run DummyUIManager(UIManager)>>displayProgress:from:to:during: ByteString(String)>>displayProgressFrom:to:during: OrderedCollection(Collection)>>do:displayingProgress:every: OrderedCollection(Collection)>>do:displayingProgress: Got startup errors: MessageNotUnderstood: Unicode class>>isUnifiedKanji:

Feb. 28, 2016

Re: [Pharo-users] Who is using Pharo Launcher and for what

by Stephan Eggermont

On 20-02-16 11:49, Damien Cassou wrote: > I don't need long paragraphs, just give me the keywords please. Today I triaged a bug in CodePanel by downloading image versions 50600 50590 50595 50597 and 50596 and installing NewUI from the catalog browser to find out that it was broken by a change in 50596. With PharoLauncher it took me about 5 minutes, just long enough to wonder if I should automate this further, and just short enough to not bother. Stephan

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Stephan Eggermont

On 28-02-16 10:17, ClÃ©ment Bera wrote: > assuming tinyC has performance similar to gcc > or llvm, you may get faster, It does not. On the website they compare to -O1 speed and then are already twice as slow Stephan

Feb. 28, 2016

Helpful info for Fuel data migration

by Hilaire

Hello guys, It will be very helpful to migrate fuel data from one image to another to have written somewhere on the Fuel page[1], the Fuel number version shipped with each image release. Thanks Hilaire [1] http://rmod.inria.fr/web/software/Fuel -- Dr. Geo http://drgeo.eu

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by ClÃ©ment Bera

Hello, As Stephan Eggermont said, you need to make some measurements. There are a few big problems. In short, if the FFI call is going to do quite some computation (at least a few millisecond), assuming tinyC has performance similar to gcc or llvm, you may get faster, if the FFI call is going to do very little (calling Math.abs() for example as Pharo has no primitive for abs), the overhead of the call is going to be too big. Maybe you can make your runtime with C worth it, but for example it's clear that if you write tiny methods in C for reusability / modularity of your code and you bind each tiny method to the smalltalk runtime, using those tiny methods one by one is not going to be worth it. However, if you write a merge sort or another algorithm fully in C and do a single call to the algorithm to sort a collection, on large collection and large collections only, it's going to be worth it. In details, the main problems are: - the Smalltalk stack has specific constraints, like hand-written stack page management to support heavy stack manipulation (setting sender of a context from the image). Hence, a C stack cannot just grow inside the Smalltalk stack as in other languages directly integrated to C. The way FFI tackles this problem is by using the interpreter C stack to execute C code. This is problematic as the runtime needs to switch from assembly runtime (Smalltalk method generated from the jit) to C runtime for the FFI call and then switch back, which induces overhead in jitted code, i.e., performance critical code. Maybe you could change the way the jitted code activates C code by checking the stack size needed by the dynamic lib API and if there is enough room on the smalltalk stack, then call it on the Smalltalk stack, though it creates other problems (what if garbage collection happens from another native thread while the FFI call is performed in non blocking FFI ?). - you need to convert types between Smalltalk to C at each call inducing FFI call overhead or makes the C code aware of your data structures which you have to support for those Smalltalk data structure yourself and induces some overhead in the C runtime. In Smalltalk/X, the C runtime is directly integrated in the Smalltalk runtime. You can ask Jan Vrany how he does it. But I think he doesn't have our hand written stack management (I am not 100% sure). 2016-02-28 2:04 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > On 26/02/16 20:30, Dimitris Chloupis wrote: > >> I was thinking it would still be cool to have some kind of library that >> will help us boost the speed of pharo . So I was thinking about a C >> inliner which is far easier than an Assembly inliner (see AsmJIT) I also >> found TinyC >> > > The first thing to test is if TinyC is actually faster than Pharo. > > Stephan > > > >

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Esteban Lorenzano

> On 28 Feb 2016, at 02:04, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 26/02/16 20:30, Dimitris Chloupis wrote: >> I was thinking it would still be cool to have some kind of library that >> will help us boost the speed of pharo . So I was thinking about a C >> inliner which is far easier than an Assembly inliner (see AsmJIT) I also >> found TinyC > > The first thing to test is if TinyC is actually faster than Pharo. yes! but it can be a nice addition to gain part of what is lost with the removal of ASMJIT (not that anyone was using it, but well... :P) > > Stephan > > >

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Stephan Eggermont

On 26/02/16 20:30, Dimitris Chloupis wrote: > I was thinking it would still be cool to have some kind of library that > will help us boost the speed of pharo . So I was thinking about a C > inliner which is far easier than an Assembly inliner (see AsmJIT) I also > found TinyC The first thing to test is if TinyC is actually faster than Pharo. Stephan

Feb. 28, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by Julien Delplanque

I totally agree, I will do it and add this one. Maybe I will also make some research for similar content on the mailing list. Julien On 27/02/16 13:08, stepharo wrote: > Julien > > we should create a simple chapter with questions/answers and we > capture there such knowledge. > > Stef > > Le 25/2/16 11:30, Julien Delplanque a Ã©crit : >> Nice, can't wait to read it :) >> >> Julien >> >> On 25/02/16 10:58, Peter UhnÃ¡k wrote: >>> I'm sure it's documented somewhereâ¦ in any case new Spec >>> documentation is >>> emerging so let's not forget to make sure it's there. >>> >>> Peter >>> >>> On Thu, Feb 25, 2016 at 10:49 AM, Julien Delplanque <julien(a)tamere.eu> >>> wrote: >>> >>>> Indeed but I mean, I was not able to deduce the fact that to have a >>>> widget >>>> holding not-editable multi-line text I have to use >>>> >>>> TextInputFieldModel and use #enabled: message... >>>> >>>> But maybe there is already documentation about that? >>>> >>>> Julien >>>> >>>> >>>> >>>> On 25/02/16 09:58, Peter UhnÃ¡k wrote: >>>> >>>>> Maybe this should be documented in the class comment of >>>>>> TextInputFieldModel? >>>>>> >>>>>> This is a feature of AbstractWidgetModel, so it applies to all >>>>>> widgets >>>>> (buttons, texts, selects, ...). >>>>> >>>>> Peter >>>>> >>>>> >>>> >> >> >> > >

Feb. 27, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by stepharo

Julien we should create a simple chapter with questions/answers and we capture there such knowledge. Stef Le 25/2/16 11:30, Julien Delplanque a Ã©crit : > Nice, can't wait to read it :) > > Julien > > On 25/02/16 10:58, Peter UhnÃ¡k wrote: >> I'm sure it's documented somewhereâ¦ in any case new Spec >> documentation is >> emerging so let's not forget to make sure it's there. >> >> Peter >> >> On Thu, Feb 25, 2016 at 10:49 AM, Julien Delplanque <julien(a)tamere.eu> >> wrote: >> >>> Indeed but I mean, I was not able to deduce the fact that to have a >>> widget >>> holding not-editable multi-line text I have to use >>> >>> TextInputFieldModel and use #enabled: message... >>> >>> But maybe there is already documentation about that? >>> >>> Julien >>> >>> >>> >>> On 25/02/16 09:58, Peter UhnÃ¡k wrote: >>> >>>> Maybe this should be documented in the class comment of >>>>> TextInputFieldModel? >>>>> >>>>> This is a feature of AbstractWidgetModel, so it applies to all >>>>> widgets >>>> (buttons, texts, selects, ...). >>>> >>>> Peter >>>> >>>> >>> > > >

Feb. 27, 2016

Re: [Pharo-users] A Spec widget to hold non-editable multi-lines text?

by stepharo

Le 25/2/16 08:15, Julien Delplanque a Ã©crit : > Hi, > > Thank you it works as expected :) Maybe this should be documented in > the class comment of TextInputFieldModel? please send a change. Stef > > Regards, > > Julien > > On Wed, Feb 24, 2016 at 7:49 PM, Johan Fabry <jfabry(a)dcc.uchile.cl > <mailto:jfabry@dcc.uchile.cl>> wrote: > > Hello Julien, > > have you tried configuring it with enabled: false ? > > > On Feb 24, 2016, at 13:24, Julien Delplanque <julien(a)tamere.eu > <mailto:julien@tamere.eu>> wrote: > > > > Hello, > > > > I wonder if there is a Spec widget to hold non-editable > multi-line text? > > > > There is TextInputFieldModel but the text is editable. > > > > Thanks in advance, > > > > Julien > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > > >

Feb. 27, 2016