- Pharo-dev - lists.pharo.org

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

by Denis Kudriashov

2016-12-31 16:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > Also in Calypso protocol is not exists anymore. > > Okay. So btw will you have a new name for the third pane of the > browser to use in discussions? I call this pane method groups view (because it shows method groups)

Dec. 31, 2016

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

by Ben Coman

On Sat, Dec 31, 2016 at 6:55 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-12-30 17:04 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> > 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. > > > Personally I do not like it. > I not understand why "accessing" under "inherited methods" is looks like > child inside parent If I look more closely I notice that "accessing" is not indented from "inherited methods", so you are right that I should not be considering "accessing" as a child of "inherited methods". But just this is my first impression. And the same glitch happened regarding my perception of "Class variables" item. I'm not clear on the cause. Perception is a strange thing highly influenced by what you already know. Like those magic eye stereographic images [1] that at first you can't see, but then after the image appears, its hard to *not* see it. [1] http://www.vision3d.com/sghidden/saturn.html Maybe it is the checkbox doubling the size of the whitespace (??) such that it would be better placed to the right (??), or maybe I just need to adapt. > but "instance methods" under it will not confuse you too. By having "instance methods" at the top level with "accessing" will be indented from it, I think it would be more obvious rather than cause additional confusion. An alternative might be putting "inherited methods" next to "extensions" beneath the standard protocols > > Also in Calypso protocol is not exists anymore. Okay. So btw will you have a new name for the third pane of the browser to use in discussions? cheers -ben. > There is just specific kind > of method group which shows methods marked with given tag. > Group "extensions" is another kind of method group which shows class > extensions. > In future we will have much more groups from old nice project "dynamic > protocols" (there are github issues for them). > > So in general my idea that tagged method groups is not something special > comparing to any other method groups. Not need for special parent for them. > > (In Pharo7 we will try to move to tags idea and remove protocols and > class/method categories. New API for tags is already in Pharo 6 19341. > User will be able to mark method or class with set of tags. Each tag is just > symbol) >

Dec. 31, 2016

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

by Ben Coman

On Sat, Dec 31, 2016 at 6:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 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? > > > It's easy. Class extension is shown with grey and #asZLibReadStream is from > Compression package. > Actually this logic is a bit different. If method not belongs to selected > package (from package view) then it will be shown with grey. > It is current logic of Nautilus. Okay. That should have been obvious. So in trying to work out why my mind faltered, I think it may be because Nautlius provides visual feedback by light-highlighting the extension package (i.e. Compression) where Calypso does not - it only highlights real protocols. https://github.com/dionisiydk/Calypso/issues/38 cheers -ben

Dec. 31, 2016

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

by Stephane Ducasse

Phil let us know what are the problems because we are interested to help people and provide some tools (but I need phd for that). On Fri, Dec 30, 2016 at 5:02 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > 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. 31, 2016

Re: [Pharo-dev] uFFI chapter needs more love

by Stephane Ducasse

Thanks this is really important and I'm not good enough to do it. And I have three books on the burner. On Fri, Dec 30, 2016 at 1:54 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I am on it , I promised to Esteban that I would add to it the things I > learned with my shared memory bridge for C++ , obviously uFFI related. I > will probably contribute a lot to it because of my CPPBridge I will be > using UFFI almost on a daily basis so I am sure I will learn a lot and I am > more than happy to share the knowledge :) > > Give me a couple of months and UFFI doc will be in much better state ;) > > On Fri, Dec 30, 2016 at 2:44 PM Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi >> >> FFI is important and the FFI chapter is still draft. >> It would be good that some good souls help. >> >> https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/ >> UnifiedFFI >> >> Stef >> >

Dec. 31, 2016

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

by Stephane Ducasse

