- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher

by Sebastian Tleye

Great, for me, that i am touching kernel classes, it will be very useful have something to manage images quickly!! 2013/7/8 Tudor Girba <tudor(a)tudorgirba.com> > Hi Damien, > > Nice :). > > I noticed two issues when playing with it: > - there is no feedback while downloading the image. This can be confusing. > - the launcher quits when launching another image (I am on Mac). This is > actually interesting, but it was surprising. I am not sure what is the > right solution here. > > And a question: How can we get more images available through this > interface? > > Cheers, > Doru > > > On Jul 8, 2013, at 10:11 AM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: > > > Dear list, > > > > Erwan and I are proud to announce the first release of the Pharo > > Launcher, a cross-platform application that > > > > - lets you manage your Pharo images (launch, rename, copy and delete); > > - lets you download image templates (i.e., zip archives) from many > > different sources (Jenkins, files.pharo.org, and your local cache); > > - lets you create new images from any template. > > > > A screenshot is attached to this email. > > > > The idea behind the Pharo Launcher is that you should be able to > > access it very rapidly from your OS application launcher. As a result, > > launching any image is never more than 3 clicks away. > > > > Download: > https://ci.inria.fr/pharo-contribution/job/PharoLauncher/PHARO=30,VERSION=b… > > > > Please report bugs on the 'Launcher' project at > https://pharo.fogbugz.org > > > > You can contribute to this project. All classes and most methods are > > commented. There are unit tests. Please contribute! > > > > Source code: http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > > CI: https://ci.inria.fr/pharo-contribution/job/PharoLauncher > > > > Things you can do to improve the system: > > > > - check if a template is already downloaded before downloading it > > - add a preference mechanism (for, e.g., quit after launch, definition > > of your own template groups, location of downloaded templates and > > images) > > - put the launcher in the Pharo Ubuntu package so that the launcher > > becomes a registered appliation of the system > > (https://launchpad.net/~pharo/+archive/stable) > > - make sure the pharo launcher does not load your personal scripts > > (like fonts and MC configuration) > > - add a toolbar to enhance the discoverability of the features > > (currently everything is in contextual menus) > > - make sure rename and copy actions propose default values > > - make sure no debugger pops up when a user press cancels or enter an > > invalid name > > - propose multiple kinds of sorting (last used, most frequently used, > > alphabetically on the name) > > - give some information about each template (build date, pharo version) > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." > > Winston Churchill > > <screenshot.png> > > -- > www.tudorgirba.com > > "To utilize feedback, you first have to acquire it." > > >

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Stefan Marr

Hi ClÃ©ment: On 09 Jul 2013, at 11:19, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Sounds cool, nice idea. What VM did you extend ? Vanilla, Stack ? If i remember correctly you implemented Roar VM so maybe you extended this one ? It is an extension to the RoarVM, but for all intents and purposes I use it like a classic interpreter. Thus, no context-to-stack mapping is used. Probably not very useful without all the context, but the relevant code looks often like this: https://github.com/smarr/OmniVM/blob/master/vm/src/interpreter/squeak_inter… Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by ClÃ©ment Bera

2013/7/9 Stefan Marr <smalltalk(a)stefan-marr.de> > Hi ClÃ©ment: > > On 09 Jul 2013, at 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Now I'd like to know what context's state do we modify, and what states > are just internal representations ? > > I extended my VM with additional information that is kept in the context. > My contexts can be 'owned' by a certain metaobject, and they indicate with > a boolean whether the execution should regard that metaobject or not, for > instance to delegate certain operations to it. > Sounds cool, nice idea. What VM did you extend ? Vanilla, Stack ? If i remember correctly you implemented Roar VM so maybe you extended this one ? > > So, that's all not exactly 'Pharo' but, I wanted to point out that there > are use cases where additional fields and mutability of those is desirable. > Yeah this feature is nice. And an efficient implementation should be doable. Thanks for your answer. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > >

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by ClÃ©ment Bera

