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

Re: [Pharo-dev] ZnEasy problem?

by Esteban Lorenzano

I can confirm it too on mac. A problem in the SSL plugin? (we know is not in the best shapeâ¦ but Iâd like to know why this was working before and not it stopped). Esteban > On 24 Mar 2017, at 08:48, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Hi guys > > in the mooc (first example) we have the following expression > > (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png' <http://pharo.org/web/files/pharo.png'>) > > and it does not work anymore. I'm pair programming with Amal in Rennes > from the university in italy and from her univ in Rennes > we both get on 60 and 50 > > and time out https > > sslException: text code: code > self error: > (String streamContents: [ :stream | > stream << 'SSL Exception: ' << text << ' [code:'. > stream print: code. > stream << ']' ]) > > Any idea. > > Tx in advance > > What platform are you on. > > On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 > I can confirm the same error with this... > (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png' <http://pharo.org/web/files/pharo.png'>). > > but picking some random SSL PNG, this works fine... > (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' <https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png'>). > > It is strange that you are getting an SSL error using http rather than https. > It seems the server is redirecting to http to https and maybe this is not handled? > https://geekflare.com/http-to-https-redirection/ <https://geekflare.com/http-to-https-redirection/> > > When was the last update to rewrite rules on the server? > > cheers -ben > > >

March 24, 2017

Re: [Pharo-dev] ZnEasy problem?

by Ben Coman

On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > in the mooc (first example) we have the following expression > > (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') > > and it does not work anymore. I'm pair programming with Amal in Rennes > from the university in italy and from her univ in Rennes > we both get on 60 and 50 > > and time out https > > sslException: text code: code > self error: > (String streamContents: [ :stream | > stream << 'SSL Exception: ' << text << ' [code:'. > stream print: code. > stream << ']' ]) > > Any idea. > > Tx in advance > What platform are you on. On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 I can confirm the same error with this... (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png'). but picking some random SSL PNG, this works fine... (ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' ). It is strange that you are getting an SSL error using http rather than https. It seems the server is redirecting to http to https and maybe this is not handled? https://geekflare.com/http-to-https-redirection/ When was the last update to rewrite rules on the server? cheers -ben

March 24, 2017

ZnEasy problem?

by Stephane Ducasse

Hi guys in the mooc (first example) we have the following expression (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') and it does not work anymore. I'm pair programming with Amal in Rennes from the university in italy and from her univ in Rennes we both get on 60 and 50 and time out https sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ]) Any idea. Tx in advance

March 24, 2017

Re: [Pharo-dev] Good way to promote Smalltalk

by philippe.back＠highoctane.be

Le 24 mars 2017 03:03, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : I was having a browse of the practice problems of Google's Code Jam and it strikes me that it would be useful to have a competition toolset for common tasks like: * interactively parsing text input data into objects * dealing with test cases * visualizing the input and output data to help cognitively understand the problem & solution. * producing a source code list in a suitable form for submission Definitely. And being deployable easily. Phil [1] https://code.google.com/codejam/contest/32003/dashboard#s=p0 cheers -ben On Fri, Mar 24, 2017 at 7:30 AM, Ben Coman <btc(a)openinworld.com> wrote: > It certainly makes a quantifiable measure of performance. > cheers -ben > > On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: >> Being able to shine in software competitions is a very good way for Smalltalk >> to get exposure. We should present our technologies as such competitions as >> much as possible. Enjoy the case below. >> http://www.cincomsmalltalk.com/main/2017/03/one-cincom- engineer-got-450-programmers-bite-smalltalk/ >> >> Aik-Siong Koh >> >> >> >> -- >> View this message in context: http://forum.world.st/Good- way-to-promote-Smalltalk-tp4939758.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>

March 24, 2017

Re: [Pharo-dev] How to install Iceberg?

by Stephan Eggermont

