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

Re: [Pharo-dev] Redline: Talking Runtime basics ...

by James Ladd

Monty I'll have a look at Cuis thanks Sent from my Commodore 64 On 30 Dec 2016, at 9:16 pm, monty <monty2(a)programmer.net> wrote: >> Sent: Thursday, December 29, 2016 at 6:51 PM >> From: "James Ladd" <ladd.james(a)gmail.com> >> To: pharo-dev(a)lists.pharo.org >> Subject: [Pharo-dev] Redline: Talking Runtime basics ... >> >> Hi Pharo People, >> >> I have continued work on Redline Smalltalk and I'm wanting to discuss what > > Nice to hear Redline is still under development. > >> the absolute minimum >> set of Classes and method should be included in the Redline Runtime. > > Have you looked at Cuis? > >> Would anyone here like to participate in that discussion? >> >> - James. >> Redline Smalltalk <http://redline.st> >> >> >> >> -- >> View this message in context: http://forum.world.st/Redline-Talking-Runtime-basics-tp4928375.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> >

Dec. 30, 2016

Re: [Pharo-dev] Redline: Talking Runtime basics ...

by Pavel Krivanek

It is better to use smaller bootstrapped image without Monticello but it is still quite big. https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-01-00-Bootstr… -- Pavel 2016-12-30 18:13 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james(a)gmail.com> wrote: > > Hi Pharo People, > > > > I have continued work on Redline Smalltalk and I'm wanting to discuss > what > > the absolute minimum > > set of Classes and method should be included in the Redline Runtime. > > > > Would anyone here like to participate in that discussion? > > > > - James. > > Redline Smalltalk <http://redline.st> > > Nice to hear you are continuing. > I'm not very knowledgable on this, but I'll show you how to pull some > data from the work on producing a minimal image. > > 1. From PharoLauncher > Templates > Pharo 6.0(beta) > download/create an image of build "60334-minimal". > 2. Right-click on the image and choose [Copy pathname] > 3. In a shell, change to that directory, and execute the following > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses > size" > ==> 2801 > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class > allSubclasses size" > ==> 1399. > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class > printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt > > I've attached the output of that last one. > > 4. For comparison, in a standard 60334 image, > Object allSubclasses size "==>11923". > Object class allSubclasses size "==>5959". > > Now in Pharo 6, the minimal image starts with a standard image and > strips these things out... > https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2- > Minimal/ws/output.txt > > In Pharo 7, there will be a new build system that it will start with a > minimal image and build it up to a normal image. So this may provide > a better way to understand the order that things need to be > implemented. > > cheers -ben >

Dec. 30, 2016

Re: [Pharo-dev] Redline: Talking Runtime basics ...

by philippe.back＠highoctane.be

Amber took a bunch of classes and this could be a nice starting point for fundamentals. Phil Le 30 dÃ©c. 2016 18:14, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james(a)gmail.com> wrote: > > Hi Pharo People, > > > > I have continued work on Redline Smalltalk and I'm wanting to discuss > what > > the absolute minimum > > set of Classes and method should be included in the Redline Runtime. > > > > Would anyone here like to participate in that discussion? > > > > - James. > > Redline Smalltalk <http://redline.st> > > Nice to hear you are continuing. > I'm not very knowledgable on this, but I'll show you how to pull some > data from the work on producing a minimal image. > > 1. From PharoLauncher > Templates > Pharo 6.0(beta) > download/create an image of build "60334-minimal". > 2. Right-click on the image and choose [Copy pathname] > 3. In a shell, change to that directory, and execute the following > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses > size" > ==> 2801 > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class > allSubclasses size" > ==> 1399. > $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class > printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt > > I've attached the output of that last one. > > 4. For comparison, in a standard 60334 image, > Object allSubclasses size "==>11923". > Object class allSubclasses size "==>5959". > > Now in Pharo 6, the minimal image starts with a standard image and > strips these things out... > https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2- > Minimal/ws/output.txt > > In Pharo 7, there will be a new build system that it will start with a > minimal image and build it up to a normal image. So this may provide > a better way to understand the order that things need to be > implemented. > > cheers -ben >

Dec. 30, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

