December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Pharo 1.2 - default packages

by laurent laffont

Hi, What do you think about adding these packages as default in Pharo 1.2: - ConfigurationOfMocketry - ConfigurationOfXMLSupport - ConfigurationOfCryptography (does'nt exist yet, planned to be created in a local coding-dojo on Tuesday). Motivations: - XMLSupport and Cryptography are often needed to consume web services - Mocketry because I want to write tests using Mocks and it's easier to work when tools are in standard Pharo (and then newcomers can see Mocketry examples). I will update ConfigurationOfPharo 1.2 (beta3 ?) if people agree. Cheers, Laurent Laffont

Dec. 17, 2010

Re: [Pharo-project] Dynamic Arrays view index at execution

by Peter Hugosson-Miller

As Henrik pointed out, "foo at 1" won't even compile, let alone return anything, because "1" isn't a valid name for a method, and "at" (without the ":") doesn't take any arguments. To get the first object in an indexable collection, be it String, Array or whatever, you use "foo at: 1". To get the third object, you use "foo at: 3". It really is as simple as that. I usually say that with Smalltalk, if what you're doing feels complicated or hard, then you're doing it wrong. Here, you were simply missing the ":". -- Cheers, Peter. On 16 dec 2010, at 23:22, flebber <flebber.crue(a)gmail.com> wrote: > > > Henrik Sperre Johansen wrote: >> >> >> >> Den 16.12.2010 14:48, skrev flebber: >>> HI >>> >>> doing the pharo tutorial and I wanted to know how pharo viewed the >>> dynamic >>> array at index 3(seems smalltalk starts at 1 not 0) >>> >>>> From the xample simple enough >>> { (2+3) . (6*6) . 'hello', ' Stef'} size. 3 >>> >>> from the strings example we found index by >>> >>> 'ProfStef' at: 1. $P >>> >>> so I thought { (2+3) . (6*6) . 'hello', ' Stef'} at 3. would let me know >>> what the array was evaluated to after execution but it doesn't. Is it >>> confused because it doesn't know whether I want the third array element >>> or >>> the third character? >>> >>> Led me to wonder the correct way if doing this, so that I could evaluate >>> array 1 * 2. >>> >>> { (2+3) . (6*6) . 'hello', ' Stef'} at 1 * at 2. 180 >>> >>> >>> Cheers >> >> What do you mean? >> The dynamic array is created with three elements, >> 5 (2+3) at index 1, >> 36 (6*6) at index 2, and >> 'hello Stef' ('hello', ' Stef') at index 3. >> >> at: 3 thus returns the string. >> at 3 is invalid, as it is basically 2 method calls, array does not >> understand a message called #at, and #3 is an invalid selector anyways. >> >> For your second expression, writing >> ({ (2+3) . (6*6) . 'hello', ' Stef'} at: 1) * (at: 2) would not work, >> as you're missing the receiver for the second at: call. >> you'd need to do something like: >> array := { (2+3) . (6*6) . 'hello', ' Stef'}. >> (array at: 1) * (array at: 2). 180 >> >> Cheers, >> Henry >> >> >> >> >> > Yes so simply if at 1 returns the first element of a string, what returns > the third element of dynamic array, do you have to assign a varaible for the > array to be able to retrieve elements? > -- > View this message in context: http://forum.world.st/Dynamic-Arrays-view-index-at-execution-tp3090891p3091… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 17, 2010

Re: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config button doesn't work

by pharo＠googlecode.com

Comment #1 on issue 3446 by elpochodelagente: VMMakerTool load config button doesn't work http://code.google.com/p/pharo/issues/detail?id=3446 forgot to say, loading VMMaker with: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfVMMaker'; load. (ConfigurationOfVMMaker project version: '1.3') load

Dec. 17, 2010

[Pharo-project] Issue 3446 in pharo: VMMakerTool load config button doesn't work

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3446 by elpochodelagente: VMMakerTool load config button doesn't work http://code.google.com/p/pharo/issues/detail?id=3446 Pharo image: dev 1.1.1 Pharo core version: Pharo-1.1-11411 Virtual machine used: custom linux, allmost latest VMMaker, classic (not cog) Class browser used if applicable: OBSystemBrowserAdaptor Steps to reproduce: 1. Load VMMaker with 2. Open the VMMakerTool with: "VMMakerTool openInWorld" 3. Push load config button, you get an error message The problem is that VMMaker tool makes use of StandardFileDialog, which isn't present in Pharo anymore. The method that raises the error is VMMakerTool>>#loadConfig | fileResult file | fileResult := (StandardFileMenu oldFileMenu: FileDirectory default withPattern: '*.config') startUpWithCaption: 'Select VMMaker configuration...'. fileResult ifNotNil: [ file := fileResult directory fullNameFor: fileResult name. [ vmMaker := VMMaker forConfigurationFile: file. vmMaker logger: logger. vmMaker platformDirectory ] on: Error do: [self inform: 'Possible problem with path settings or platform name?']. self updateAllViews] Changing fileResult := (StandardFileMenu oldFileMenu: FileDirectory default withPattern: '*.config') startUpWithCaption: 'Select VMMaker configuration...'. for fileResult := UIManager default chooseFileMatching: nil label: 'Select VMMaker configuration...'. and file := fileResult directory fullNameFor: fileResult name. for file := fileResult Fixes it almost completely. It would be better to use chooseFileMatching: #('*.config') but it didn't work well.

Dec. 17, 2010

[Pharo-project] Fwd: [squeak-dev] Re: Mac App Store opens January 6

by GermÃ¡n Arduino

Sorry I forget to reply all....or so...... ---------- Forwarded message ---------- From: GermÃ¡n Arduino <garduino(a)gmail.com> Date: 2010/12/16 Subject: Re: [squeak-dev] Re: Mac App Store opens January 6 To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> I don't know much about Apple Store nor Apple itself because here in Argentina are so expensives, but seems that a lot of people is selling solutions using this way. Is not a bad idea to push our "products" in all the possible places, and the Eliot suggestion make me think about if we could have some own repo of ready to use squeak/pharo solutions were each author can offer their products (free or not, open or not) as a way of concentrate a portfolio of Smalltalk (aka Pharo/Squeak/other dialects?) solutions. A sort of Smalltalk Store..........I know that is not a big difference against any other software repository (as cnet, tucows, etc) only that here we could join forces in some ways to try to sell/offer our solutions......Could work? Cheers. 2010/12/16 Casey Ransberger <casey.obrien.r(a)gmail.com>: > Boycott from such a small community won't change anything. Absence probably only hurts. It's a rock and a hard place. > > I don't know what to think about it. > > On Dec 16, 2010, at 2:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 2010/12/16 Levente Uzonyi <leves(a)elte.hu>: >>> On Thu, 16 Dec 2010, Jecel Assumpcao Jr. wrote: >>> >>>> Eliot Miranda wrote: >>>>> >>>>> So we should be ready to provide Squeak, Pharo, Etoys et al on the >>>>> Mac App Store on 6/1/2011. Â John, any advice or should I just go ahead >>>>> and submit Cog and Squeak 4.1 trunk and see what happens? Â Other >>>>> cautions suggestions anybody? >>>> >>>> I hope it works out! Since I am not a developer, I don't know if this >>>> leaked version of the "terms of use" is true and current: >>>> >>>> http://www.cultofmac.com/apples-mac-app-store-approval-guidelines/65022 >>>> >>>> These parts might be a problem: >>>> >>>> # 2.16 >>>> # >>>> # Apps that download or install additional code or resources to add >>>> # functionality or change their primary purpose will be rejected >>>> >>>> # 2.21 >>>> # >>>> # Apps may not use update mechanisms outside of the App Store >>>> >>>> And these might or might not be a problem (since the GUI inside the >>>> window is different, but the menus and the window stuff is Mac >>>> compatible): >>>> >>>> # 6.3 >>>> # >>>> # Apps that do not use system provided items, such as buttons and >>>> # icons, correctly and as described in the Apple Macintosh Human >>>> # Interface Guidelines will be rejected >>>> >>>> # 6.4 >>>> # >>>> # Apple and our customers place a high value on simple, refined, >>>> # creative, well thought through interfaces. They take more work but >>>> # are worth it. Apple sets a high bar. If your user interface is complex >>>> # or less than very good it may be rejected >>>> >>>> At least there isn't the code generation limitations of the iOS App >>>> Store. >>> >>> Most web browsers and all virtualization software would be rejected >>> according to these terms. >>> >> >> Yep, Apple bar seems to high for professionally made software. >> Btw, XCode neither having good interface nor easy one. So ban it. :) >> >> It is adequate only for casual software like Pocket Heat >> (http://www.psfk.com/2010/01/iphone-app-overworks-components-to-warm-hands.h…) >> >> I don't understand, why we need to jump into this bandwagon of bigots? >> Will presence on App Store change anything for Squeak? I don't think so. >> >>> >>> Levente >>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Dec. 17, 2010

Re: [Pharo-project] Issue 3445 in pharo: [Repackage] "SUnit" should be well structured

by pharo＠googlecode.com

Comment #2 on issue 3445 by Torsten....(a)astares.de: [Repackage] "SUnit" should be well structured http://code.google.com/p/pharo/issues/detail?id=3445 BTW: three tests in SUnit tests fail in the current #12280 image but this is not due to the changes in the changeset. Stef uncommented the pragma way in TestCase>>expectedFailures: "this implementation is far too slow and block the execution of tests since just for printing a test it scans all the literal of the system. So I reverted the old way of declaring expectedFailures" Looks like the tests are not adopted

Dec. 17, 2010

Re: [Pharo-project] Issue 3445 in pharo: [Repackage] "SUnit" should be well structured

by pharo＠googlecode.com

Updates: Status: Fixed Cc: stephane.ducasse marcus.denker adrian.lienhard Comment #1 on issue 3445 by Torsten....(a)astares.de: [Repackage] "SUnit" should be well structured http://code.google.com/p/pharo/issues/detail?id=3445 In SLICE-Issue-3445-RepackageSUnit-TorstenBergmann.1.mcz After loading the slice one should also evaluate: Smalltalk organization removeSystemCategory: 'SUnit-Events'; removeSystemCategory: 'SUnit-Extensions'; removeSystemCategory: 'SUnit-Kernel'; removeSystemCategory: 'SUnit-Utilities'; removeSystemCategory: 'SUnitGUI'; sortCategories. to remove the obsolete empty categories

Dec. 16, 2010

Re: [Pharo-project] Test Anything Protocol

by Lukas Renggli

> The JUnit XML format is probably far more useful for Pharo. (Though > it's probably not a perfect match either) The TestRunner for Hudson generates the JUnit XML format so that Hudson displays the test results. http://source.lukas-renggli.ch/hudson.html Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 16, 2010

Re: [Pharo-project] Test Anything Protocol

by Stuart Herring

Yes, it is just a way to format test results. It's something from the Perl world, and so most of the tools to do anything useful with it are therefore Perl oriented. It's fairly limited in the amount of information it can convey - just a test number, a status, and an optional description. Not even a title for the tests. The JUnit XML format is probably far more useful for Pharo. (Though it's probably not a perfect match either) Regards, Stuart On Fri, Dec 17, 2010 at 10:12 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Noting that this is described as a protocol, I started to ask what any transport might be, and whether that could be abused??? Â Lots of dead links, so it was not clear whether this involves sockets. Â All I found so far is what looks like a way to format test results, which sounds harmless and potentially helpful. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br [csrabak(a)bol.com.br] > Sent: Thursday, December 16, 2010 3:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Test Anything Protocol > > Folks, > > I'm readying a proposal and came across this, which at first seemed as joke, then a typo or placeholder for some other item in the spec, then I learned it exists: > > http://en.wikipedia.org/wiki/Test_Anything_Protocol > http://testanything.org/ > > Do you think Pharo would profit supporting this? > > -- > Cesar Rabak > > > >

Dec. 16, 2010

[Pharo-project] Issue 3445 in pharo: [Repackage] "SUnit" should be well structured

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de New issue 3445 by Torsten....(a)astares.de: [Repackage] "SUnit" should be well structured http://code.google.com/p/pharo/issues/detail?id=3445 Pharo 1.2beta 12280: I now reorganized the SUnit package: - introduce a SUnit-Core-X category instead of SUnit-X categories - rename SUnitGUI into SUnit-UI category - SUnit-Events becomes SUnit-Core-Announcements since announcements are used - rename ivar result in TestCaseAnnouncement into testResult since this is more consistent with ivar testCase and testSelector - method comments on TestCaseAnnouncement - class comment on TestCaseAnnouncement, TestCaseEnded and TestCaseStarted - a new "SUnit-Core" package => this has to be SAVED in Monticello - a new "SUnit-UI" package => this has to be SAVED in Monticello A help package/tutorial is in preparation ... Attachments: Repackage-SUnit-Reorganize.cs 3.8 KB

Dec. 16, 2010