On 23/03/17 21:54, Christophe Demarey wrote: > Hi Alex, > > the master branch is quite old. > Please use dev-0.4 branch with the latest stable VM. How? Metacello new baseline: 'Iceberg'; repository: 'github://npasserini/iceberg:dev-0.4'; load

March 24, 2017

Re: [Pharo-dev] Good way to promote Smalltalk

by Ben Coman

I was having a browse of the practice problems of Google's Code Jam and it strikes me that it would be useful to have a competition toolset for common tasks like: * interactively parsing text input data into objects * dealing with test cases * visualizing the input and output data to help cognitively understand the problem & solution. * producing a source code list in a suitable form for submission [1] https://code.google.com/codejam/contest/32003/dashboard#s=p0 cheers -ben On Fri, Mar 24, 2017 at 7:30 AM, Ben Coman <btc(a)openinworld.com> wrote: > It certainly makes a quantifiable measure of performance. > cheers -ben > > On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: >> Being able to shine in software competitions is a very good way for Smalltalk >> to get exposure. We should present our technologies as such competitions as >> much as possible. Enjoy the case below. >> http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… >> >> Aik-Siong Koh >> >> >> >> -- >> View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>

March 24, 2017

Re: [Pharo-dev] Good way to promote Smalltalk

by Ben Coman

It certainly makes a quantifiable measure of performance. cheers -ben On Fri, Mar 24, 2017 at 12:57 AM, askoh <askoh(a)askoh.com> wrote: > Being able to shine in software competitions is a very good way for Smalltalk > to get exposure. We should present our technologies as such competitions as > much as possible. Enjoy the case below. > http://www.cincomsmalltalk.com/main/2017/03/one-cincom-engineer-got-450-pro… > > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Good-way-to-promote-Smalltalk-tp4939758.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 23, 2017

Re: [Pharo-dev] inspector performance improvement

by Andrei Chis

Hi Henry, On Thu, Mar 23, 2017 at 10:49 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > I guess I'm late to the party, downloaded the latest Moose image today, > compared to Pharo5/6, it's night and day! > Browsing large collections is quicker than I can ever remember, if emails > had emoticons, there'd be a :partyhat: right here, great job! > > You're probably aware already, but there's an issue with the indexes for > the items tab when collections contain the same object multiple times, say > Yes we know this issue. It's actually fixed in Pharo, but it seems that I forgot to port the slice also to the repo of the inspector. Will do that tomorrow. > > o := Object new. > oc := OrderedCollection new: 2. > 1 to: 2 do: [:i | oc add: o]. > oc inspect > > or > > ba := (ByteArray new: 20000) inspect. > 0 to: 19999 do: [:i | ba at: i + 1 put: i \\ 255 + 1]. > ba inspect. > > Finding a solution that avoids doing indexOf: lookups, but pass along the > index instead when needed would be nice ;) > That's actually how the view for SequenceableCollection objects works; this problem is related to caching. > > The second example also highlight that there seems to be a (legacy?) > restriction of 10k entries in the raw view; the list jumps from index 5000 > -> 15001, this shouldn't be necessary anymore, right?. > In Pharo 5 the limit was 42 :). We increased it in Pharo 6 to 10k as we thought it is good enough. The 'Items' presentation however always displays the entire number of elements. > > *EDIT* After some digging, and testing with a large collection where the > limit is raised, I can see why it's there... > Find attached some improvements to FT that should (at least act as a PoC > that it's possible to) improve performance enough with large trees to > possibly remove indexableDisplayLimit entirely. > Tested by inspecting a 2M ByteArray, while opening the tab took ~5 secs, > navigation/scrolling afterwards was smooth sailing > It's definitely possible to eliminate the indexableDisplayLimit. One solution is to use a lazy model that only computes visible items for all collection presentations. I see that your solution plays with #visibleChildren. That's definitely a way to improve the tree widget. We'll look at this more for Pharo 7. If you made it so far you can also give the automatic refresh of the Raw view a try :) (GTInspector enableStepRefresh). Cheers, Andrei > Cheers, > Henry > > > > On 13 Feb 2017, at 11:56 , Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > On Sun, Feb 12, 2017 at 5:07 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Any chance for this to run on a 5.0? > > > > There are two main changes: moved inspector to fast table and some > > fixes in the glamour renderer. > > Moving the changes for the glamour renderer should be straightforward. > > I can point you to the list of relevant commits if you want to make a > > slice (We'll just need afterwards to also update > > ConfigurationOfGlamourCore to still work for Pharo 5) > > > > The FastTable changes could require more work but that should also be > > doable. However, now we still have some issues to fix there so that's > > not done for the moment. > > > > > > Cheers, > > Andrei > > > > > >> > >> Phil > >> > >> On Sun, Feb 12, 2017 at 3:13 PM, stepharong <stepharong(a)free.fr> wrote: > >>> > >>> 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/ > >>> > >> > > > > >