Hi Yuriy 2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Wow, Denis, this is super cool! I really like that you have these âNew > methodâ tabs because I find it super confusing that you have to either > select no methods or change the existing method to create a new one. > > I would be really happy on any feedback about the Renraku (critiques > model) integration as I want to make it easily usably by any tool, and > feedback from tool developers is very valuable. > Now critiques are only supported as in MessageBrowser because it was just one line of code. To support Nautilus style (footer pane) we first need to decide who is responsible for it. Because In Calypso there are two ways how to achieve it: it could be part of method/class editor tool or it could be global browser footer pane independent from tabs. So it needs some analysis. For example first way will hide critiques when user switch to comment tab or other tab which is not method/class editor. Is it desired or not? And what is desired? Another thing from you which I want support is matcher/rewriter tool. I opened issue for this https://github.com/dionisiydk/Calypso/issues/10. Anyway all these features require documentation from me on how extend things. It is first in my todo.

Dec. 30, 2016

Re: [Pharo-dev] Redline: Talking Runtime basics ...

by Ben Coman

On Fri, Dec 30, 2016 at 7:51 AM, James Ladd <ladd.james(a)gmail.com> wrote: > Hi Pharo People, > > I have continued work on Redline Smalltalk and I'm wanting to discuss what > the absolute minimum > set of Classes and method should be included in the Redline Runtime. > > Would anyone here like to participate in that discussion? > > - James. > Redline Smalltalk <http://redline.st> Nice to hear you are continuing. I'm not very knowledgable on this, but I'll show you how to pull some data from the work on producing a minimal image. 1. From PharoLauncher > Templates > Pharo 6.0(beta) download/create an image of build "60334-minimal". 2. Right-click on the image and choose [Copy pathname] 3. In a shell, change to that directory, and execute the following $ ../../VMs/spur/pharo 60334-minimal.image eval "Object allSubclasses size" ==> 2801 $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class allSubclasses size" ==> 1399. $ ../../VMs/spur/pharo 60334-minimal.image eval "Object class printHierarchy" > /tmp/60334-minimal-class-hierarchy.txt I've attached the output of that last one. 4. For comparison, in a standard 60334 image, Object allSubclasses size "==>11923". Object class allSubclasses size "==>5959". Now in Pharo 6, the minimal image starts with a standard image and strips these things out... https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-3.2-Minimal/ws/output.t… In Pharo 7, there will be a new build system that it will start with a minimal image and build it up to a normal image. So this may provide a better way to understand the order that things need to be implemented. cheers -ben

Dec. 30, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Dimitris Chloupis

On a clean pharo 6 image file (alpha+vmLatest) Calypso installs fine but on my own built image it seems to conflict with Pillar triggering a syntax error [image: Screenshot 2016-12-30 18.08.38.png]

Dec. 30, 2016

Re: [Pharo-dev] [Ann] Calypso system browser

by Ben Coman

On Thu, Dec 29, 2016 at 1:40 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-12-28 18:12 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> * multiple code pane tabs - cool >> * multi-selection is cool (but I need to trial how it works out in >> practice) >> * automatic selection of items similar to last selection - I've been >> meaning to ask this for Nautilus for a while. >> * pinning modified pane code panes is a nice approach. It would be >> nice to pin any pane. >> * packages pane - it would be nice for the test-result-icon to appear >> on left like the other panes. The folder icon would seem reasonable >> place to substitute. >> >> Nice feature to show variables in the protocol pane and references in >> the method list pane. But it says "Class variables" while these are >> "Instance Variables" > > > Because Class variables are also accessible from instance side and you want > to see what methods are used it. > But I agree it should not be here by default. Actually it will be not here > if Object will not define any class variable. But Object has > DependantFields. Browser probably should ignore it. > Now structure of variables view is the same as when you click on Variables > button in Nautilus. > > So you think existence of "Class variables" is also confusing because it > looks like parent group for instance variables? Yes its confusing. I didn't even notice that "Class variables" could be expanded to show DependentsFields. I just assumed "Class variables" was the expanded parent of MultiByteBinaryOrTextStream, isBinary, converter. Hence my comment that "class variables" item should be renamed "instance variables". Now I see my comment was off target. I think the best fix is to have a parent "instance variables" as well as "class variables", and on the class side the parent should be "class instance variables." Such labels educate newbies. > >> >> >> Now I wonder if we can do without the Methods/Vars buttons by having >> the following top level tree items. Also as a newbie before developing >> the instinct to *know* which instance/class-side I was on, I got burnt >> a few times following tutorials accidentally putting methods on the >> wrong side. It would be interesting to try deprecating the >> Inst-Side/Class-Side buttons, and have something like the following >> items... >> + instance-side methods >> - accessing >> - initialization >> - extensions >> - GT-InspectorExtensions >> + class-side methods >> - instance creation >> - extensions >> + variables >> - instance variables >> - class variables >> - class instance variables >> > > It could be good or not. > Problem with this approach is same as why we use 4-column panes instead of > single tree menu for everything like other IDE does. > We don't want to scroll to achieve some group element. > Imaging that you browse some morph subclass which have a lot of protocols. > You are in some middle protocol and not see parent expanded group in list. > And now you want to look at class side or variables. Tree view will force > you to scroll instead of simple press on switch button like it is now. okay. It would still be useful to at least have "Instance methods" parent at the same level as "inherited methods" and "extensions" * its disconcerting to have the protocols floating without a parent * currently nowhere to select "All methods" - it seems you need to deselect to see all methods. So with * it could give another visual indication of which side you are on, by changing to "class methods" when the <Class side> button is pushed. > >> >> The "inherited methods" tree-item might be better as a pull down menu >> at the bottom of the pane, level with "Filter..." since visually it is >> confusing seeming that protocols like "accessing" are a sub-item of >> "inherited methods". > > > But it is not expanded and indentation of both items are same. > Also you can select "inherited methods" as any other group I didn't notice that. Fair enough. > and see all inherited methods together without using visibility checkbox. okay. I can see how that works. But I can't work out the display logic. Selecting... Collections-Streams > ReadWriteStream > inherited methods asBinaryOrTextStream(PositionableStream) is shown normal asZLibReadStream(PositionableStream) is shown grey Can you explain? cheers -ben