James, Nice to hear that you are still pushing. I would love to be able to developed in Pharo and deployed on red. Noury is working on the same scenario for PharoJS. May be we should organise a skype with Guille because we can use his infrastructure (hespel) to create out of Pharo automatically a kernel for Red. Guille has an infrastructure Hespel (check his phd) to - bootstrap different kernels such as Candlelight, microsqueak.. - tailor application (you give a seed expression and it collects all the mandatory methods and classes) probably like spoon He bootstrapped different small kernels during his phd. In tornado the tailoring version of Hespel we can create imae that are as small as 12k :) We put a list of the class in a techreport. https://hal.inria.fr/hal-00996908 In Pharo 70 we will use in production a bootstrap kernel: basically Pharo core with some better handled mechanisms (such as the startup) We should remove the traits from class/metaclasses to gain some space. Now our goal for this version is not to have the smallest core but a full process based on a bootstrap image. We shuffled/repackaged many classes around and we will continue to cut spurious dependencies. Stef On Sat, Dec 31, 2016 at 12:50 PM, James Ladd <ladd.james(a)gmail.com> wrote: > I'll check it out. > The version I remember was black n white. > > > Sent from my Commodore 64 > > > On 31 Dec 2016, at 9:04 pm, Stefan Marr <smalltalk(a)stefan-marr.de> > wrote: > > > > Hi James: > > > >> On 30 Dec 2016, at 22:50, James Ladd <ladd.james(a)gmail.com> wrote: > >> > >> I even tried to find the old Potatoe Smalltalk which was a port of an > old Smalltalk-80 image as it had a working ide and yet the smallest count > of classes. > > > > Did you find it? > > https://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/ > > > > Best regards > > Stefan > > > > > > -- > > Stefan Marr > > Johannes Kepler UniversitÃ¤t Linz > > http://stefan-marr.de/research/ > > > > > > > > > >

Dec. 31, 2016

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

by James Ladd

I'll check it out. The version I remember was black n white. Sent from my Commodore 64 > On 31 Dec 2016, at 9:04 pm, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > Hi James: > >> On 30 Dec 2016, at 22:50, James Ladd <ladd.james(a)gmail.com> wrote: >> >> I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes. > > Did you find it? > https://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/ > > Best regards > Stefan > > > -- > Stefan Marr > Johannes Kepler UniversitÃ¤t Linz > http://stefan-marr.de/research/ > > > >

Dec. 31, 2016

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

by Stefan Marr

Hi James: > On 30 Dec 2016, at 22:50, James Ladd <ladd.james(a)gmail.com> wrote: > > I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes. Did you find it? https://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/ Best regards Stefan -- Stefan Marr Johannes Kepler UniversitÃ¤t Linz http://stefan-marr.de/research/

Dec. 31, 2016

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

by philippe.back＠highoctane.be

Isn't there a typo in the first exptession? Also the list contains a lot of RB things. What purpose do they have in a bootstrap image? Same for RelationSlot and X11 something. Is there a scope and purpose statement for the bootstrap somewhere? Phil Le 31 dÃ©c. 2016 05:47, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > So for curiosity... > > $ $PHARO bootstrap.image eval "Object allSubclasses size" > 1677 > > $ $PHARO bootstrap.image eval "Object allSubclasses size" > 837 > > $ $PHARO bootstrap.image eval "Object class printHierarchy" > > /tmp/60334-bootstrap-hierarchy.txt > (see attached) > > cheers -ben > > > On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > 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-Bootstrap/lastSuccessfulBuild/artifact/bootstrap.zip > > > > -- 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. 31, 2016

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

by Ben Coman

So for curiosity... $ $PHARO bootstrap.image eval "Object allSubclasses size" 1677 $ $PHARO bootstrap.image eval "Object allSubclasses size" 837 $ $PHARO bootstrap.image eval "Object class printHierarchy" > /tmp/60334-bootstrap-hierarchy.txt (see attached) cheers -ben On Sat, Dec 31, 2016 at 4:42 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 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.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. 31, 2016