March 23, 2017

Re: [Pharo-dev] inspector performance improvement

by Henrik Johansen

I guess I'm late to the party, downloaded the latest Moose image today, compared to Pharo5/6, it's night and day! Browsing large collections is quicker than I can ever remember, if emails had emoticons, there'd be a :partyhat: right here, great job! You're probably aware already, but there's an issue with the indexes for the items tab when collections contain the same object multiple times, say o := Object new. oc := OrderedCollection new: 2. 1 to: 2 do: [:i | oc add: o]. oc inspect or ba := (ByteArray new: 20000) inspect. 0 to: 19999 do: [:i | ba at: i + 1 put: i \\ 255 + 1]. ba inspect. Finding a solution that avoids doing indexOf: lookups, but pass along the index instead when needed would be nice ;) The second example also highlight that there seems to be a (legacy?) restriction of 10k entries in the raw view; the list jumps from index 5000 -> 15001, this shouldn't be necessary anymore, right?. *EDIT* After some digging, and testing with a large collection where the limit is raised, I can see why it's there... Find attached some improvements to FT that should (at least act as a PoC that it's possible to) improve performance enough with large trees to possibly remove indexableDisplayLimit entirely. Tested by inspecting a 2M ByteArray, while opening the tab took ~5 secs, navigation/scrolling afterwards was smooth sailing. Cheers, Henry > On 13 Feb 2017, at 11:56 , Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > On Sun, Feb 12, 2017 at 5:07 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >> Any chance for this to run on a 5.0? > > There are two main changes: moved inspector to fast table and some > fixes in the glamour renderer. > Moving the changes for the glamour renderer should be straightforward. > I can point you to the list of relevant commits if you want to make a > slice (We'll just need afterwards to also update > ConfigurationOfGlamourCore to still work for Pharo 5) > > The FastTable changes could require more work but that should also be > doable. However, now we still have some issues to fix there so that's > not done for the moment. > > > Cheers, > Andrei > > >> >> Phil >> >> On Sun, Feb 12, 2017 at 3:13 PM, stepharong <stepharong(a)free.fr> wrote: >>> >>> 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/ >>> >> >

March 23, 2017

Re: [Pharo-dev] How to install Iceberg?

by Christophe Demarey

Hi Alex, the master branch is quite old. Please use dev-0.4 branch with the latest stable VM. > Le 26 aoÃ»t 2016 Ã 11:46, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > You should search for it on GitHub :) > > Metacello new > baseline: 'Iceberg'; > repository: 'github://npasserini/iceberg'; > load > > Cheers, > Doru > > >> On Aug 26, 2016, at 11:40 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi all! >> >> I would like to give a try to Iceberg. >> >> I have no idea where to find it however. >> >> Cheers, >> Alexandre >> <Screen Shot 2016-08-26 at 11.39.42 AM.png><Screen Shot 2016-08-26 at 11.40.01 AM.png> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > >

March 23, 2017