October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] StackVM on RaspberryPi

by Serge Stinckwich

On Thu, Oct 3, 2013 at 5:37 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Using Nick's process for compiling the vm I reintroduce a process to compile > StackVM on Rasp. > So we have a StackVM compiling process on Rasp, with a simple > CMakeConfiguration class and a simple install script for Rasp. > Next step is to recompile from Rasp. Great ! where is the documentation to do that available ? Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 6, 2013

FogBugz customizations

by btc＠openinworld.com

Just browsing around FogBugz docs a bit, I came across this... "Users can input any arbitrary javascript and css that you want to run on any FogBugz page." [1] I wonder if Amber could be loaded on top Fogbugz to do something-awesome(TM) with SmalltalkHub integration? Actually back to reality... the "13. Notification for Updates to Case Youâre Working On" script [2] looks but I don't have a <New Customization> button [3]. Would it be possible to get either the facility to add that script myself, or someone to add that particular script to the Available Customizations. cheers -ben [1] http://www.fogcreek.com/fogbugz/plugins/plugin.aspx?ixPlugin=16 [2] http://help.fogcreek.com/8534/bugmonkey-script-archive [3] http://help.fogcreek.com/7585/customizing-your-fogbugz-site-with-bugmonkey

Oct. 6, 2013

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

by btc＠openinworld.com

Oct. 6, 2013

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

by Benjamin

I would first experiment to run the critics only on the modified code, not the full package :) Then you can have a pretty accurate feedback Ben On Oct 6, 2013, at 4:26 PM, btc(a)openInWorld.com wrote: > Benjamin wrote: >> >> 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 >> > That sounds cool. Without having used Code Critics yet (I've just discovered the menu option the Nautilus package pane), I am interested if your idea would that include a diff with the critics from the previous commit? While it a full list of critic-isms is be good prompt to reduce the list to zero, also useful would be knowing if any new critic-isms had been introduced in this commit. This might help at least maintain the status-quo without having to solve all existing critic-isms at once, to avoid new ones being lost amongst a potentially large existing list. > > cheers -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

pharo-vm reattached history + new branches

by Camillo Bruni

I reattached a clean version of the old history to the pharo-vm repository https://github.com/pharo-project/pharo-vm/network As a result all the SHA hashes of the commits changed :/ AFAIK you should be fine with your local copies by pulling the latest changes from pharo-vm and merge. Additionally we have now 2 branches following according to git-flow: - master: containing the stable version - develop: containing the latest dev version

Oct. 6, 2013

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