- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] External Semaphores leaking in Socket

by Marcus Denker

On Oct 6, 2013, at 12:51 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > I opened a ticket at https://pharo.fogbugz.com/f/cases/11797 but I'm not sure how I am supposed to provide fixes made against a pharo2.0 image. Probably I should fix this againt 3.0 but then I'm still a 2.0 user :) The best is to have two issues: one for 2.0 and one for 3.0. Then we can first commit it to Pharo3, test some days and then do the pharo2 version (you need to do two slices, one for 2.0 in the 2.0 inbox and one for 3.0) Marcus

Oct. 6, 2013

Re: [Pharo-dev] New Critic Rule: Nobody should directly send #methodDict

by btc＠openinworld.com

Oct. 6, 2013

Re: [Pharo-dev] New Critic Rule: Nobody should directly send #methodDict

by StÃ©phane Ducasse

> What I would like (and will probably give a try soon) is to run some critics automatically before committing a MC package :) > That's how it's done in WebStorm by example, and I love this feature Yes this is a good practice. > Ben

Oct. 6, 2013

Re: [Pharo-dev] New Critic Rule: Nobody should directly send #methodDict

by Benjamin

What I would like (and will probably give a try soon) is to run some critics automatically before committing a MC package :) That's how it's done in WebStorm by example, and I love this feature Ben On Oct 6, 2013, at 2:19 PM, btc(a)openInWorld.com wrote: > StÃ©phane Ducasse wrote: >> Hi >> I'm really happy because >> "New Critic Rule: Nobody should directly send #methodDict" is the way to go. We should document the system design using automatic rules! >> Excellent! >> >> Stef >> >> > So you could also have "Critic Rule: Should not implement system method." Like PharoLauncher got stuck having implemented class-side method #layout [1] > > btw, apart from having a separate critics browser, are the any plans to integrate it further into the system, perhaps as: > * a Critics Panel in Nautilus in the same position as the Comments Panel, or perhaps appended to the Comment. * contextual highlighting > > cheers -ben > > [1] https://pharo.fogbugz.com/default.asp?11783 > > >

Oct. 6, 2013

Re: [Pharo-dev] Starting image gives FileWriteError: File stdout is closed - huh?

by phil＠highoctane.be

OSX Lion On Sun, Oct 6, 2013 at 2:22 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 6 October 2013 11:21, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > Now, when starting my image: > > > > FileWriteError: File stdout is closed > > MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: > > MultiByteFileStream(StandardFileStream)>>next:putAll:startingAt: > > MultiByteFileStream>>basicNext:putAll:startingAt: > > UTF8TextConverter(TextConverter)>>nextPutByteString:toStream: > > UTF8TextConverter(TextConverter)>>nextPutAll:toStream: > > MultiByteFileStream>>nextPutAll: > > > > I was a link while Googling but not resolution. > > > > What to do? > > What operating system? Windows? > > frank > > > -- > > Phil > >

Oct. 6, 2013

Re: [Pharo-dev] additional Milestone label for applications

by Camillo Bruni

seems like it works, so by default the pharo-internal projects will have the Area "1. Pharo Image" set. Why the "1."? Well I cannot order the Areas, and the first one is selected by default :P The filter "review" and "integration" now only look at issues that have the proper Area set. On 2013-10-06, at 08:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks! > This is a good idea. > > On Oct 6, 2013, at 1:57 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>>> I think it should just be fine if we define a different workflow (and thus different labels) for external projects... >>>> >>>> >>> The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area. >> >> So we need to have 2 things >> 1. a separate project for each external project that wants to report >> 2. a separate Area for these external projects >> >> For instance, NativeBoost has both a stable version in the image and a development >> version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). >> However, if the bug concerns the development version we set the Area to something project >> specific. >> >> I will try to update the tracker and the filters to reflect that... > >

Oct. 6, 2013

Re: [Pharo-dev] New Critic Rule: Nobody should directly send #methodDict

by StÃ©phane Ducasse

ben this is not that we do not have plan and vision. Just that we have lot of consumers and not enough people thinking that Pharo is theirs :) Stef On Oct 6, 2013, at 2:19 PM, btc(a)openInWorld.com wrote: > StÃ©phane Ducasse wrote: >> Hi >> I'm really happy because >> "New Critic Rule: Nobody should directly send #methodDict" is the way to go. We should document the system design using automatic rules! >> Excellent! >> >> Stef >> >> > So you could also have "Critic Rule: Should not implement system method." Like PharoLauncher got stuck having implemented class-side method #layout [1] > > btw, apart from having a separate critics browser, are the any plans to integrate it further into the system, perhaps as: > * a Critics Panel in Nautilus in the same position as the Comments Panel, or perhaps appended to the Comment. * contextual highlighting > > cheers -ben > > [1] https://pharo.fogbugz.com/default.asp?11783 > > >

Oct. 6, 2013

Re: [Pharo-dev] Starting image gives FileWriteError: File stdout is closed - huh?

by Frank Shearar

On 6 October 2013 11:21, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Now, when starting my image: > > FileWriteError: File stdout is closed > MultiByteFileStream(StandardFileStream)>>primWrite:from:startingAt:count: > MultiByteFileStream(StandardFileStream)>>next:putAll:startingAt: > MultiByteFileStream>>basicNext:putAll:startingAt: > UTF8TextConverter(TextConverter)>>nextPutByteString:toStream: > UTF8TextConverter(TextConverter)>>nextPutAll:toStream: > MultiByteFileStream>>nextPutAll: > > I was a link while Googling but not resolution. > > What to do? What operating system? Windows? frank > -- > Phil

Oct. 6, 2013

Re: [Pharo-dev] New Critic Rule: Nobody should directly send #methodDict

by btc＠openinworld.com

StÃ©phane Ducasse wrote: > Hi > > I'm really happy because > > "New Critic Rule: Nobody should directly send #methodDict" is the way to go. We should document the system design using > automatic rules! > > Excellent! > > Stef > > So you could also have "Critic Rule: Should not implement system method." Like PharoLauncher got stuck having implemented class-side method #layout [1] btw, apart from having a separate critics browser, are the any plans to integrate it further into the system, perhaps as: * a Critics Panel in Nautilus in the same position as the Comments Panel, or perhaps appended to the Comment. * contextual highlighting cheers -ben [1] https://pharo.fogbugz.com/default.asp?11783

Oct. 6, 2013

Re: [Pharo-dev] [update 3.0] #30455

by Marcus Denker

On Oct 6, 2013, at 12:38 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-10-06, at 00:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> 11792 First simplistic file system tree inspector >> https://pharo.fogbugz.com/f/cases/11792 >> >> >> actually a FileReference tree inspector... lots of improvments possible >> inspect >> >> FileSystem workingDirectory >> >> and select the FileReference Tree Inspector > > ha! nice :) actually we could reuse the file list here, no? Yesâ¦ that would be best. Marcus

Oct. 6, 2013