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

Re: [Pharo-dev] [ANN] Woden 2 first release for OS X and Linux

by Ben Coman

Cool news. I'll try it out soon. I found this paper on Lowcode to share with other curious people... http://www.esug.org/data/ESUG2016/IWST/Papers/IWST_2016_paper_16.pdf A few questions from that... > our extended instructions do not perform run time type checking on their inputs, so they do not have the overhead associated to dynamic message lookup." What happens if the wrong type object is passed to a lowcode method? > Unfortunately, when we did this work the 64 bits version of Spur was incomplete and in an experimental state [and we were] not able to compare the performance difference for floating point arithmetics against a Smalltalk with support for immediate floating point objects Have you been able to do this performance comparison since the paper was written? cheers -ben On Fri, Feb 24, 2017 at 9:02 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hello, > > Finally I am glad to announce a first release of Woden 2. I made a hopefully > simplified process for loading Woden 2 out of the box. > > For loading and testing Woden 2, follow the instructions at: > > https://github.com/ronsaldo/woden2 > > In this release, I am not loading the level editor by default because it > depends on an outdated version of Bloc. Until I fix the dependency problem > of the Level editor, it will remain unusable. > > Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which > can be unstable. This is tested on OS X El Capitan. I do not know whether it > will work or not on OS X Sierra. > > Best regards, > Ronie

Feb. 25, 2017

Re: [Pharo-dev] [ANN] Woden 2 first release for OS X and Linux

by Ronie Salgado

Hello, I fixed several bugs with Vulkan, so now it is not crashing anymore when using the Linux NVIDIA Vulkan driver. I still have to fix the stuttering problem with Vulkam. Best regards, Ronie 2017-02-24 6:38 GMT-03:00 nolwenn <nolwenn.fournier(a)fr.thalesgroup.com>: > Wonderful ! I will try it soon. > > Thanks ! > > Nolwenn > > > > -- > View this message in context: http://forum.world.st/ANN- > Woden-2-first-release-for-OS-X-and-Linux-tp4935693p4935742.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 25, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Sean P. DeNigris

Andreas Wacknitz wrote > Everything that is used outside Pharo could have a fancy name. > For internal tools and frameworks this is... like talking in argot and > creates high walls around Pharo. +100 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Any-idea-for-a-cool-name-for-the-remote-tool-suite-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 25, 2017

Re: [Pharo-dev] Code Completion in Pharo

by Ben Coman

Another random idea, that you can use something similar to Finder>Examples from within the debugger. That is, a shortcut brings up a small popup dialog kind-of inline with the cursor where you can feed live variables into the pattern matching. cheers -ben On Sat, Feb 25, 2017 at 7:09 AM, Ben Coman <btc(a)openinworld.com> wrote: > How would people feel about... > when an item is selected from the code completion popup (e.g. with > <Enter>) that the arguments get expanded as well. These might show up red > initially if there is no matching variable and easily show what needs to be > edited. > > cheers -ben > > On Wed, Feb 15, 2017 at 1:57 AM, <komarlu2(a)fit.cvut.cz> wrote: > >> Hello to all, >> >> I am a student at the Faculty of Information Technology of the Czech >> Technical University in Prague and I decided to make Code Completion in >> Pharo the topic of my Bachelor's degree and try to improve it. >> >> If you have suggestions on what should change / how to change it so you >> would be satisfied with it, I will appreciate any input on this topic. It >> would mean a lot to me if you could find two minutes and take this survey >> (there are only like 7 questions, so it won't take longer than those 2 >> minutes): >> >> https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwR >> snA_AX_e_7sZEz2XJQ4059nk_-LV6w/viewform >> >> Regards >> >> >> Lukas >> > >

Feb. 24, 2017

Re: [Pharo-dev] Code Completion in Pharo

by Ben Coman

How would people feel about... when an item is selected from the code completion popup (e.g. with <Enter>) that the arguments get expanded as well. These might show up red initially if there is no matching variable and easily show what needs to be edited. cheers -ben On Wed, Feb 15, 2017 at 1:57 AM, <komarlu2(a)fit.cvut.cz> wrote: > Hello to all, > > I am a student at the Faculty of Information Technology of the Czech > Technical University in Prague and I decided to make Code Completion in > Pharo the topic of my Bachelor's degree and try to improve it. > > If you have suggestions on what should change / how to change it so you > would be satisfied with it, I will appreciate any input on this topic. It > would mean a lot to me if you could find two minutes and take this survey > (there are only like 7 questions, so it won't take longer than those 2 > minutes): > > https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_ > 7sZEz2XJQ4059nk_-LV6w/viewform > > Regards > > > Lukas >

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Thierry Goubier

