July 2013 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [Moose-dev] SourceCity works

by Erwan Douaille

Hi (few days later) 2013/7/4 Alexandre Bergel <alexandre.bergel(a)me.com> > Hi Erwan and all, > Just to make a few things clear about Roassal 3d vs SourceCity. > > There is no vs, i just wanted to know the goal and which difference there is between them. Now let's see how it will grow up, with new 3D stuff ;) We are currently working on Roassal 3d, which intends to be a nice layer at > the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, > lights, camera, interactions, zooming, translucent coloring, > clicking/rotating/translating individual elements and so on. Everything > that is good for Roassal is equally good for 3D Scene. > Having a city-like visualization will be one of our first objectives since > (i) it is a compelling use of 3D and (ii) it is easy to implement (at least > the bases). We started to work on a CityBuilder, to easily create cities > from objects and provided metrics. Ideally, it would be great to have > SourceCity based on our effort. Not now since we have just started Roassal > 3D, but on some point we should merge (this is similar in the 2d World with > Mondrian and EyeSee moving from plain Morphic to Roassal). > > Our objective is to offer a great 3d framework to make a truly flying > SourceCity. > Does this make sense to you? > > Cheers, > Alexandre > > > > On Jul 4, 2013, at 10:47 AM, Erwan Douaille <douailleerwan(a)gmail.com> > wrote: > > > https://ci.inria.fr/pharo-contribution/job/SourceCity/ > > > > done > > > > > > 2013/7/4 Camillo Bruni <camillobruni(a)gmail.com> > > > > On 2013-07-04, at 15:35, Erwan Douaille <douailleerwan(a)gmail.com> wrote: > > > > > I updated the ConfigurationOfSourceCity. > > > > > > Gofer new > > > smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; > > > configuration; > > > load. > > > ConfigurationOfSourceCity loadBleedingEdge > > > > would it make sense to make a jenkins job for this? > > > > > > > > > > -- > > Best regards, > > > > Douaille Erwan <douaille.erwan(a)gmail.com> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

July 9, 2013

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

by Camillo Bruni

cool! I hope I have more energy tomorrow so I can look into it and put on fix to include :) On 2013-07-08, at 22:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > This is cool. > I like first class objects! > Thanks Max. > > >> 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 8, 2013

Re: [Pharo-dev] pharo jenkins down

by Camillo Bruni

On 2013-07-08, at 22:15, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> http://ci.inria.fr/pharo is currently down... > > Seems to be up now... even better, then it just took forever and back to upgrade :P

July 8, 2013

Re: [Pharo-dev] [ANN] Pharo VM now building on Pharo 2.0

by phil＠highoctane.be

I'll have to try that. How to run an interpreter in there? Is it possible? Phil On Mon, Jul 8, 2013 at 9:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > Today I migrated the jenkins jobs for building the PharoVM to 2.0. > Objectively, nothing changes for the VM users, but is important to move > the infrastructure according to our yearly releases. > For those who are creating their own VMs and stuff, now you can move to > 2.0 too, there is no need to keep using 1.4. > > jenkins builds are, as always, at: > https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > (windows build is broken due a know problem in the windows slave, not > related with the VM build itself) > > Thanks Guille for doing the work and Camillo for the support :) > > Esteban >

July 8, 2013