- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [INRIAGforge] Monday 26th October 2009 : scheduled service downtime
by StÃ©phane Ducasse Oct. 23, 2009

Oct. 23, 2009

Begin forwarded message: > From: <noreply(a)gforge.inria.fr> > Date: October 23, 2009 3:40:36 PM GMT+02:00 > To: stephane.ducasse(a)inria.fr > Subject: [INRIAGforge] Monday 26th October 2009 : scheduled service > downtime > > > On Monday 26th October 2009, from 18:30 to 22:00 the site and all > associated services will be unavailable due to maintenance > operations on the electrical supply. > > A reply to this announce will signal the end of the maintenance. > > We apologize for any inconvenience. > > Cordially, > > -- > The InriaGforge Team > > >

1 0

[Pharo-project] Finalization question
by Schwab,Wilhelm K Oct. 23, 2009

Oct. 23, 2009

Hello all, I have started to port some of my code that relies on Dolphin's finalization. The idea is that one sends #beFinalizable to the object requiring finalization. Dolphin sets a flag on the object (in its header??) that the vm later notices.

2 5

[Pharo-project] #1339 - ODBC crashes vm
by Schwab,Wilhelm K Oct. 23, 2009

Oct. 23, 2009

Hello all, I decided to try the simplest of all possible tests to reproduce my ODBC crash: start with a fresh beta image, load FFI and ODBC, and then try to connect to a non-existent data source. It indeed crashes the Linux VM, and the Windows VM hangs badly. Sorry about this next part: I marked it for 1.0. Bill

3 6

[Pharo-project] VNC (RFB) problem (2nd attempt)
by Dennis Schetinin Oct. 23, 2009

Oct. 23, 2009

I've asked this some time ago, and got no reply. Another attempt: Using *pharo1.0-10466-BETAweb09.10.1* + *RFB-DamienCassou.28* (still the > latest): the image *stops to respond after closing connection remotely*. > Stopping the server leaves image ok. > Can anybody reproduce this? I'm working on Russian Smalltalk User Group web server currently. This package has shown itself as a very helpful tool during my last web project, and it will be great if I can use it... If I get no reply because this is not the correct list, please give me an advice about where to send the report. :) -- Dennis Schetinin

3 7

[Pharo-project] [update 1.1] #11013
by StÃ©phane Ducasse Oct. 23, 2009

Oct. 23, 2009

11013 ----- - Issue 1334: [Squeak trunk] New tests for String format - Issue 1333: [squeak trunk] Add timeProfile to BlockClosure - Issue 1335: [Squeak trunk] Faster shuffle - Issue 1136: DejaVu strinkeFonts render ascii character in WideStrings as black boxes - Issue 1305: Deleting morphs from the yellow button menu - Issue 1303: MNU #who when decompiling Fix the sender of #who with method from trunk (tfel) I don t know if this test is still relevant: = #unknown ifTrue: [] Or if it should be replaced with: ifNil: [] See http://code.google.com/p/pharo/issues/detail?id=1303

1 0

Re: [Pharo-project] [squeak-dev] Re: Issue with traits
by Adrian Lienhard Oct. 23, 2009

Oct. 23, 2009

I've fixed this issue in Pharo a couple of months ago. CompiledMethods are not shared anymore, so methodClass returns the expected class. At the time I implemented traits (2004?), there were no method properties and hence sharing compiled methods worked -- of course except for super sends in which case the method was always recompiled (so the answer to Andreas' question below is b)). Cheers, Adrian On Oct 21, 2009, at 08:42 , Andreas Raab wrote: > Igor Stasenko wrote: >> now what i found interesting: >> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo) >> but as side effect, we got this one: >> (ABBAB methodDict at: #foo) methodClass ==> ABBAC >> which i find a bit disturbing :( > > Yes, seems wrong. VERY wrong. Try this: > > Object subclass: #BaseA > > BaseA>>foo > ^42 > > Object subclass: #BaseB > > BaseB>>foo > ^13 > > And then create subclasses of BaseA and BaseB which use your trait > and have the trait implementation use "^super foo". One of two > things should happen: > > a) They both return the same (incorrect) value (which would be > expected if methodClass is the same). In this case it's just plain > broken. > > b) They both return different values, in which case there is code > that handles super sends specifically and the sharing is simply an > unnecessary optimization. > > I hope it's the latter case which would mean you only need to throw > out the test for super sends and do whatever that code was doing to > begin with ;-) > > Cheers, > - Andreas > >

3 4

[Pharo-project] the we site does not point to the rc1 image/
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

can somebody fix it? Stef

6 12

Re: [Pharo-project] Bug in OCompletion
by Mariano Martinez Peck Oct. 22, 2009

Oct. 22, 2009

This bug has been closed but I can still reproduce it in 10479. Can someone please test it and tell me if I am not the only one. Thanks mariano On Wed, Sep 23, 2009 at 4:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > Begin forwarded message: > > *From: *Mariano Martinez Peck <marianopeck(a)gmail.com> > *Date: *September 23, 2009 8:20:40 PM CEDT > *To: *Pharo Development <pharo-project(a)lists.gforge.inria.fr> > *Subject: **[Pharo-project] Bug in OCompletion* > *Reply-To: *Pharo-project(a)lists.gforge.inria.fr > > http://code.google.com/p/pharo/issues/detail?id=1236 > > Tested with OBSystemBrowserAdaptor in pharo1.0-10451-BETAdev09.09.3 on > Windows. > > To reproduce: > > 1) Open a System Browser > 2) Create a new class. When you do this, when you are changing > "#NameOfSubclass" to "#YourClass", after doing this press the down arrow > key > 3) An empty pop up will be brought and the keyboard won't respond. To fix > this, you must press "Esc" key. > > > Best, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

2 3

Oct. 22, 2009

Hi guys we tried to use and force you to use the new inspector and it does not fly that well. I'm sure that frederick is open to suggestion so please send your remarks. Here were mine :) Stef Hello Stef, here what is really strange and annoying is that we cannot see the collection elements in the right pane Now it is fixed. on the left Elements is confusing. because this is not clear the relationship with array, firstInd.... It shows only elements of any kind of collection (it is simply a collect: [:o | o] on the collection). on the right this is also frustrating that we cannot modify, touch the elements. Ok... but you can expand the Elements, select the element you want to change, put the new value in the description pane and accept it. I'm not sure that we want to see the class (in an expandable manner). For the methods may be you want to stop and show the methods but expandabel may be by defualt you should not show the class and methods as expandable and have a menu entry doing that (expand) I'm not sure to understand what you want. For me the NewInspector it is a like an infinite inspector: if you want to go into an object, you can. So if you want to inspect a class or the methods, you should have the possibility to do it. FrÃ©d

8 11

Oct. 22, 2009

Hi I released image 11011 for 1.1-alpha on the inria web site Stef

1 0