- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Sven Van Caekenberghe

On 18 Jun 2013, at 10:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: > the original issue you posted was closed because it is a duplicate of this one > https://pharo.fogbugz.com/default.asp?7526 I saw that, but the title is too restrictive I think. > where you will fine a proper script to kill hanging processesâ¦ OK, but it is not good to keep on producing images with all this shit in them. Maybe we need some QA type unit test that checks for unexpected processes. > On 2013-06-18, at 10:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> >>> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: >>> >>>> Hi, >>>> >>>> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >>>> >>>> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >>>> >>>> â¦ >>>> >>>> <Screen Shot 2013-06-18 at 09.30.30.png> >>>> >>>> This is not good ;-) >>>> >>>> The least we should do is add some script in the release/build process to kill them. >>> >>> I added the following to my startup preferences: >>> >>> Process allInstances do: [ :process | >>> process suspendedContext ifNotNil: [ :context | >>> context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] >> >> OK, thanks. >> But are we sure that no legitimate ones are killed ? >> I am not sure, but I believe Igor's script had more testsâ¦. >> >>>> >>>> Sven >>>> >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> Proudly supporting Pharo >>>> http://pharo.org >>>> http://association.pharo.org >>>> http://consortium.pharo.org >>>> >>>> >>>> >>>> >>> >> >> > >

June 18, 2013

Object>>#if:then:else:

by Camille Teruel

Hello everyone. I see a lot of code that follows the following pattern: <a long expression> <aComplexTest> ifTrue: [ <a long expression> <something> ] ifFalse: [ <a long expression> <something else> ]. The classic refactoring is to store <a long expression> in a temp to avoid repetition: | temp | temp := <a long expression>. temp <aComplexTest> ifTrue: [ temp <something> ] ifFalse: [ temp <something else> ]. Then <a long expression> is evaluated once and the name of the temp can carry a meaningful name that helps reading the code. But this is more verbose than the first version. But if you add the following method in Object: if: conditionBlock then: trueBlock else: falseBlock ^ (conditionBlock cull: self) ifTrue: [ trueBlock cull: value ] ifFalse: [ falseBlock cull: value ] You can then rewrite it like that: <a long expression> if: [ :obj | obj <aComplexTest> ] then: [ :obj | <something> ] else: [ :obj | <something else> ] The names of the block args can give a meaningful name depending on the result of the test (something like ... if: #notEmpty then: [ :collection | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three block also enable a good flexibility: you can omit the arg when irrelevant. Likewise, we could also have Object>>#while:do: while: conditionBlock do: actionBlock ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] What do you think? Camille

June 18, 2013

Re: [Pharo-dev] Zinc problem with PUT requests

by Nicolas Petton

Hi Sven, This is not merged on purpose, as Camillo's patch needs some review and thinking :) Nico On Jun 17, 2013, at 3:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > BTW: there is even code in StHub, namely Hub-CamilloBruni.119, that was not merged properly AFAICT. -- Nicolas Petton http://www.nicolas-petton.fr

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Camille Teruel

On 18 juin 2013, at 10:05, Sven Van Caekenberghe wrote: > > On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: >> >>> Hi, >>> >>> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >>> >>> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >>> >>> â¦ >>> >>> <Screen Shot 2013-06-18 at 09.30.30.png> >>> >>> This is not good ;-) >>> >>> The least we should do is add some script in the release/build process to kill them. >> >> I added the following to my startup preferences: >> >> Process allInstances do: [ :process | >> process suspendedContext ifNotNil: [ :context | >> context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] > > OK, thanks. > But are we sure that no legitimate ones are killed ? > I am not sure, but I believe Igor's script had more testsâ¦. Ok I did't saw Igor's one. Indeed mine doesn't check context sender sender sender method selector == #contents: >>> >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >> > >

June 18, 2013

Re: [Pharo-dev] Barcodes

by Olivier Auverlot

Hi Torsten, Artefact don't support TTF fonts for the moment but it's planned in futures versions. Best regards Olivier :-) Le 14 juin 2013 Ã 16:16, Milan Mimica a Ã©crit : > You just need a TTF font. Does Artefact support TTF? hpdf does. > > > On 14 June 2013 13:58, Torsten Bergmann <astares(a)gmx.de> wrote: > Do we have some barcode stuff available for Pharo? > Something "Form" based that can be used with Artefact? > > Thx > T. > > > > > -- > Milan Mimica > http://sparklet.sf.net

