- Pharo-dev - lists.pharo.org

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

by Mariano Martinez Peck

I've added http://code.google.com/p/cog/issues/detail?id=23 On Mon, Apr 4, 2011 at 4:38 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Dale, > > this is a known issue spotted and fixed by Ken Treis. I've been tardy > in integrating the fix. I'll try and do that in the next couple of days. A > test case would help (Ken, Dale?). > > If you want to try Ken's fix in advance then see > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/044521.html > > Apologies, > Eliot > > > On Sun, Apr 3, 2011 at 1:04 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> >> 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 >> >> >> > -- http://marianopeck.wordpress.com

April 4, 2011

Re: [Pharo-project] [ANN 1.2] 1.2.1 Full Release Image

by Igor Stasenko

On 3 April 2011 10:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 3, 2011, at 10:22 AM, Lukas Renggli wrote: > >> A pity that broken OB code is used, nevertheless it is quite usable. >> > > Yes, and I added a bug report on March 22: > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=3842 > > But nobody cared to react. So how important can it be? > :) One good feature i found on drupal site, that its automatically closing the issues if there is no activity after two weeks. Closed with label "unresolved" or "unattended" .. but the idea is that if nobody cared to fix it, then its not so important.. and there's always a way to reopen an issue later. > There are two possibilities: > > Â Â Â Â -> Postponing the release because it's not perfect. > Â Â Â Â Â Â (We are doing this for *3 Months* already) > > Â Â Â Â -> Not release and wait another 3 Months. > > > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

Re: [Pharo-project] Pharo sprint at Brussels Friday 15th of April

by Sven Van Caekenberghe

On 02 Apr 2011, at 09:31, StÃ©phane Ducasse wrote: > Johan Brichau and Andy Kellens are organizing a sprint at VUB. > Please let us know who will join. > I will join That's an offer I can't refuse: so yes, I'll be joining too. What are the details, timeframe & place ? Sven

April 4, 2011

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

by Igor Stasenko

On 3 April 2011 19:31, Marcus Denker <marcus.denker(a)inria.fr> 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, i think that full or 'dev' images just need to have a configurations which people could load on top of core image. The responsibility of core team is to define what is included in those configurations on next release and making sure that they can be loaded in latest core images. But don't mix 'can be loaded' with 'works without bugs' :) This is another story. This is where community has to be involved and people who interested in using full image(s) need to help with it. Otherwise, if nobody using it, then why wasting an effort with maintaining and fixing such a large codebase? I know it by myself, that bugs are discovered and fixed only when you using some tool(s). But if something lies there unattended, then it will definitely break at some point, and it is not really matters how hard you try to keep backwards compatibility or making sure all tests are green. > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig.

April 4, 2011

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

by HernÃ¡n Morales Durand

2011/4/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Apr 3, 2011, at 9:34 PM, HernÃ¡n Morales Durand wrote: > >> 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? > > I'm not sure that you want a lot of different setups because it means checking problems due to interactions. > So far we cannot maintain 2 so I do not see why more would help. > Â Â Â Â a core + packages + a dsitribution browser to load certified distributions > > > we want a mini-core + a set of maintained pharo packages + a configuration files > > When we work on them > Â Â Â Â -> new mini core + Â automatic publication of new packages + new configuration files > Ok I see. Let me comment some background: In the past I've worked in a team of 4 developers doing a custom ANSI private smalltalk, programming smalltalk code in notepad without cvs or any kind of SCM during almost 1 year, and I know what is having no tools at all. We had just a very well organized swiki, a methodology for communication... and an extremely ugly set of XML files for enabling "packages". We had weekly package releases. The core image was regularly released each month. Not a super mega project, but it worked for our client. Anyone wanting details of how please don't hestitate to ask me privately. I still have the documentation and source code. I'd prefer just a good mini-core or core release regularly than n setups, so my vote is for abandoning regular Dev releases, which to me are "newbie" releases, not meaning to offend anyone here, I know most readers know how to do their own dev releases (for example I have 2 pharo core images one for developing FFI and primitives and another one for scientific development). Believe me, I work everyday in Pharo and I've abandoned the Dev image, too many hangs when working heavily (I **really** tried the dev image), I can post the experiment scripts, although many times there were unhandled exceptions when just browsing code. If I had a team I'd report every issue. > Right now this process does not work so this is a ***pain*** I spent 2 hours > one sunday to fix some stupid problem with shout in OB just because we do not have > good tools on top of metacello and because loading packages is slow. > I'd like you enjoy releasing Pharo, I'm now enjoying comparing Smalltalk with Perl, Python and Java :) > Stef > -- 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 4, 2011

[Pharo-project] [COTDC] 41 - ExclusiveWeakMessageSend

by laurent laffont

Today: ExclusiveWeakMessageSend Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

April 4, 2011

Re: [Pharo-project] [COTDC] 40 - PasswordDialogWindow

by laurent laffont

I'm a Dialog whose TextEditors characters are replaced by *. Example: (UITheme builder openModal: (PasswordDialogWindow new title: 'Authentification'; textFont: StandardFonts defaultFont; text: 'Enter your password')) entryText explore Laurent On Thu, Mar 31, 2011 at 9:21 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: PasswordDialogWindow > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

April 4, 2011

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

by Eliot Miranda

Hi Dale, this is a known issue spotted and fixed by Ken Treis. I've been tardy in integrating the fix. I'll try and do that in the next couple of days. A test case would help (Ken, Dale?). If you want to try Ken's fix in advance then see http://lists.gforge.inria.fr/pipermail/pharo-project/2011-March/044521.html Apologies, Eliot On Sun, Apr 3, 2011 at 1:04 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > 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 4, 2011

Re: [Pharo-project] Issue 3912 in pharo: Circular dependency with GLMOrangeUITheme

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3912 by stephane...(a)gmail.com: Circular dependency with GLMOrangeUITheme http://code.google.com/p/pharo/issues/detail?id=3912 So far I move all the themes into Polymorph. Removed SoftSqueak, started to rename Glamour (should rename the classes). So I will close this issue since the circular dependency should be over now. In 13131

April 3, 2011

Re: [Pharo-project] Issue 3877 in pharo: Check reduced complexity for UI themes

by pharo＠googlecode.com

Comment #2 on issue 3877 by stephane...(a)gmail.com: Check reduced complexity for UI themes http://code.google.com/p/pharo/issues/detail?id=3877 first step in that direction done: repackaged theme, rename Glamour ones, removed soft squeak

April 3, 2011