Hi Andrei, Le 24/02/2017 Ã 17:02, Andrei Chis a Ã©crit : > Hi Thierry, > > Strangely enough I'm getting different times on my machine > Just to start from the same baseline in a fresh Pharo 60411 image with > no changes to any of the inspectors over a series of runs I get: > > array := (1 to: 1000000) asArray. > [array inspect] timeToRun. "0:00:00:00.145" > [GTInspector inspect: array] timeToRun. "0:00:00:00.031" Yes, this is expected. I'm not comparing to the standard EyeInspector, but with my experiments with a FastTable-derived widget and the EyeInspector model. GTInspector is a lot faster than the normal EyeInspector. As default (the only one displaying 100k elements is the AltInspector) | array | array := (1 to: 1000000) asArray. [AltInspector inspect: array ] timeToRun. "0:00:00:00.096" [EyeInspector inspect: array] timeToRun. "0:00:00:00.364" [GTInspector inspect: array] timeToRun. "0:00:00:00.065" > If I change indexableDisplayLimit to 50000 and remove the Items view > then I get: > > [GTInspector inspect: array] timeToRun. "0:00:00:00.124" [GTInspector inspect: array] timeToRun. "0:00:00:00.256" So this time is to be compared to the "0:00:00:00.096". > I'm really interested in seeing what makes GTInspector slower on your > machine. Did you do other optimizations to SpecInspector? The optimisations are: - remove Spec (revert to a pure morphic application), - use a FastTable-derived widget for a tree view (with a 100k element limit), - have the GT views as subitems in the widget. > I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7 Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest. 5.0-201702231204 Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 VM: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Date: Thu Feb 23 13:04:59 2017 +0100 $ Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 i686 i386 GNU/Linux > Pharo VM version: > CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: > 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 > uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 > git@github.com:pharo-project/pharo-vm.git Commit: > 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 > By: GitHub <noreply(a)github.com <mailto:noreply@github.com>> > > Cheers, > Andrei > > > On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>>: > > > > On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > > Hi Andrei, > > 2017-02-24 11:31 GMT+01:00 Andrei Chis > <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>>: > > Hi Thierry, > > Indeed that's the simplest option now that we are using > fast table. > > Just now in the case of the Raw view an > OrderedCollection is used to store all displayed elements. > If you display large collections every time you open the > Raw view it will instantiate a collection of size 100k > and instantiate 100k objects of > type GTInspectorIndexedNode. With FastTable we can > lazily load elements so we should be able to remove this > behaviour and the limit. Just we need to make sure it > will play nicely with automatic refresh. There is also > the issue that when expanding an element in the tree if > it's a collection you don't want to expand all elements. > > > I'm not sure you need to worry too much about that one; in > practical experiments, creating that 100k collection for > viewing (and the associated nodes instances) isn't too > costly (unless creating the GTInspectorIndexedNodes has > hidden costs: I've only experimented with the EyeInspector > framework). > > > There should be no hidden costs in GTInspectorIndexedNodes. > I made some experiments in the latest Pharo version and opening > the Raw view on an array with one million numbers takes around > 120ms when 100k elements are computed. > I'll be curious how much it takes on your machine. To test > update indexableDisplayLimit to 50000 in > Object>>#gtInspectorVariableNodesIn: and remove the annotation > from Collection>>#gtInspectorItemsIn: (so that the Items > presentation is not loaded) > > arrayLarge := (1 to: 1000000) asArray. > arrayLarge inspect. > > > This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); > both inspectors displays 100k elements. > > (1 to: 1000000) asArray in: [ :s | [s inspect] timeToRun] > 0:00:00:00.064 > (1 to: 1000000) asArray in: [:s | [GTInspector inspect: s] > timeToRun] 0:00:00:00.381 > > Pharo 6 60411 > > > > > > Opening the tree with all elements works fine in my > experiments. Tuning scrolling as done in Bloc is necessary, > however. > > > > I'm looking now on a lazy data source for FastTable that > plays nicely with GTInspector. Let's see how it will go. > Help is always welcomed :) > > > As I said: do not overoptimize that part... just remove that > limitation on the raw view and measure. > > > If I measure the Items view on the previous array it takes > around 35ms. > What I'd like to have is the same opening time for the Items > view on large Sets and Dictionaries. > > > On my machine, the experiment is that displaying the set is fast, > but the system becomes totally unresponsive... which may be an issue > with the self refresh of the inspector. Yes, it was the culprit. > > (1 to: 1000000) asSet in: [ :s | [s inspect] timeToRun] 0:00:00:00.034 > (1 to: 1000000) asSet in: [:s | [GTInspector inspect: s] timeToRun] > 0:00:00:00.199 > > Regards, > > Thierry > > > > > > > > I think I used the word paginator in the wrong way. If > you have a very large collection (millions of elements) > I do not want to scroll through elements but most likely > jump to a certain element or view just a subset of all > elements. Not really add a paginator like in web pages. > > > Ok, millions of elements is a bit out of my scope... I'll > look for filtering then. > > > Yes, definitely filtering is the way to go there :) > > Cheers, > Andrei > > > > Regards, > > Thierry > > > > Cheers, > Andrei > > On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Andrei, > > if you're using fasttable for the Raw view, you > should be able to reach one 100k elements without > issues. I did some experiments and it handles the > load very well. > > Avoid the paginator at any cost. This thing is > really user-unfriendly. > > Regards, > > Thierry > > 2017-02-23 20:19 GMT+01:00 Andrei Chis > <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>>: > > Hi Stef, > > Currently that's the default behaviour of the > Raw view: it displays for collections only the > first and the last 21 elements. The Items view > however always should display all the elements > of a collection. > > The main problem with the Raw view in Pharo 5 is > the speed. In Pharo 6 now the speed of the Raw > view is greately improved so we could increase > those limits. Still for now there should still > be some limit for the Raw view. Ideally we > should add a small widget, something like a > paginator, for navigating through large and very > large collections. > > Cheers, > Andrei > > On Feb 23, 2017 19:35, "stepharong" > <stepharong(a)free.fr <mailto:stepharong@free.fr>> > wrote: > > Hi > > I'm trying to debug citezen generation and I > have to compare strings. > Now I think that the raw views (in Pharo 50) > is not good because we cannot see all the > items in raw format. > See the attachements. It jumps from 21 to > 174 ... > and what I want to see is of course in the > middle. > > Is it me or there is something wrong there. > Stef > > > > > > >

Feb. 24, 2017

Re: [Pharo-dev] Epicea user experience report

by Igor Stasenko

Epicea is most valuable jewel i ever wished to have in Pharo.. Martin big thanks for your effort to make such a wonderful piece of software. -- Best regards, Igor Stasenko.

Feb. 24, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Igor Stasenko

Call it Java[tm] .. .. what? i heard it is quite popular. albeit fuzzy wuzzy :) P.S. just call it Pharo-Remote and let it go -- Best regards, Igor Stasenko.