June 18, 2013

Re: [Pharo-dev] NBOpenGL

by Igor Stasenko

On 17 June 2013 21:24, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Igor, > > I currently have two students who are very motivated in working with the open gl binding. > However we are experiencing stability problems. Last week I created a moose image with NBOpenGL and SourceCity and it worked well "SourceCity exampleRpackage" gave me the beautiful visualization. > > Today I cannot open the image anymore. I got the diabolic error "Could not find accessor for variable named "aModuleName" in NativeBoost." I have attached a .log file. Do you have any idea what is going on? > > Are there some resources that are not freed when I saved my image? How can I reset them? > According to your log, NB cannot get source code of methods. make sure .source and .changes files are accessible to image. > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > -- Best regards, Igor Stasenko.

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Igor Stasenko

On 18 June 2013 10:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi guys! > > I worked yesterday on making VMMaker load and work in Pharo2.0 with > filesystem. Now, I want to push my changes in a new development version of > ConfigurationOfCog. But I have some questions: > > Is ConfigurationOfCog used by other people besides Pharo? > > Because so far I see: > - there are two different groups in the conf: #common and #pharo. > - In #common, there is CMakeVMMaker (which in turn loads cairo from > files.pharo.org :)) and the oscog branch of VMMaker. Both have only as > latest committers Igor and Esteban :P. And I > - in #pharo there are nativeboost and some compatibility packages. > > So there are pharo specific stuff in both groups, or am I mistaken? Should > we keep both groups, or make them one and simplify? And how should I push my > changes related with filesystem (pharo-specific) then? > loading this code doesnt means that VM will be built with it. And sure thing your changes is pharo-specfic. > Guille -- Best regards, Igor Stasenko.

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Camillo Bruni

the original issue you posted was closed because it is a duplicate of this one https://pharo.fogbugz.com/default.asp?7526 where you will fine a proper script to kill hanging processes... On 2013-06-18, at 10:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: >> >>> Hi, >>> >>> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >>> >>> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >>> >>> â¦ >>> >>> <Screen Shot 2013-06-18 at 09.30.30.png> >>> >>> This is not good ;-) >>> >>> The least we should do is add some script in the release/build process to kill them. >> >> I added the following to my startup preferences: >> >> Process allInstances do: [ :process | >> process suspendedContext ifNotNil: [ :context | >> context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] > > OK, thanks. > But are we sure that no legitimate ones are killed ? > I am not sure, but I believe Igor's script had more testsâ¦. > >>> >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >> > >

June 18, 2013

Changing ConfigurationOfCog

by Guillermo Polito

Hi guys! I worked yesterday on making VMMaker load and work in Pharo2.0 with filesystem. Now, I want to push my changes in a new development version of ConfigurationOfCog. But I have some questions: Is ConfigurationOfCog used by other people besides Pharo? Because so far I see: - there are two different groups in the conf: #common and #pharo. - In #common, there is CMakeVMMaker (which in turn loads cairo from files.pharo.org :)) and the oscog branch of VMMaker. Both have only as latest committers Igor and Esteban :P. And I - in #pharo there are nativeboost and some compatibility packages. So there are pharo specific stuff in both groups, or am I mistaken? Should we keep both groups, or make them one and simplify? And how should I push my changes related with filesystem (pharo-specific) then? Guille

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Sven Van Caekenberghe

On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: > >> Hi, >> >> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >> >> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >> >> â¦ >> >> <Screen Shot 2013-06-18 at 09.30.30.png> >> >> This is not good ;-) >> >> The least we should do is add some script in the release/build process to kill them. > > I added the following to my startup preferences: > > Process allInstances do: [ :process | > process suspendedContext ifNotNil: [ :context | > context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] OK, thanks. But are we sure that no legitimate ones are killed ? I am not sure, but I believe Igor's script had more testsâ¦. >> >> Sven >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >

June 18, 2013