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

Re: [Pharo-dev] We did it! SlotClassBuilder is active

by Norbert Hartl

Congrats! That's really a huge step forward. Didn't expect that so soon! Norbert Am 03.07.2013 um 17:00 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > Today we turned on the SlotClassBuilderâ¦ this means actually quite a huge change, as it puts into place > lots of things that we can build on later. > > What it means for now > > -> A new, much easier to understand ClassBuilder > -> meta Objects. Layouts + Slots > > For example, there is now for every instance variable a meta object that describes it > It will be very interesting to see what we can do with that! > > Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo > for the work to get in really into 3.0. > > Marcus

July 3, 2013

Re: [Pharo-dev] Problem with Zinc and HTTPS

by Mariano Martinez Peck

Hi Sven. Thanks for the help. Together with your tests and a few others I finally found my problem. In this case, I was trying to access the Shub repo from a VirtualBox image. The Shub is hosted by ANOTHER VBox image but both are in the same HOST machine. Since the URL of the shub repo contains the external IP (because is the same URL written in the ConfigurationOf etc), this is understood by the router as loopback. From what I understand, most router disable or directly do not allow loopback because of security....so that was the problem. Thanks for the help! On Tue, Jul 2, 2013 at 5:09 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 02 Jul 2013, at 01:16, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > Sorry, I express myself wrong. Indeed, from the server side (the image > running shub), I do not use Zodiac at all. But in another image (where I am > having the problem), if I try to connect to the Monticello repository > (served by HTTPS by nginx in the other server) I do have the problem and in > this case I am trying to communicate via HTTPS from Pharo. Wouldn't be > using Zodiac here? > > Ah, I misunderstood. > > Yes, to access an HTTPS based repository, you need Zodiac. > If all Zn+Zdc tests are green, that means you are good. > > I see that you get a ConnectionTimedOut error while connecting, that's > like the very first step ;-) > > What I would do is: make sure you can access your HTTPS repo in other > ways, using a regular browser and/or curl. You know, MC repo serving is > just plain HTTP(S) with basic authentication: you should be able to list a > repo or download a version using any other means. > > If that works, try to do the same using ZnClient, like this: > > ZnClient new > username: 'marianopech' password: 'secret'; > get: ' > http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/Ston-Core-Sven… > '. > > Good luck ! > > Sven > > PS: I also see you are using a numeric IP address, not a DNS name. That > won't work with virtual hosts AFAIK. > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > > -- Mariano http://marianopeck.wordpress.com

July 3, 2013

We did it! SlotClassBuilder is active

by Marcus Denker

Hi, Today we turned on the SlotClassBuilderâ¦ this means actually quite a huge change, as it puts into place lots of things that we can build on later. What it means for now -> A new, much easier to understand ClassBuilder -> meta Objects. Layouts + Slots For example, there is now for every instance variable a meta object that describes it It will be very interesting to see what we can do with that! Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo for the work to get in really into 3.0. Marcus

July 3, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,mac #257

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=mac…>

July 3, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,win #257

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=win…>

July 3, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… 1 regressions found. FileSystem.Tests.Disk.FileHandleTest.testTruncate

July 3, 2013

[update 3.0] #30249

by Marcus Denker

30249 ----- 11047 Integrate new class builder step 2 https://pharo.fogbugz.com/f/cases/11047 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.8… http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.37.diff

July 3, 2013

[update 2.0] #20610

by Marcus Denker

20610 ----- 11101 fileOutMethod:on: uncategorized in 2.0 https://pharo.fogbugz.com/f/cases/11101 â¦ and using an image with all strange processes killed.

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Goubier Thierry

Le 03/07/2013 14:25, Igor Stasenko a Ã©crit : > On 3 July 2013 14:19, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 03/07/2013 11:59, Igor Stasenko a Ã©crit : >> >>> On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> Is there something against that ? >>>> >>>> It seems as if NB is used to check file existence / isReadable, then, >>>> upon >>>> startup, the vm is unable to open the changes file and all NB calls >>>> becomes >>>> incorrect. >>>> >>> >>> NB callout needs argument names (which it can only get right now by >>> accessing method's source). >>> We plan to change that after introducing pluggable mechanism in opal >>> to use it to run additional >>> code on certain pragma to handle it in custom way (like remembering >>> argument names in method's properties). >> >> >> If it is like that, I have to give up any chance of correcting the file >> permissions problem on Pharo 2.0. >> >> Any chance that we could use arguments positions instead ? >> > I don't know.. look: > > realloc: flags mem: lpMem size: dwBytes > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> > > > ^ self nbCall: > #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) > > here, see: flags, lpMem, dwBytes names is in function signature same > as in your method. > That's how NB knows which argument from method corresponds to argument > passed to function. > > now if you don't use argument names , how the above should look like? > > realloc: flags mem: lpMem size: dwBytes > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> > > ^ self nbCall: > #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) > ? > > potentially , you can change the signature parser to accept such syntax.. > but as to me, that's really ugly, counter intuitive and error prone. I'm doing that at the moment because it sounds inacceptable in 2.0 to have the following true: No use of NativeBoost if you start the VM without sources and changes. Just wait until someone deploys 2.0 in production without the sources and is unable to load environment variables... (for my own use, I'll hack either OSProcess to extend FileSystem and get correct file permissions, the ChangeFile opening to force it even if NB isn't working, or NB itself. But I don't have yet a need to deploy without the sources). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 3, 2013

Re: [Pharo-dev] NativeBoost with no access to sources

by Igor Stasenko

On 3 July 2013 14:19, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 03/07/2013 11:59, Igor Stasenko a Ã©crit : > >> On 3 July 2013 11:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>> Is there something against that ? >>> >>> It seems as if NB is used to check file existence / isReadable, then, >>> upon >>> startup, the vm is unable to open the changes file and all NB calls >>> becomes >>> incorrect. >>> >> >> NB callout needs argument names (which it can only get right now by >> accessing method's source). >> We plan to change that after introducing pluggable mechanism in opal >> to use it to run additional >> code on certain pragma to handle it in custom way (like remembering >> argument names in method's properties). > > > If it is like that, I have to give up any chance of correcting the file > permissions problem on Pharo 2.0. > > Any chance that we could use arguments positions instead ? > I don't know.. look: realloc: flags mem: lpMem size: dwBytes <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) here, see: flags, lpMem, dwBytes names is in function signature same as in your method. That's how NB knows which argument from method corresponds to argument passed to function. now if you don't use argument names , how the above should look like? realloc: flags mem: lpMem size: dwBytes <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) ? potentially , you can change the signature parser to accept such syntax.. but as to me, that's really ugly, counter intuitive and error prone. -- Best regards, Igor Stasenko.

July 3, 2013