- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Odd FFI problms with Mac vms...

by Dale Henrichs

On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote: > > On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote: > >> Norbert, >> >> Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. >> >> Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). >> >> The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. >> >> Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. >> >> Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... >> >> Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... >> >> Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... >> >> If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... > > Here's the FFI call: > > apiGciFetchObjImpl: anOopType > > <apicall: ulong 'GciFetchObjImpl' (OopType64) > > ^self externalCallFailed > > and OopType64 is a subclass of ExternalStructure with the following fields declaration: > > fields > " > (OopType64 defineFields) > " > > ^#(asOop 'ulonglong'). > > and the function declaration from the header file: > > int GciFetchObjImpl(OopType theObject); I thought it might be suspicious that a SmallInteger was being passed in when the argument type should have been OopType, so in the Cog vm, I traced the source of the argument back to the _result_ another FFI call: <apicall: OopType64 'GciNbPerform' (OopType64 char* ulong long) > The result is declared as OopType64 so it looks like the result was not converted to the correct type on return...which ends up with the incorrect argument coming in .. When the Squeak 4.2.5beta1U runs through the same sequence of calls, the result of GciNbPerform gets correctly converted to OopType64, so that seems to be the ulitmate source of the error ... Not sure whether this is a VM issue or an FFI issue, in either case I assume that the bug exists in some C code floating around somewhere.. Dale

April 3, 2011

Re: [Pharo-project] Odd FFI problms with Mac vms...

by Dale Henrichs

On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote: > Norbert, > > Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. > > Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). > > The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. > > Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. > > Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... > > Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... > > Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... > > If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... Here's the FFI call: apiGciFetchObjImpl: anOopType <apicall: ulong 'GciFetchObjImpl' (OopType64) > ^self externalCallFailed and OopType64 is a subclass of ExternalStructure with the following fields declaration: fields " (OopType64 defineFields) " ^#(asOop 'ulonglong'). and the function declaration from the header file: int GciFetchObjImpl(OopType theObject); Dale

April 3, 2011

[Pharo-project] Odd FFI problms with Mac vms...

by Dale Henrichs

Norbert, Today I have found that I can get GemTools to work on the mac using Squeak 4.2.4beta1U. Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a Space is low error, because the size comes back as 1330942246849085449, instead of a reasonable number). The image is identical and the gci library file is identical in both cases, I've just switched the vm that I'm using. Squeak 5.7.4.1 gives an 'unsupported calling convention' with the first FFI call into the library. Cog-VM.r2378 gives a 'Could not coerce arguments' error for the FFI call that returns the unreasonable number in 4.2.5beta1U...the argument to the function is a SmallInteger (343552513) ... at least this error gives me hope that I can figure out what's wrong with this call sooner or later ... Anyway, the upshot is that Squeak 4.2.4beta1U is the best bet at the moment on the Mac for running GemTools ... Oh, the image was a PharoCore-1.1.1...Finding _a_ Mac vm, that works gives me an incentive to try getting GemTools running on PharoCore.1.2... If any of the vm or FFI guys have some insight to these problems I'd appreciate some pointers to what may be going on... Dale On Mar 30, 2011, at 10:09 AM, Norbert Hartl wrote: > > Am 30.03.2011 um 19:02 schrieb Johan Brichau: > >> well... it only works with a VM up to version 4.2.2 >> > well, right! Something I forgot to tell. That is the reason I start it from the command line :) > > Norbert > >> everything beyond that ended up in a strange login error, indeed >> >> On 30 Mar 2011, at 18:19, Dale Henrichs wrote: >> >>> Yes I am suspicious that there are some os library mismatches involved as I get an odd error during the login sequence and I haven't successfully characterized the specific problem... >>> >>> I am glad to hear that some folks are not having trouble ... which only deepens the mystery:) >>> >>> Dale >> >> > >

April 3, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by HernÃ¡n Morales Durand

I really agree with you Marcus. It sounds to me that core/dev is a black and white approach. I know there are no resources, but what do you think of starting with a minimum image and the build over more sophisticated images? -Kernel image -Core image -Image with really basic browsing/scm tools (OB, Script Manager, Shout, etc) - or "developer basic" -developer standard (the current dev) -developer scientific -developer web ... etc. that wouldn't result in more easier integrations? Cheers, 2011/4/3 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. > > 1) We don't develop the system using the tools that we tell people to use. > Â Â Â Â Â Â Â Â -> bugs don't get fixed > Â Â Â Â Â Â Â Â -> there is no pressure on improving the tools > Â Â Â Â Â Â Â Â -> we can't use the advanced tools while developing the Core. > > 2) We integrate *far* too late. > Â Â Â Â Â Â Â Â -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. > > 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. > Â Â Â Â Â Â Â Â -> People even expect to be able to shrink it more, which in turn we do not test. > > 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... > Â Â getting them fixed for the release if they are not touched for a year is nearly impossible. > > 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. > Â Â e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. > > 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. > > The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly > not working. > > So I vote for abandoning Core vs. Dev for 1.3. > > Â Â Â Â Marcus > > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

April 3, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by StÃ©phane Ducasse

On Apr 3, 2011, at 7:31 PM, Marcus Denker wrote: > Hi, > > So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. > > 1) We don't develop the system using the tools that we tell people to use. > -> bugs don't get fixed > -> there is no pressure on improving the tools > -> we can't use the advanced tools while developing the Core. Yes > 2) We integrate *far* too late. > -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. yes but this is not our fault > 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. > -> People even expect to be able to shrink it more, which in turn we do not test. > > 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... > getting them fixed for the release if they are not touched for a year is nearly impossible. > > 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. > e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. But marcus you should also read the metacello chapter. Did you read it? > 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. > > The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly > not working. > > So I vote for abandoning Core vs. Dev for 1.3. Yes but we need good tool. Stef

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

> > - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Yes but for that we need a good browser that we can maintain. > Yes, 2 images seems hard to maintain and hard to understand for newcomers. > > May be we can have: > - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests > - drop actual Pharo, rename PharoCore => Pharo. > - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help This is the idea. This is why I asked people (mariano in particular) to focus on helping metacello taking off the ground and to focus on metacello distributions. Once this is up and running. we can have Pharo and hudson loads and certifies the distributions. Stef

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

>> >> >> as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. >> > Yes, that is why I did not want to decouple the release of Core from Full. Because is drags out the release so far that we can not announce it > > But we could not, as people (inkluding those maintaining packages of Full) only look at released core images... > And so I did a Core 1.2. And people looked at it. Finally. So I did a 1.2.1, and only after releasing that, people looked at it, This is not your fault. > so I even started > a 1.2.2 today.. and now I am dead. Let 1.2.2 for in a couple of months. >> I'm thinking about: >> - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. >> - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) >> - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears >> - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). >> > > - Get rid of the Core/Full image destinction. This does not work. And I will not do a release with having two images again... it never worked, and it will never work. Yes we are working on that. The missing pieces of the puzzle are coming along. Stef

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by StÃ©phane Ducasse

On Apr 3, 2011, at 7:12 PM, laurent laffont wrote: > Hi, > > as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't seen 1.2.0, no big party, no 1 million download contest, BBC announcement... :) I wonder how we can improve the process for 1.3. > > I'm thinking about: > - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo 1.3. we will not start 1.4 before 1.3 is at least one month in beta. > - freezing early to have shorter release and have less stuff to fix with maximum energy (it seems energy go down quickly in the fixing period) this is what we did. We got now 3 months of beta and result: nobody look at it > - a failing test should be highest priority: it's easier to fix a broken feature/test as soon as it appears yes but if nobody look at them, does it make a difference? > - one guy should drive the release (I feel that Mariano did this for Pharo 1.1 and we know who we should talk to). marcus did that and this is not the problem. > > Any idea ? We should no have pharo-dev just pharo-core + RB + oCompletion + shout in the core. > > Laurent.

April 3, 2011

Re: [Pharo-project] Let's get rid of Core vs. Full

by Dale Henrichs

Rather than abandon core vs full, here's a thought on a slightly different approach... Do development in the FULL version. That way the tools are used and bugs in the tools are fixed as the changes are made in the CORE...you are keeping the FULL alive, not adding new features, etc, since that kind of work is the responsibility of the maintainers ... Use the build server to run tests against the CORE and the set of CORE tools... You'll be dragging along more code as you do new development on the CORE, but at least the work of keeping the FULL version in synch will be spread across the whole CORE development cycle rather than concentrated at the end ... Just some ideas:) Dale On Apr 3, 2011, at 10:31 AM, Marcus Denker wrote: > Hi, > > So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. > > 1) We don't develop the system using the tools that we tell people to use. > -> bugs don't get fixed > -> there is no pressure on improving the tools > -> we can't use the advanced tools while developing the Core. > > 2) We integrate *far* too late. > -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. > > 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. > -> People even expect to be able to shrink it more, which in turn we do not test. > > 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... > getting them fixed for the release if they are not touched for a year is nearly impossible. > > 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. > e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. > > 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. > > The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly > not working. > > So I vote for abandoning Core vs. Dev for 1.3. > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 3, 2011

Re: [Pharo-project] Pharo 1.3 process

by laurent laffont

On Sun, Apr 3, 2011 at 7:18 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 3, 2011, at 7:13 PM, laurent laffont wrote: > > Hi, > > as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't > seen 1.2.0, no big party, no 1 million download contest, BBC announcement... > :) I wonder how we can improve the process for 1.3. > > Yes, that is why I did not want to decouple the release of Core from Full. > Because is drags out the release so far that we can not announce it > > But we could not, as people (inkluding those maintaining packages of Full) > only look at released core images... > And so I did a Core 1.2. And people looked at it. Finally. So I did a > 1.2.1, and only after releasing that, people looked at it, so I even started > a 1.2.2 today.. and now I am dead. > Time for a big real good fresh beer ;) I'm thinking about: > - not starting Pharo 1.4 too soon as I feel it will steal energy from Pharo > 1.3. > - freezing early to have shorter release and have less stuff to fix with > maximum energy (it seems energy go down quickly in the fixing period) > - a failing test should be highest priority: it's easier to fix a broken > feature/test as soon as it appears > - one guy should drive the release (I feel that Mariano did this for Pharo > 1.1 and we know who we should talk to). > > > - Get rid of the Core/Full image destinction. This does not work. And I > will not do a release with having two images again... it never worked, and > it will never work. > Yes, 2 images seems hard to maintain and hard to understand for newcomers. May be we can have: - Metacello configurations tested separately in Pharo-Clients in Hudson (like PetitParser, Seaside, ...) - drop the ones that don't have tests - drop actual Pharo, rename PharoCore => Pharo. - GUI tool in Pharo to easy load Metacello configurations (some stuff must be easy to load for newbies, especially help) Laurent. Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 3, 2011