2013/7/9 Igor Stasenko <siguctua(a)gmail.com> > > To my thinking playing with pc is awfully evil, it should be > read-only, only to allow debugger > to map it to source code. Same goes for stack pointer. > For stack pointer I don't know use cases so I have to agree. Now for pc in a smalltalk debugger you can select a place in code and execute 'run to here without executing code'. It is hidden in Pharo (right menu on stack) but it is a button in Visual works. So even if evil, it is required for some functionalities. I don't know if it could be deleted like that. > > Setting receiver is less evil and it may work, if receiver belongs to > same inheritance chain > as compiled method's class. But it should not be set without checking this. > Setting receiver fails in Cog and no one complains so .. > > And for method's temps, it is fine. > > > Thanks for answering, > > > > -- > Best regards, > Igor Stasenko. > >

July 9, 2013

Re: [Pharo-dev] NativeBoost and lacking string argument/return handling

by Igor Stasenko

On 5 July 2013 18:17, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Was leaving work in a hurry there, think I forgot a not and some smileys in the last post ;) > Anyways, in combination with an encoding opt, a nice addition (for those functions expecting size of string as separate parameter) would be being able to specify strLength(myString) as the size parameter, and have it computed after conversion, otherwise you still have to do it all in an image-side wrapper to get the correct number... > > 2 weeks vacation upcoming, I guess I got plans if the weather is bad ;) > i hope so (so you can contribute to NB ;))) > Cheers, > Henry -- Best regards, Igor Stasenko.

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Stefan Marr

Hi ClÃ©ment: On 09 Jul 2013, at 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Now I'd like to know what context's state do we modify, and what states are just internal representations ? I extended my VM with additional information that is kept in the context. My contexts can be 'owned' by a certain metaobject, and they indicate with a boolean whether the execution should regard that metaobject or not, for instance to delegate certain operations to it. So, that's all not exactly 'Pharo' but, I wanted to point out that there are use cases where additional fields and mutability of those is desirable. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Igor Stasenko

On 9 July 2013 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello pharoers, > > Recently I have been looking at the Pharo thisContext capabilities, in order > to perhaps one day in the far future edit its implementation with the Pharo > dev team. Nothing is planned or confirmed, it is just to discuss. > > A context has instances variables (method closureOrNil receiver stackp > sender pc) and holds the arguments and temporaries. > > Now I'd like to know what context's state do we modify, and what states are > just internal representations ? > > For example, it seems that you can do 'thisContext receiver: #foo', but you > cannot with Cog. > > SomeClass>>foo > thisContext receiver: #foo. > ^ self > > In workspace, evaluating: > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] > > Transcript result (with Cog): > foo > foo > a SomeClass > a SomeClass > a SomeClass > > Transcript result (with Stack or Vanilla): > foo > foo > foo > foo > foo > > Now as no one has ever complained, I guess this feature is not used. > > As far as I know, the real use cases of the context seems to be: > - setting and gettings temporaries > - setting and getting the sender of a context > - setting and getting the pc > - getting method, closureOrNil, receiver, stackp, arguments but NOT setting > them > > Now setting the sender of a context seems to be used only in two cases: > - continuations (as seaside continuations) > - exception implementation > > So imagine that in the future you would have a context that can be accessed > in read-only, where you could only: > - set the temporaries (but not arguments) > - set the pc (or something equivalent, as set the currently executed ast > node) > - use continuations (exceptions can be implemented on top of continuations) > > I would like to know if there are things that you do now and that you would > not be able to do with a context like that. For non meta developer (like > enterprise app developer) I guess it will not change anything, but I want to > know if you implemented a framework as seaside, does it requires other > things from the context and why ? > To my thinking playing with pc is awfully evil, it should be read-only, only to allow debugger to map it to source code. Same goes for stack pointer. Setting receiver is less evil and it may work, if receiver belongs to same inheritance chain as compiled method's class. But it should not be set without checking this. And for method's temps, it is fine. > Thanks for answering, -- Best regards, Igor Stasenko.

July 9, 2013

thisContext usecases

by ClÃ©ment Bera

