January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] fixing deprecation process once for all

by StÃ©phane Ducasse

On Jan 3, 2011, at 9:34 AM, Henrik Johansen wrote: > Sounds good to me, to me there's a missing when/why description though: > Which criterias do we use for when deprecating is warranted? > - # of callers in image required to deprecate planned for removal (0?) > - # of callers / age when considering renaming for clarity (low > number of callers and/or age < X years?) > - new/better API available (always, as long as new place documented?) > > As for the how, since we do have an integration process, would it not > also be desirable with some sort of integration lint tool working on slices? yes now I do not time for that... :( > For deprecations, it could do things like: > - Checking for method removals without corresponding method additions in > a slice aimed at recategorization (happened quite a few times...) YES! > - Deprecations rather than removals of non-private methods This is true that having something more automatic would be good. In fact I would like to have the rbengine available all the time. but even if I said that I did not make any progress on using metacello to manage core/dev.... Stef > > Cheers, > Henry > > Den 01.01.2011 12:35, skrev StÃ©phane Ducasse: >> I took 5 min and wrote down that >> http://code.google.com/p/pharo/wiki/DeprecationProcess >> >> comment if you want. >> >> >

Jan. 3, 2011

Re: [Pharo-project] Issue 3503 in pharo: LongMessageDialogWindow should be resizeable

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3503 by stephane.ducasse: LongMessageDialogWindow should be resizeable http://code.google.com/p/pharo/issues/detail?id=3503 (No comment was entered for this change.)

Jan. 3, 2011

Re: [Pharo-project] Issue 3414 in pharo: CompilerEvaluationTest>>#testEvaluationOfSelfSend fails

by pharo＠googlecode.com

Comment #8 on issue 3414 by stephane.ducasse: CompilerEvaluationTest>>#testEvaluationOfSelfSend fails http://code.google.com/p/pharo/issues/detail?id=3414 in 12292

Jan. 3, 2011

Re: [Pharo-project] fixing deprecation process once for all

by Henrik Johansen

Sounds good to me, to me there's a missing when/why description though: Which criterias do we use for when deprecating is warranted? - # of callers in image required to deprecate planned for removal (0?) - # of callers / age when considering renaming for clarity (low number of callers and/or age < X years?) - new/better API available (always, as long as new place documented?) As for the how, since we do have an integration process, would it not also be desirable with some sort of integration lint tool working on slices? For deprecations, it could do things like: - Checking for method removals without corresponding method additions in a slice aimed at recategorization (happened quite a few times...) - Deprecations rather than removals of non-private methods Cheers, Henry Den 01.01.2011 12:35, skrev StÃ©phane Ducasse: > I took 5 min and wrote down that > http://code.google.com/p/pharo/wiki/DeprecationProcess > > comment if you want. > >

Jan. 3, 2011

Re: [Pharo-project] IRC meeting next Tuesday, January 4, at ...?

by StÃ©phane Ducasse

Thanks for the call adrian. I will be travelling until 16h (it was not planned when I proposed that dat) but there is no problem, Stef On Jan 2, 2011, at 10:34 PM, Adrian Lienhard wrote: > Hi all, > > During the last meeting [1] we decided to do the next one on January 4 but we didn't decide when to start. > > The previous meeting started at 20:00 CET/UTC/GMT+1, which may not be optimal for people in other time zones. If somebody likes to suggest another time, please let us know soon! > > Cheers, > Adrian > > [1] http://pharo-project.org/news?article=irc-meeting-notes

Jan. 3, 2011

Re: [Pharo-project] Issue 3503 in pharo: LongMessageDialogWindow should be resizeable

by pharo＠googlecode.com

Updates: Labels: Milestone-1.2 Comment #1 on issue 3503 by aplantec: LongMessageDialogWindow should be resizeable http://code.google.com/p/pharo/issues/detail?id=3503 SLICE-Issue-3503-LongMessageDialogWindow-should-be-resizeable in InBox. Could be for 1.2 since it only needs #isResizeable redefinition in LongMessageDialogWindow: LongMessageDialogWindow>>isResizeable "Answer whether we are not we can be resized." ^true

Jan. 3, 2011

[Pharo-project] Issue 3503 in pharo: LongMessageDialogWindow should be resizeable

by pharo＠googlecode.com

Status: Accepted Owner: aplantec Labels: Milestone-1.3 New issue 3503 by aplantec: LongMessageDialogWindow should be resizeable http://code.google.com/p/pharo/issues/detail?id=3503 Really more confortable for system/about message or the about message of a SystemWindow as examples.

Jan. 3, 2011

Re: [Pharo-project] alternative source for rfb server?

by Yanni Chiu

On 02/01/11 8:39 PM, sergio_101 wrote: > it looks like http://source.lukas-renggli.ch/ has been around for awhile.. > > i think this is causing my problems in trying to find an RFB server.. > > does anyone have any ideas how i might get a working RFB server? http://hudson.jooshr.org/job/MyBaseImage/ I can send you the RFB packages from the cache, if you need those.

Jan. 3, 2011

Re: [Pharo-project] new Cog VMs

by Andres Valloud

That sounds familiar... are there bitfields next to a memory allocation zone boundary? GCC will issue read instructions that read off the bitfield (documented in the manual --- can't really complain), so you can get a segfault reading a bitfield if GCC emits instructions at compile time that read off the allocation edge at run time... On 1/2/11 10:09 , Eliot Miranda wrote: > Hi All, > > looks like there are issues running Cog on 64-bit linux. I only > have a 32-bit one to hand so it'll be a while before I can look at this. > > BTW, it would really help if when people post bugs they give > - a URL to the image and changes, not just a name like Pharo 1.1.1. A > pointer to the exact bits eliminates any possibility that I will fetch > the wrong image and not be able to reproduce > - the exact directory something is installed in, not just the name but > the full path, and whether it is remote ounted or not. I just fixed a > crash on windows for Torsten that didn't show on a remote-mounted drive > but caused a hard crash if installed as c:\pharo. So saying "its in > coglinux/" isn;t being precise enough. > > TIA > > > best > Eliot > > On Sun, Jan 2, 2011 at 11:01 AM, Philippe Marschall <kustos(a)gmx.net > <mailto:kustos@gmx.net>> wrote: > > On 02.01.2011 16:50, Eliot Miranda wrote: > > Hi Philippe, > > > > what image, what OS and what directories are the vm and image > > installed in (yes it can make a difference). > > - Pharo 1.1.1 > - $uname -a > Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010 > x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux > - image lies in some subdirectory of the user home, Cog is extracted in > the same folder, so it's under coglinux/ > > Cheers > Philippe > > >

Jan. 3, 2011

Re: [Pharo-project] new Cog VMs

by mkobetic＠gmail.com

"Eliot Miranda"<eliot.miranda(a)gmail.com> wrote: > so find new VMs in > VM.r2341/<http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. Yup, much better on my end. Thanks! Martin

Jan. 3, 2011