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

Re: [Pharo-dev] Pharo wiki

by stepharong

remember that we have this http://pharo.gemtalksystems.com stef On Sat, 11 Feb 2017 23:22:11 +0100, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I try to use StackOverflow documentation to document some Pharo stuff. > Itâs very limited, but it has all the collaborative stuff from > StackOverflow, so somehow I believe there is less effort needed to > >manage permissions. > > Uko > >> On 10 Feb 2017, at 21:14, philippe.back(a)highoctane.be >> <philippe.back(a)gmail.com> wrote: >> >> I miss the Squeak wiki Pharo style. >> >> Phil >> >> Le 10 fÃ©vr. 2017 19:06, "Esteban A. Maringolo" <emaringolo(a)gmail.com> a >> Ã©crit : >>> 2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>> Mass adoption and hyper reduced friction to get people on board. >>>> >>>> For me: I have 10+ slack teams in my slack client and there is really >>>> no >>>> point in having more clients on the desktop. >>> >>> +1 to this. This is key. >>> >>> Maybe what we're missing is a simple wiki to collect the shared >>> knowledge, recipes, and other stuff. >>> >>> >>> Esteban A. Maringolo >>> > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

Re: [Pharo-dev] inspector performance improvement

by stepharong

Great job!!!! It feels lot snappier :) Now it is a real pleasure to navigate objects. This is nice to see that you are paying attention because the engine is getting faster and this is important that the tools do not eat all the power by accident. Tx a lot On Sat, 11 Feb 2017 21:31:56 +0100, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Andrei and Alex did a great job at improving the performance and > scalability of the inspector. > > There are a couple of main improvements: > - Added FastTable support for the Raw presentation for all objects. This > implied completing the support for the tree presentation binding to fast > table. > - Moved the Items presentation for collections to FastTable. > - Improved the rendering of Glamour to no longer rely on the default > Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers > a relayout of the morph, even if it is not visible. We extended > PanelMorph in the context of Glamour with a less needy logic. > > I will not tell you how fast it is. I would rather want you to play with > it :). > > The change is already in the Moose image. It is not yet in Pharo, but it > will be soon. In the meantime you can be load it in Pharo 6 like this: > > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'ConfigurationOfGToolkitCore'; > load. > (#ConfigurationOfGToolkitCore asClass project version: #stable) load > > To play with it, try this with both the current version and the new one > and the Spec Inspector if you want (just make sure you save the image > beforehand): > > collection := (1 to: 100000000) asArray. > [collection inspect] timeToRun. > > collection := (1 to: 100000000). > [collection inspect] timeToRun. > > (for these two ones notice that Items do not appear at all in the old > implementation) > > [World inspect] timeToRun. > > > There are still a couple of issues open, such as the sorting of the > columns. We would need your help with testing this, and report possible > missing issues. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

Re: [Pharo-dev] GLMAction and PharoShortcut

by Ben Coman

On Sun, Feb 12, 2017 at 6:32 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > While writing these tooltips for the debugger, it seems to me some > refactoring is needed in the use of Pharo shortcut: > https://pharo.fogbugz.com/f/cases/19684/GLMAction-and- > PharoShortcut-need-refactoring > > because the current situation to have Glamour tk rendering short cut as > 'Ctrl-A' then Spec as 'Meta-A' > > Any opinion on the topic. > Well spotted. They should be consistent. I guess the next questions are; * Does Glamour convert cross platform Meta-x definitions to platform specific in its rendering? Or are the Ctrl-xx hard coded? * If the former, can Spec be made to do the same conversion for its rendering? * Or do we prefer to refer to the general Meta-x throughout the UI? cheers -ben

Feb. 12, 2017

Context stack semantics (was Re: GTDebugger variables table)

by Ben Coman

On Fri, Feb 3, 2017 at 11:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, Feb 3, 2017 at 10:21 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> Or maybe it [Stack] would be better as a tab of thisContext's next pane. >> > > Actually you can try this now... > > Context>>stackValueMap > | stackValues stackDepth| > stackValues := OrderedCollection new. > stackDepth := self basicSize min: 21. > (stackDepth to: 1 by: -1) do: [ :index | > |key| > key := (index = stackDepth) ifTrue: ['Top'] ifFalse: [(stackDepth - index + > 1) asString]. > stackValues add: (key -> (self basicAt: index)) > ]. > ^stackValues > > Context>>gtInspectorStackValuesIn: composite > <gtInspectorPresentationOrder: 40> > | stackValues | > stackValues := self stackValues. > ^ (composite table) > title: 'Stack'; > display: [ self stackValueMap ]; > column: 'Depth' evaluated: [ :assoc | assoc key ] width: 50; > column: 'Item' evaluated: [ :assoc | GTObjectPrinter new > asTruncatedTextFrom: assoc value ] > > > I'm not sure whether the #stackValueMap is an appropriate name. Perhaps it > should be #methodStackValueMap or something else? Similar for the tab name. A couple of times already I've missed not having this in fresh Images. Since its simple and low impact I hoping to add it for Pharo 6, but I'd like to check the semantics are right As a comparison, what I understand of C lang is it has only one stack (per thread) for: * execution flow return to caller's next statement * function parameters * function local variables So C kind of combines call stack and variable stack.. In Pharo, the top pane of the debugger shows a stack of Contexts as returned by "thisContext stack" which is effectively is for * execution flow return to caller's next statement And from what I learnt writing #stackValueMap above it seems , that each Context has its own stack for: * function parameters * function local variables * calculations / parameter marshalling for message sends So how should the second stack be referred to? Any of the following? * methodStackValues? * contextStackValues? * valueStack? * stackValues? and btw I wonder if Context>>stack would be better named Context>>callStack Here is my current refinement of the methods... Context>>stackValues | stackValues stackDepth| stackValues := OrderedCollection new. stackDepth := self basicSize min: 21. (stackDepth to: 1 by: -1) do: [ :index | stackValues add: (self basicAt: index) ]. ^stackValues Context>>composite <gtInspectorPresentationOrder: 30> |stackValues| stackValues := self stackValues. ^ composite table title: 'Value Stack'; display: [ :aCollection | [(1 to: stackValues size) collect: [ :index | index -> (stackValues at: index) ]] on:Error do:[#()]]; beMultiple; column: 'Index' evaluated: [ :assoc | (assoc key = 1 ifTrue: ['Top'] ifFalse: [ assoc key asString ])] width: 50; column: 'Item' evaluated: [ :assoc | GTObjectPrinter new asTruncatedTextFrom: assoc value ]; send: [ :result | result isNil ifTrue: [ nil ] ifFalse: [ result value size = 1 ifTrue: [result anyOne value] ifFalse: [self species withAll: (result collect: [:each | each value])]]]; showOnly: 50 cheers -ben

Feb. 12, 2017

GLMAction and PharoShortcut

by Hilaire

Hi, While writing these tooltips for the debugger, it seems to me some refactoring is needed in the use of Pharo shortcut: https://pharo.fogbugz.com/f/cases/19684/GLMAction-and-PharoShortcut-need-re… because the current situation to have Glamour tk rendering short cut as 'Ctrl-A' then Spec as 'Meta-A' Any opinion on the topic. Hilaire -- Dr. Geo http://drgeo.eu

Feb. 12, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Sven Van Caekenberghe

Note that he managed to run the System Report UI, which means his image was running pretty normally at some point ... > On 12 Feb 2017, at 10:26, Ben Coman <btc(a)openinworld.com> wrote: > > On Sun, Feb 12, 2017 at 5:18 AM, Andriy Tykhonov <atykhonov(a)gmail.com> wrote: >> Ben Coman <btc(a)openinworld.com> writes: >> >>> Are you on 64-bit using 32-bit Pharo? >> >> This is not pure 64-bit system. This is multilib setup. So, I can execute >> 32-bit and 64-bit programs on the same machine. This is recent system >> installation, and Pharo doesn't work well on it. But it did work well on >> another Gentoo Linux system with the same multilib support. >> >>> Can you use ldd to check the pharo binary is linking to these 32-bit libraries? >>> http://pharo.org/gnu-linux-installation >> >> $ ldd ./pharo-vm/pharo >> >> linux-gate.so.1 (0xf76f6000) >> libm.so.6 => /lib32/libm.so.6 (0xf7664000) >> libdl.so.2 => /lib32/libdl.so.2 (0xf765f000) >> libpthread.so.0 => /lib32/libpthread.so.0 (0xf7643000) >> libc.so.6 => /lib32/libc.so.6 (0xf7496000) >> /lib/ld-linux.so.2 (0xf76f7000) > > Okay, so four out of six are obviously bound to 32bit libs. > > linux-gate seems okay per... > http://man7.org/linux/man-pages/man7/vdso.7.html > Note that the vDSO that is used is based on the ABI of your user- > space code and not the ABI of the kernel. Thus, for example, when > you run an i386 32-bit ELF binary, you'll get the same vDSO > regardless of whether you run it under an i386 32-bit kernel or under > an x86_64 64-bit kerne l. > > Could you check if ld-linux symlinks to 32-bit location? > >> >> This is mostly the same output (except addresses, such as 0xf76f6000, -- >> I'm writing about this fact just because I'm not sure whether it is >> important) which I had seen on the previous Gentoo Linux system. >> >>> >>> When you get it working can you provide a recipe for the download page. >>> >>> Alternatively you might try either (pre-release) 64-bit VM from... >>> http://files.pharo.org/vm/pharo-spur64/linux/ >>> * pharo-linux-x86_64threaded-201702061308-aa78f27.zip >>> * pharo-linux-x86_64itimer-201702030802-61970b6.zip >> >> I have tried both with the image downloaded from >> http://files.pharo.org/image/60/ (Pharo-Image-6.0-latest.zip). >> >> I get the same result: >> >> $ ./pharo Pharo-60386.image >> This interpreter (vers. 68021) cannot read image file (vers. 6521). >> Press CR to quit... >> zsh: exit 1 ./pharo ../tmp64/Pharo-60386.image > > I'm not completely sure, but I think this indicates you're using > a 64-bit VM (68021) to open a 32-bit Image (6531). > IIUC you need to use Pharo64-60386.image from this zip... > > However I guess Scale needs FFI and I'm not sure > of 64 bit FFI status on Linux. (Esteban?) > >>> http://files.pharo.org/image/60/ >>> * 60385-64.zip > > >>> On Sat, Feb 11, 2017 at 5:49 AM, Andrey Tykhonov <atykhonov(a)gmail.com> wrote: >>>> Hi all, >>>> >>>>> and which VM do you use (there is a System report browser where you can >>>>> find the information. >>>> >>>> I've somehow managed to get the information from System report browser: >>>> >>>> Image >>>> ----- >>>> /home/demi/mess/2017/06/tmp2/Pharo.image >>>> Pharo5.0 >>>> Latest update: #50768 >>>> Unnamed >>>> >>>> Virtual Machine >>>> --------------- >>>> /home/demi/mess/2017/06/tmp2/pharo-vm/pharo >>>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> https://github.com/pharo-project/pharo-vm.git Commit: >>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >>>> >>>> Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 >>>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: >>>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >>>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>>> >>>> >>>> I noticed that there are more items which could be selected (list in the >>>> left bar, I mean System report browser), but I cannot get more info, because >>>> pharo crashes each time I try to select all text from the all items. May be >>>> it would be helpful (and I'll be able to) to get information only from some >>>> particular item? But then, I need to know which exactly items would be >>>> helpful. >>>> >>>> Also, I'm attaching to this email log file after execution of the Pharo with >>>> strace: >>>> >>>> strace ./pharo-ui Pharo.image > pharo-ui-with-strace.log 2>&1 >>>> >>>> I hope it could shed more light on the issue.

Feb. 12, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Ben Coman

On Sun, Feb 12, 2017 at 5:18 AM, Andriy Tykhonov <atykhonov(a)gmail.com> wrote: > Ben Coman <btc(a)openinworld.com> writes: > >> Are you on 64-bit using 32-bit Pharo? > > This is not pure 64-bit system. This is multilib setup. So, I can execute > 32-bit and 64-bit programs on the same machine. This is recent system > installation, and Pharo doesn't work well on it. But it did work well on > another Gentoo Linux system with the same multilib support. > >> Can you use ldd to check the pharo binary is linking to these 32-bit libraries? >> http://pharo.org/gnu-linux-installation > > $ ldd ./pharo-vm/pharo > > linux-gate.so.1 (0xf76f6000) > libm.so.6 => /lib32/libm.so.6 (0xf7664000) > libdl.so.2 => /lib32/libdl.so.2 (0xf765f000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7643000) > libc.so.6 => /lib32/libc.so.6 (0xf7496000) > /lib/ld-linux.so.2 (0xf76f7000) Okay, so four out of six are obviously bound to 32bit libs. linux-gate seems okay per... http://man7.org/linux/man-pages/man7/vdso.7.html Note that the vDSO that is used is based on the ABI of your user- space code and not the ABI of the kernel. Thus, for example, when you run an i386 32-bit ELF binary, you'll get the same vDSO regardless of whether you run it under an i386 32-bit kernel or under an x86_64 64-bit kerne l. Could you check if ld-linux symlinks to 32-bit location? > > This is mostly the same output (except addresses, such as 0xf76f6000, -- > I'm writing about this fact just because I'm not sure whether it is > important) which I had seen on the previous Gentoo Linux system. > >> >> When you get it working can you provide a recipe for the download page. >> >> Alternatively you might try either (pre-release) 64-bit VM from... >> http://files.pharo.org/vm/pharo-spur64/linux/ >> * pharo-linux-x86_64threaded-201702061308-aa78f27.zip >> * pharo-linux-x86_64itimer-201702030802-61970b6.zip > > I have tried both with the image downloaded from > http://files.pharo.org/image/60/ (Pharo-Image-6.0-latest.zip). > > I get the same result: > > $ ./pharo Pharo-60386.image > This interpreter (vers. 68021) cannot read image file (vers. 6521). > Press CR to quit... > zsh: exit 1 ./pharo ../tmp64/Pharo-60386.image I'm not completely sure, but I think this indicates you're using a 64-bit VM (68021) to open a 32-bit Image (6531). IIUC you need to use Pharo64-60386.image from this zip... However I guess Scale needs FFI and I'm not sure of 64 bit FFI status on Linux. (Esteban?) >> http://files.pharo.org/image/60/ >> * 60385-64.zip >> On Sat, Feb 11, 2017 at 5:49 AM, Andrey Tykhonov <atykhonov(a)gmail.com> wrote: >>> Hi all, >>> >>>> and which VM do you use (there is a System report browser where you can >>>> find the information. >>> >>> I've somehow managed to get the information from System report browser: >>> >>> Image >>> ----- >>> /home/demi/mess/2017/06/tmp2/Pharo.image >>> Pharo5.0 >>> Latest update: #50768 >>> Unnamed >>> >>> Virtual Machine >>> --------------- >>> /home/demi/mess/2017/06/tmp2/pharo-vm/pharo >>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> https://github.com/pharo-project/pharo-vm.git Commit: >>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: >>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >>> >>> Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 >>> VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: >>> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: >>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >>> CoInterpreter VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >>> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >>> >>> >>> I noticed that there are more items which could be selected (list in the >>> left bar, I mean System report browser), but I cannot get more info, because >>> pharo crashes each time I try to select all text from the all items. May be >>> it would be helpful (and I'll be able to) to get information only from some >>> particular item? But then, I need to know which exactly items would be >>> helpful. >>> >>> Also, I'm attaching to this email log file after execution of the Pharo with >>> strace: >>> >>> strace ./pharo-ui Pharo.image > pharo-ui-with-strace.log 2>&1 >>> >>> I hope it could shed more light on the issue. >>> >>> >

Feb. 12, 2017

Re: [Pharo-dev] Pharo wiki

by Alistair Grant

On 12 February 2017 at 09:22, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I try to use StackOverflow documentation to document some Pharo stuff. Itâs > very limited, but it has all the collaborative stuff from StackOverflow, so > somehow I believe there is less effort needed to manage permissions. > > Uko Uko, thanks for mentioning this, I wasn't aware of it, and will try and contribute a bit to build the knowledge base (I don't believe email or chat (slack, discord, etc.) even with a searchable history, can replace a wiki for documentation). There's been quite a bit of discussion in the past about in-image documentation vs external documentation (e.g. wikis, books, etc.). While I like the idea of having the documentation in image, the delays and cost of getting documentation in to the core image currently makes it largely impractical to have the same level of contribution as a wiki. Recently I've seen in a couple of places people mentioning that github and/or gitlab allow simple editing of files in the web interface and directly generating pull requests. Given that the class comment is stored in a separate file, could this help facilitate the development of in-image documentation? If there's no one that knows more about this than me, and there is some interest, I'm happy to investigate a bit further. Cheers, Alistair