Feb. 24, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by stepharong

Apparently you do not know the amount of time we have to explain to students in FRANCE with internet blocked over a proxy that No Pharo is not dead. It is just a time out. So don't be egoist be adults and use the infrastructure. Use a preference in your system. Stef

Feb. 24, 2017

Re: [Pharo-dev] Catalog loading in Spotter

by stepharong

The compromise is that people add an expression in one line in their startup preferences. It sounds reasonable to me. Stef On Tue, 21 Feb 2017 12:26:43 +0100, Torsten Bergmann <astares(a)gmx.de> wrote: > As there were no further objections I guess we should do the following > steps as a compromise: > > 1. We switch back to how it was by selecting Solution A as it is the > old behavior and the pragmatic approach. > This avoids the confusion, allows to quickly search for the catalog > items and also renders the videos > valid again. > > 2. Pharo 6 is still not released. People can still be testing and if > this really gives trouble again > (maybe next time in a reproducible way) we can try to fix it/find > another solution. > In the worst case we can disable it by disabeling the Catalog > setting (not the GT extension itself) > so it is not confusing or hidden again in the Pharo settings. > > I've opened issue https://pharo.fogbugz.com/f/cases/edit/19732 and will > fix it. Lets see how it goes. > > Thanks > T. > > >> Gesendet: Montag, 20. Februar 2017 um 11:27 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] Catalog loading in Spotter >> >> >> > On 20 Feb 2017, at 10:30, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > >> > >> > 2017-02-20 10:27 GMT+01:00 Guillermo Polito >> <guillermopolito(a)gmail.com>: >> > As far as I remember, the main problem was not bandwidth but a >> blocking and non-responsive UI. >> > Imagine I'm in the university, or in a company with a proxy. And I >> forget to set the proxy. Then, while spotter tries to fetch catalog >> entries, it would block the image and throw a timeout error some >> minutes after. >> > >> > So, maybe for the future and besides Ben's C option (which I like) I >> have a >> > >> > D) Load catalog entries in background in a non-blocking way >> > - and while catalog entries are not yet available, they should not >> be shown >> > >> > AFIK the main problem was that there was not possilbe to do it >> non-blocking way. >> >> Yes that is true. (It is actually DNS resolving that is blocked in some >> freak case). >> >> But the thing is, the problematic situation only occurs for a very >> small percentage of people, like less than 1%, probably even much less. >> (Remember, nobody can produce a repeatable case for it). >> >> So the question is, is that enough reason to act as if we are still in >> the 90's when internet was a luxury and cut features that depend on it >> ? If you have no network today, you're in big trouble anyway. (Again, >> if you turn off your network, no blocking will happen at all, try it). >> >> So what is more important ? The general functionality of the 99.xxx % >> or the unreproducible freak case ? >> >> > -- Pavel >> > >> > >> > Even further, It would make sense a solution that mixes Ben's caching >> with background loading of the catalog entries... >> > >> > Guille >> > >> > On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc(a)openinworld.com> >> wrote: >> > On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares(a)gmx.de> >> wrote: >> > > In the past in Pharo it was possible to open Spotter, type in the >> name of a framework/project to load >> > > from catalog, perform a search and just hit ENTER to easily install >> the project. >> > > >> > > This was following the Spotter idea that it is easy to access most >> informations of Pharo >> > > with the Spotter tool. >> > > >> > > There always was and still is a setting in "Settings" -> "Catalog" >> -> "Display catalog projects in Spotter". >> > > This setting is ENABLED BY DEFAULT but could be switched off in the >> settings tool or custom preference >> > > scripts if this is problematic for someone. >> > > >> > > >> > > Now in Pharo 6 there is an additional class >> "GTSpotterExtensionSettings" to activate/deactivate >> > > Spotter extensions. While nearly all of the Spotter extensions are >> enabled the one for the catalog >> > > integration is DISABLED BY DEFAULT. >> > > >> > > This leads to several effects: >> > > >> > > 1. While in the past it was possible in a fresh Pharo image to >> search and install out of >> > > the box it is (as of today in the not yet released Pharo 6) >> not possible anymore to quickly >> > > start by searching and installing from catalog using Spotter. >> > > >> > > 2. It is very confusing that in the settings "Display catalog >> projects in Spotter" is enabled but a search >> > > in Spotter gives no results. Most people will not not know >> about the second setting and easily >> > > get lost and think this behavior is just broken. >> > > Also this second setting for the Spotter extension is much >> more hidden between all the other >> > > Spotter extension enablements very and hard to find. >> > >> > Generally its not good to have two settings for the one thing. >> > >> > > >> > > 3. Several of my youtube videos demonstrating Goodies like >> DesktopManager, QuickAccess, >> > > MessageFlowBrowser, ... directly start by loading the tools >> from Spotter. Anyone newbee who will >> > > follow these will not only be confused - but also stuck in >> trying Pharo when he learns >> > > from these videos. >> > >> > UI things do evolve and videos date. But these seem worthwhile to >> keep current. >> > >> > > >> > > I was asked several times on Slack and via Mail from people >> who were not able to reproduce ... this >> > > is really annyoing. Especially this gives the wrong impression >> to newbees. Things should be easy >> > > not complicated. >> > > >> > > To my knowledge disabling the Spotter search in Pharo 6 came up due >> to some Pharo teaching in regions >> > > with slow internet connection. >> > >> > This made sense at the time. It is a worse first impression if UI >> > lags when this central part of the UI is interfaced. >> > How often would it access the network? Every time? Or did it cache >> > the result for a day, etc? >> > >> > > I understand that we would like to support these Pharo users too as >> best >> > > as possible in their out of the box experience ... but (without >> being able to prove) I think that 90% or >> > > more Pharo users have a regular internet connection. Otherwise it >> would be hard to work with updates, >> > > project loading, PharoLauncher, STHub or Iceberg/GitHub. >> > > >> > > Also my own personal experience is that even on low bandwidth >> network this Catalog Spotter search for >> > > me was always fast enough (as I often use Pharo in trains with slow >> connections or on a Pi with slow >> > > connections and less processing power). I do not know about all >> others from the community. >> > > >> > > I invested hours in the past in developing and introducing the >> initial configuration browser to Pharo, >> > > later improved and helped shaping its replacement CatalogBrowser, >> also contributed this spotter search >> > > for the catalog items so things are more accessible, easy and >> enjoyable. That's why I also invested >> > > hours in udpating configs or pushing you to put things into catalog. >> > > >> > > Because accessibility is key. Only when things are easy to access >> and understandable people will >> > > enjoy Pharo. >> > > >> > > Currently in an out-of the box image this easy access to the >> projects via Spotter is blocked. >> > > Additionally I have to explain to anyone who asks me that there is >> a second non-obvious/more hidden setting >> > > leaving an unpleasant feeling how many others unknown to me will >> struggle with this issue. >> > > >> > > I see two solutions: >> > > >> > > A) We enable both settings by DEFAULT to bring back the Spotter >> search and installation >> > > of catalog items - with the clear benefit of having >> > > - the previous behavior in Pharo back >> > > - the out of the box ability to search for catalog >> projects in any fresh image >> > > - no confusion among the user base anymore regarding the >> settings >> > > - we have unbroken Youtube videos that newbees can >> continue to follow >> > > - if a user asks (like often) how to get Seaside, >> Artefact, Mongo, Teapot or other projects we can >> > > just tell him "search in Spotter and you should be fine" >> as most of them have a config in >> > > the catalog. >> > > >> > > Remember that not all of us know about all the github >> pages or nice Metacello expressions. >> > > So the easier things are found and accessible the better >> it is. >> > > >> > > B) If A is still a "No go" for the community we should at a >> minimum switch the defaults of >> > > the two settings: >> > > >> > > => we ENABLE the Spotter extension >> (GTSpotterExtensionSettings perform: >> #GTSpotter_spotterCatalogProjectsFor: with: true) >> > > => we DISABLE the catalog setting (CatalogSettings >> displayCatalogProjectsInSpotter: false) >> > > >> > > With this at least we have no confusion among the user base >> anymore regarding the settings. >> > >> > C) Could a STON file of the catalog be cached in the zip of >> > Image/Changes files? >> > That zip might be updated daily to keep it current. >> > Then in a fresh image Spotter searches the cached file for a instant >> response, >> > while the Catalog is updated from the network in the background. >> > >> > Even with fast Internet the Catalog should only need to auto-update >> once a day, >> > with results cached in a common file to be accessed when fresh images >> > are started. >> > >> > The Spotter UI might display the last update date as part of the >> > Catalog sub-heading in its results. >> > >> > cheers -ben >> > >> > > >> > > I would clearly and strongly vote for option A as my preferred one. >> > > >> > > I agree there are regions/continents with very low bandwidth - but >> Pharo will rival with state of the art >> > > technologies where loading/installation megabytes from the web is >> often not seen as an issue. There are >> > > many package registries out there (from debian packages) up to >> Maven, npm in JS, ... or look at Docker. >> > > Shuffling megabytes around is a reality in todays technologies. >> > > >> > > So to be honest I never understood this whole "bandwidth" >> discussion and even if this comes up it could >> > > be solved with a note in the download/welcome screen or pointing to >> a custom preference script for low bandwidth >> > > situations. >> > > >> > > Sorry for having to bring this up again ... but I would like this >> to be solved BEFORE Pharo 6 will >> > > be pushed out of the door. Keeping it like it is without further >> actions would be really stupid. >> > > >> > > Thanks for you comments, ideas or votes. >> > > >> > > Thanks >> > > T. >> > > >> > >> > >> > >> >> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 24, 2017