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

[Pharo-project] Metacello issues on Pharo 2.0

by Christophe Demarey

Hi all, I have issues with Metacello on Pharo 2.0 If I load and run tests for the version used in Pharo1.4, it gives: (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: 'Tests' Metacello packages shipped with Pharo 2.0 are all packages derived from the latest stable Metacello baseline (1.0-beta.31.1.5) except the MetacelloToolBox. If I load and run tests packages with version described in the latest stable Metacello baseline (1.0-beta.31.1.5), i.e. : Metacello-TestsCore-DaleHenrichs.14 and Metacello-TestsMC-dkh.351, it gives (Pharo 2.0 #20547): So, it seems there are some problems. Do we use the rigth versions of Metacello packages? Regards, Christophe.

Feb. 15, 2013

Re: [Pharo-project] monkey stuff

by Marcus Denker

On Feb 15, 2013, at 2:39 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I changed the monkey to run all tests, so the integration process will take > considerable more time but at the same time will hopefully catch more bugs. > Good! We then should speed up the run of testsâ¦ I am sure there are some extreme cases (it takes 5 - 6 minutes). Another thing is that we should max out the slave. so e.g. have 15 linux slaves, max CPU, 2 queues per machineâ¦ so we can run multiple Monkey runs in parallel to other builds. And even later we should spawn multiple images that run only parts of the tests.. ;-) > The first complete check is already running here: > > https://ci.inria.fr/pharo/job/Pharo-2.0-Issue-Tracker/10550/console > >

Feb. 15, 2013

[Pharo-project] monkey stuff

by Camillo Bruni

I changed the monkey to run all tests, so the integration process will take considerable more time but at the same time will hopefully catch more bugs. The first complete check is already running here: https://ci.inria.fr/pharo/job/Pharo-2.0-Issue-Tracker/10550/console

Feb. 15, 2013

[Pharo-project] [update 2.0] #20548

by Marcus Denker

20548 ----- Issue 7512: Nautilus Class side Checkbox>>mouseUpBalk http://code.google.com/p/pharo/issues/detail?id=7512 Issue 7501: Monkey needs to run *ALL* tests http://code.google.com/p/pharo/issues/detail?id=7501 Issue 7109: Nautilus: still some menues with lowercase menu items left http://code.google.com/p/pharo/issues/detail?id=7109 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.771.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.423.diff http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.62.diff

Feb. 15, 2013

[Pharo-project] obsolete behaviors in image

by Martin Dias

Hi In 20547, I do: SystemNavigation default obsoleteBehaviors. and obtain: an Array(Behavior Behavior class) Which sounds weird. I tried with: SystemNavigation default obsoleteBehaviors first == Behavior and it's false. So at least it's not the class installed in system dictionary, but an older version (probably). I tried to remove them with: SmalltalkImage current fixObsoleteReferences. 3 timesRepeat: [ Smalltalk garbageCollect ]. but no changes. Is this a known issue? I used #pointersTo to see who is pointing it but I didn't understand yet. Martin

Feb. 15, 2013

Re: [Pharo-project] Another stupid question

by Henrik Sperre Johansen

On 15.02.2013 11:29, Benjamin wrote: > On Feb 15, 2013, at 11:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 15 Feb 2013, at 11:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On Feb 15, 2013, at 1:51 AM, Benjamin wrote: >>> >>>> On Feb 15, 2013, at 1:40 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >>>> >>>>> This was just an example to play with since you asked >>>>> for a #convertFromBase:to: method in your original mail >>>>> and one cant provide such a method on Number. Your >>>>> original request >>>>> >>>>> 11 convertFromBase: 2 to: 10 >>>>> >>>>> may work - but it wont work for hex values: >>>>> >>>>> FF convertFromBase: 16 to: 10 >>>>> >>>>> then FF would have to be a string. >>>>> >>>>> 'FF' convertFromBase: 16 to: 10 >>>>> >>>>> So having a #convertFromBase:to: on String is not to recommend >>>>> (especially since the string has to be in a number format) >>>>> and also not necessary. I should have added this to my mail >>>>> as a warning. >>>>> >>>>> Just use >>>>> >>>>> (Number readFrom: self base: sourceBase) printStringBase: targetBase >>>>> >>>> Thank you >>>> >>>>> If necessary put it in a private helper method for conversion. >>>>> >>>>> May I ask why you require conversions between the different base systems? >>>> I have to implement a FTP server for a lecture, and the port is provided in a strange format (twice 8 bits). >>>> So I needed to change the port in base 10 to base 2, cut it into two pieces, then turn those pieces back in base 10 :) >>>> >>>>> Working on a hex editor for Nautilus? ;) >>>> Is a hex editor a need ? :) >>>> >>>> Ben >>>> >>>>> Bye >>>>> T. >>>>> >>>>> >>>>> >>>> >>> Wait, wait, wait. >>> >>> You mean like #[16 45] ? >>> >>> What's wrong with >>> Number1 := sourceNumber >> 8 >>> Number2 := sourceNumber bitAnd: 255 >>> >>> ? >>> >>> Cheers, >>> Henry >> There is also >> >> sourceNumber asByteArrayOfSize: 2 >> >> 1000 asByteArrayOfSize:2 #[3 232] > Thank you guys :) > > I definitely feel stupid now :D > > Ben http://www.catb.org/esr/faqs/smart-questions.html#idp29958640http://www.cat… ;) Cheers, Henry

Feb. 15, 2013

Re: [Pharo-project] Opening a webbrowser (using NB on non-Windows)

by Camillo Bruni

OSProcess command: 'open http://foo.bar.com' On 2013-02-15, at 02:12, "Torsten Bergmann" <astares(a)gmx.de> wrote: > In Pharo 2.0 one can now use > > NBWin32Shell shellBrowse: 'http://www.pharo-project.org' > > which will open an external webbrowser on the given URL. This is currently limited > to Windows. > > Anyone able to implement/call appropriate NB functions for Mac and Linux? > I would like to see a unified interface coming with 2.0 > > NBWebbrowser shellBrowse: url > > dispatching to the appropriate class depending on OS. > > Since these days a lot of work is done using webbrowsers I think > a unified way to open a browser on a given URL is required for Pharo. > > I also need this for the upcoming Pharo online help to work on all major platforms. > > Thanks > T. >

Feb. 15, 2013

Re: [Pharo-project] TxTextMorph based on new text model

by phil＠highoctane.be

I guess if we could have something that lays out basic text properly (e.g. bold/italics do not mess everything) and a Paragraph>>composeAll: that works, it would be a huge plus. The main issue IMV is that we keep on recreating Paragraphs and that whole logic should be revised. Phil 2013/2/15 Stephan Eggermont <stephan(a)stack.nl>: > Sean wrote: > Denis Kudriashov wrote >>> Do you think that presenting any letter with real object (not just >>> character) is sufficient for modern computers? I think not. Of course such >>> model significantly simplified all logic around text layout stuff. But I >>> think it is too expensive. > > In a case study on designing a document editor in 'Design Patterns (1995)' , > there is a reference to a thesis from 1993 showing that using Flyweight > or sharing commonality makes it fast enough. I assume that was c++, but > 20 years of hardware improvements should be enough. > > Paul R Calder. Building User Interfaces with Lightweight Objects. > PhD Thesis, Stanford University, 1993 > >>I don't know how efficient it would be, but how much text do we really >>layout at once? If it makes the code simpler and more beautiful, then it >>would be my starting point. Doing otherwise is premature optimization. > > One book at a time. In multiple columns, with tables. But we don't need > to show more than one screenful at a time. > > I noticed the current strategy seems to be to make a very simple model > work, and add abstractions late. That means a lot of refactorings will be > needed. Cocoa fundamental abstractions are TextStorage, LayoutManager, > TextContainer and TextView. LayoutManager uses TypeSetter(s) to layout > glyphs in lines according to the dimensions of one or more text container > objects in one or more text views, directs the GlyphGenerator to translate > characters in the textstorage into glyphs... > > Stephan > >

Feb. 15, 2013

Re: [Pharo-project] Another stupid question

by Benjamin

On Feb 15, 2013, at 11:24 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 15 Feb 2013, at 11:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> On Feb 15, 2013, at 1:51 AM, Benjamin wrote: >> >>> On Feb 15, 2013, at 1:40 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >>> >>>> This was just an example to play with since you asked >>>> for a #convertFromBase:to: method in your original mail >>>> and one cant provide such a method on Number. Your >>>> original request >>>> >>>> 11 convertFromBase: 2 to: 10 >>>> >>>> may work - but it wont work for hex values: >>>> >>>> FF convertFromBase: 16 to: 10 >>>> >>>> then FF would have to be a string. >>>> >>>> 'FF' convertFromBase: 16 to: 10 >>>> >>>> So having a #convertFromBase:to: on String is not to recommend >>>> (especially since the string has to be in a number format) >>>> and also not necessary. I should have added this to my mail >>>> as a warning. >>>> >>>> Just use >>>> >>>> (Number readFrom: self base: sourceBase) printStringBase: targetBase >>>> >>> >>> Thank you >>> >>>> If necessary put it in a private helper method for conversion. >>>> >>>> May I ask why you require conversions between the different base systems? >>> >>> I have to implement a FTP server for a lecture, and the port is provided in a strange format (twice 8 bits). >>> So I needed to change the port in base 10 to base 2, cut it into two pieces, then turn those pieces back in base 10 :) >>> >>>> Working on a hex editor for Nautilus? ;) >>> >>> Is a hex editor a need ? :) >>> >>> Ben >>> >>>> >>>> Bye >>>> T. >>>> >>>> >>>> >>> >>> >> Wait, wait, wait. >> >> You mean like #[16 45] ? >> >> What's wrong with >> Number1 := sourceNumber >> 8 >> Number2 := sourceNumber bitAnd: 255 >> >> ? >> >> Cheers, >> Henry > > There is also > > sourceNumber asByteArrayOfSize: 2 > > 1000 asByteArrayOfSize:2 #[3 232] Thank you guys :) I definitely feel stupid now :D Ben > > Sven

Feb. 15, 2013

Re: [Pharo-project] Another stupid question

by Sven Van Caekenberghe

On 15 Feb 2013, at 11:11, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Feb 15, 2013, at 1:51 AM, Benjamin wrote: > >> On Feb 15, 2013, at 1:40 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >> >>> This was just an example to play with since you asked >>> for a #convertFromBase:to: method in your original mail >>> and one cant provide such a method on Number. Your >>> original request >>> >>> 11 convertFromBase: 2 to: 10 >>> >>> may work - but it wont work for hex values: >>> >>> FF convertFromBase: 16 to: 10 >>> >>> then FF would have to be a string. >>> >>> 'FF' convertFromBase: 16 to: 10 >>> >>> So having a #convertFromBase:to: on String is not to recommend >>> (especially since the string has to be in a number format) >>> and also not necessary. I should have added this to my mail >>> as a warning. >>> >>> Just use >>> >>> (Number readFrom: self base: sourceBase) printStringBase: targetBase >>> >> >> Thank you >> >>> If necessary put it in a private helper method for conversion. >>> >>> May I ask why you require conversions between the different base systems? >> >> I have to implement a FTP server for a lecture, and the port is provided in a strange format (twice 8 bits). >> So I needed to change the port in base 10 to base 2, cut it into two pieces, then turn those pieces back in base 10 :) >> >>> Working on a hex editor for Nautilus? ;) >> >> Is a hex editor a need ? :) >> >> Ben >> >>> >>> Bye >>> T. >>> >>> >>> >> >> > Wait, wait, wait. > > You mean like #[16 45] ? > > What's wrong with > Number1 := sourceNumber >> 8 > Number2 := sourceNumber bitAnd: 255 > > ? > > Cheers, > Henry There is also sourceNumber asByteArrayOfSize: 2 1000 asByteArrayOfSize:2 #[3 232] Sven

Feb. 15, 2013