Feb. 12, 2017

Re: [Pharo-dev] Pharo wiki

by Yuriy Tymchuk

I try to use StackOverflow documentation to document some Pharo stuff. Itâs very limited, but it has all the collaborative stuff from StackOverflow, so somehow I believe there is less effort needed to manage permissions. Uko > On 10 Feb 2017, at 21:14, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > I miss the Squeak wiki Pharo style. > > Phil > > Le 10 fÃ©vr. 2017 19:06, "Esteban A. Maringolo" <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> a Ã©crit : > 2017-02-10 14:59 GMT-03:00 phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>>: > > Mass adoption and hyper reduced friction to get people on board. > > > > For me: I have 10+ slack teams in my slack client and there is really no > > point in having more clients on the desktop. > > +1 to this. This is key. > > Maybe what we're missing is a simple wiki to collect the shared > knowledge, recipes, and other stuff. > > > Esteban A. Maringolo >

Feb. 11, 2017

Re: [Pharo-dev] Segmentation fault while installing Scale

by Andrey Tykhonov

Hi all, I've managed to get all information from the System report browser. I'll attach it to this email. Surprisingly (at least for me), Pharo doesn't crash if I execute it like the following: strace -f ./pharo-ui Pharo.image (before this, I executed it without -f). So, I'm attaching also part of the output from the command execution. strace generates a lot of such log messages like you can see in the log file strace-f-pharo.log (something is wrong, but I'm not sure what exactly is wrong). Best regards, Andriy.

Feb. 11, 2017