Hello pharoers, Recently I have been looking at the Pharo thisContext capabilities, in order to perhaps one day in the far future edit its implementation with the Pharo dev team. Nothing is planned or confirmed, it is just to discuss. A context has instances variables (method closureOrNil receiver stackp sender pc) and holds the arguments and temporaries. Now I'd like to know what context's state do we modify, and what states are just internal representations ? For example, it seems that you can do 'thisContext receiver: #foo', but you cannot with Cog. SomeClass>>foo thisContext receiver: #foo. ^ self In workspace, evaluating: 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] Transcript result (with Cog): foo foo a SomeClass a SomeClass a SomeClass Transcript result (with Stack or Vanilla): foo foo foo foo foo Now as no one has ever complained, I guess this feature is not used. As far as I know, the real use cases of the context seems to be: - setting and gettings temporaries - setting and getting the sender of a context - setting and getting the pc - getting method, closureOrNil, receiver, stackp, arguments but NOT setting them Now setting the sender of a context seems to be used only in two cases: - continuations (as seaside continuations) - exception implementation So imagine that in the future you would have a context that can be accessed in read-only, where you could only: - set the temporaries (but not arguments) - set the pc (or something equivalent, as set the currently executed ast node) - use continuations (exceptions can be implemented on top of continuations) I would like to know if there are things that you do now and that you would not be able to do with a context like that. For non meta developer (like enterprise app developer) I guess it will not change anything, but I want to know if you implemented a framework as seaside, does it requires other things from the context and why ? Thanks for answering,

July 9, 2013

Re: [Pharo-dev] Issue-5468: Extract CRC code -> NativeBoost?

by Max Leske

On 09.07.2013, at 09:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Max I added you to the Pharo team. Great, thanks. > So now you should be able to commit to the inbox (soon it should be fixed). > Then I tried to merge (I read the beginning ogf the article and this is a nice article) but > I could not because Fuel-marcus766 is not found. May be my image is not recent enough. Fuel-MarcusDenker.766 is the default Fuel version in the latest 3.0 (curl get.pharo.org/30 | bash). I did all my work in there. > I should probably add a repository but I could not find it. > > >> As promised (a very long while ago) I moved all the checksum code to a dedicated hiearchy (see https://pharo.fogbugz.com/default.asp?5468) The thing I'm most proud of is the CRC class which implements Ross Williams's "RockSoft" parameterized CRC caculation model (http://www.ross.net/crc/) >> >> Currently there are still two plugin primitives (used by the Compression package) which I simply moved to the new Checksum hierarchy. When I originally wrote the CRC class I wasn't aware of NativeBoost. Today I saw that there are two methods NativeBoost offers for crc32 calculations. I don't have time to look in to that but I just wanted to put the idea out there that with the checksum code now all in one place, we might be able to perform all checksum calculations through NB (and get rid of the ZipPlugin :) ). >> >> Any thoughts? >> >> Cheers, >> Max > >

July 9, 2013

Re: [Pharo-dev] Issue-5468: Extract CRC code -> NativeBoost?

by StÃ©phane Ducasse

Max I added you to the Pharo team. So now you should be able to commit to the inbox (soon it should be fixed). Then I tried to merge (I read the beginning ogf the article and this is a nice article) but I could not because Fuel-marcus766 is not found. May be my image is not recent enough. I should probably add a repository but I could not find it. > As promised (a very long while ago) I moved all the checksum code to a dedicated hiearchy (see https://pharo.fogbugz.com/default.asp?5468) The thing I'm most proud of is the CRC class which implements Ross Williams's "RockSoft" parameterized CRC caculation model (http://www.ross.net/crc/) > > Currently there are still two plugin primitives (used by the Compression package) which I simply moved to the new Checksum hierarchy. When I originally wrote the CRC class I wasn't aware of NativeBoost. Today I saw that there are two methods NativeBoost offers for crc32 calculations. I don't have time to look in to that but I just wanted to put the idea out there that with the checksum code now all in one place, we might be able to perform all checksum calculations through NB (and get rid of the ZipPlugin :) ). > > Any thoughts? > > Cheers, > Max

July 9, 2013