Dec. 30, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by phil＠highoctane.be

I've been remodeling my office for VR work (need to stop hitting into those desks and chairs). Next project is a WebVR set of brushes for AFrame https://aframe.io/ Porting my old web projects from Pharo3 to Pharo5 is taking more time than expected... Phil On Fri, Dec 30, 2016 at 4:48 PM, Ben Coman <btc(a)openinworld.com> wrote: > You are waiting for Santa on the 30 Dec? > Or am I just a little slow receiving these? > Anyway, merry xmas and hope the new year is good for you all. > cheers -ben > > On Fri, Dec 30, 2016 at 3:00 AM, Dimitris Chloupis > <kilon.alios(a)gmail.com> wrote: > > Shhhh .... we are waiting for Santa ;) > > On Thu, 29 Dec 2016 at 20:10, Dale Henrichs > > <dale.henrichs(a)gemtalksystems.com> wrote: > >> > >> The list server is up so it's just quiet:) > >> > >> > >> On 12/29/16 10:04 AM, Dale Henrichs wrote: > >> > No messages on list since yesterday morning? > >> > > >> > Dale > >> > > >> > >> > > > >

Dec. 30, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Dimitris Chloupis

Hey there "Email client The Terrible" how you doing ? :D On Fri, Dec 30, 2016 at 12:57 AM Igor Stasenko <siguctua(a)gmail.com> wrote: > who's there? :) > > > On 29 December 2016 at 21:31, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > I still love to get in trouble though I suck at getting up early , even > for Santa. Morfeas gives me busy :D > > On Thu, 29 Dec 2016 at 21:04, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > > > > > > > > > > > > I always got in trouble on Christmas ... getting up too early:) > > > > > > > > On 12/29/16 11:00 AM, Dimitris Chloupis > > wrote: > > > > > Shhhh .... we are waiting for Santa ;) > > > > > On Thu, 29 Dec 2016 at 20:10, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> > > wrote: > > > > > The list > > server is up so it's just quiet:) > > > > > > > > > On 12/29/16 10:04 AM, Dale Henrichs wrote: > > > > No messages on list since yesterday morning? > > > > > > > > Dale > > > > > > > > > > > > > > > > > > > > > > > Happy overquote! :) > > > -- > Best regards, > Igor Stasenko. >

Dec. 30, 2016

Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)

by Dimitris Chloupis

On Fri, Dec 30, 2016 at 5:49 PM Ben Coman <btc(a)openinworld.com> wrote: > You are waiting for Santa on the 30 Dec? > Or am I just a little slow receiving these? > Anyway, merry xmas and hope the new year is good for you all. > cheers -ben > > Yeah we organize every year an after party for Santa, after all this hard work running around getting stuck in chimneys he deserves it dont you think :)

Dec. 30, 2016