November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Goods Test Runner Pharo 1.3 Issues

by Carlo

Hi On 01 Nov 2011, at 1:41 PM, mail list wrote: >>>> self deny: (set includes: 1@1). -->fails >>>> >>>> set = (2@2,1@1) >>>> so it seems to think that x and 1@1 are the same. Which to me seems correct but I may be misunderstanding the testcase. KKIdentitySet should not think x and 1@1 are the same as they are 2 different instances. I would think that the implementation of Set has changed (@see scanFor: method, specifically the SetElement wrapper around nil). My guess would be that Set storage has changed slightly. Maybe try changing KKIdentitySet to be: KKIdentitySet>>scanFor: anObject "Scan the key array for the first slot containing either a nil (indicating an empty slot) or an element that matches anObject. Answer the index of that slot or raise an error if no slot is found. This method will be overridden in various subclasses that have different interpretations for matching elements." | index start | index := start := anObject hash \\ array size + 1. [ | element | ((element := array at: index) == nil or: [ element enclosedSetElement == anObject ]) ifTrue: [ ^index ]. (index := index \\ array size + 1) = start ] whileFalse. self errorNoFreeSpace Cheers Carlo

Nov. 1, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Ben Coman

StÃ©phane Ducasse wrote: > Hi guys > > we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your > feedback/suggestions. Note this is typically the way we want to work with the consortium in the future: > Build an initial roadmap and refine it based on the input of the community. > > - A website for the consortium registration (esteban is expert on that). > - This is important for INRIA and for the visibility of the consortium. We should get new members :) > - Integration with SmalltalkHub > > - Working on fixing bugs! > - Debugger fixes > - Continuous bug fixing. > > - Improving release process: faster, more people involved, simpler. > - Working on metacello repositories for each distributions (everything is there but missing last bits) > - Metacello tools > - Automatic release validations > - Automatic validation of fixes > > Now the free items with probably igor involvement > - Multiwindowing support > - Fully working multithreaded FFI with ***Documentation*** > - Filesystem fix and integration > - Integration of OPAL > - RPackage integration > > Igor related > - Ephemerons > - Object format > - VM branding > - Use of new canvas > - Event cleaning > > So we are waiting for your suggestions. > > > Stef Just a very general view... that in paid positions, you don't always get to work on the sexy stuff. One of the downsides of open-source is the chance that developers might focus on the fun 80% of their ideas before moving on to the next-big-thing(c). It is easy to develop something to be used by oneself. It is much harder to develop something to be used by others - particularly in providing a sense of how to use the system by way of well documented examples. There is a lot of drudge work to make a system successful and stable. Knowing there is a paid position that might deal with part of that work definitely increases confidence in the system. One new idea. I really like the way Wordpress manages their thousands of Plugins with the "Compatability" sidebox where you choose a Wordpress version and a Plugin version and it indicates how compatible they are based on user votes. However rather than (or as well as) user voting I think that TestRunner results from applications could be used - and also presented in a tabulated form rather than just pull-down choices showing a single sample point. A continuous integration and testing system would take combinatorial approach to testing registered Metacello configurations - which might take a lot of processing power and leads to... A second idea for a distributed continuous integration test system. I would personally be happy to contribute cpu cycles to running a Pharo test system on top of a virtual machine, which from a central server obtains a random set of Metacello configurations to install, runs tests and reports results to the central server. Apart from gaining the processing power to possibly test all permutations of configurations, it also provides a way for new community members to feel like they are contributing, which preceeds them getting more involved. As an example in line with my first comment, perhaps the initial proof of concept would be done as a research project, and then the paid professional would polish off the stability and usability of it. cheers, Ben

Nov. 1, 2011

Re: [Pharo-project] Someone bought Smalltalk?

by Tudor Girba

Oh, my God! I will have to delete every piece of Smalltalk evidence! Ah, but I guess it will be a while until they get to Switzerland. I just hope they do not catch me in Argentina. Doru On 1 Nov 2011, at 11:12, Damien Cassou wrote: > I just received this email: > > > ---------- Forwarded message ---------- > > I heard some rumors about Smalltalk. Apparently, an american > enterprise bought Smalltalk and is trying to make money by sueing > users. Therefore, they changed the licence agreements (and maybe other > stuff). In my company we have a strict interdiction to use Smalltalk. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > -- www.tudorgirba.com "Some battles are better lost than fought."

Nov. 1, 2011

[Pharo-project] Custom-Global Exception handlers

by Guillermo Polito

Hi! Am I wrong If I say that there is no way to set a custom event handler per * application* in pharo? Let's say I want a different error handling approach for OmniBrowser, the TestRunner and Pharo in general. More over, there is no application idea (or I didn't find it). I think it is healthy to have such handlers to have a single point of error handling... Ideas? Guille

Nov. 1, 2011

Re: [Pharo-project] Comment Syntax

by Schwab,Wilhelm K

Actually, I think the second point is arguable, for reasons I gave and that you snipped. But they *would* indeed say "just delete it." ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Monday, October 31, 2011 8:57 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Comment Syntax Schwab,Wilhelm K wrote: > > ...It would be nice if it were portable to other Smalltalks, but it would > be useful. > ... > XP advocates would tell us that we don't need the code and to just delete > it. > The second point is valid, but only applies to a subset of comments. For example, in my case the thing that needs to be commented is Applescript code that provides context for the method. It is part of the documentation, and must contain double quotes to be valid Applescript. -- View this message in context: http://forum.world.st/Comment-Syntax-tp3961451p3962192.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 1, 2011

Re: [Pharo-project] [ANN 1.3] One-Click #13315

by Marcus Denker

>>> >>> For your records, I did the following... >>> a. extracted Pharo-1.3-13315-OneClick.zip >>> b. extracted Pharo-1.4-14210.zip into the Resource folder, >>> c. renamed pharo.exe & pharo.ini to pharo14.exe & pharo14.ini as described in my previous report >>> d. modified pharo14.ini with ImageFile=Contents\Resources\pharo-1.4.image >>> e. ran pharo14.exe, opened TestRunner and clicked <Run Selected>, then later clicked <Run Selected> a second time. >>> f. Quit >>> g. modified pharo14.ini with ImageFile=Contents\Resources\pharo.image >>> h. ran pharo14.exe, opened TestRunner and clicked <Run Selected> >>> i. Quit >>> >> What would be interesting: >> >> -> Does it happen Core 1.3? >> -> Does it happen with other VMs? >> >> Marcus > Happy to try, but I don't know where to get Core or other VMs. Hello, The page http://www.pharo-project.org/pharo-download/release-1-3 has the links to: 1) Pharo VM (Cog build by build system, same as in one-click): http://gforge.inria.fr/frs/download.php/29045/CogVM-Win-13307.zip 2) The core image: http://gforge.inria.fr/frs/download.php/29166/PharoCore-1.3-13315.zip Then, Eliot has slighly newer VMs (but with some other things not included) http://www.mirandabanda.org/files/Cog/VM/VM.r2502/ -- Marcus Denker -- http://marcusdenker.de

Nov. 1, 2011

Re: [Pharo-project] Goods Test Runner Pharo 1.3 Issues

by mail list

Let me come up with a proper failing testcase and I will update the list. I was hoping for some general insight as I assumed it was just my misuse of the packages. S. On Nov 1, 2011, at 5:34 PM, StÃ©phane Ducasse wrote: > let us know > because core collection should be really robust. > > Stef > > > On Nov 1, 2011, at 9:52 AM, mail list wrote: > >> I will check. Thank you. >> >> The problem is definitely something related to 'reachability'. eg I can save the top level objects but the second level objects (eg instance varaibles of the top level) I can not get to save. >> >> S. >> On Nov 1, 2011, at 2:59 PM, Lukas Renggli wrote: >> >>> Not sure if this is related, but the collection hierarchy got refactored in Pharo at some point to include HashedCollection (AFAIR) as superclass. Maybe this broke something with the persistence of Sets and Dictionaries? >>> >>> Lukas >>> >>> On Tuesday, 1 November 2011, mail list <mail.list(a)ficonab.com> wrote: >>>> I am trying to deploy a Pharo 1.3 image using Goods and running into some basic issues where my objects are not persisted by reachability. >>>> eg I put dictionary x at root under a key 'test' >>>> eg db root at: 'test' put x. >>>> db commit. >>>> Then at x i updated instance variable and add something to its dictionary and committ >>>> eg x intancevariable y at: 'key' put 'zzzz' >>>> db commit >>>> >>>> looking at the root x does not get updated with y. >>>> >>>> I have the majority of the test cases pasing except for testIdentitySet and testFlushAllRemovesAllUnreferenced. >>>> >>>> In testIdentitySet the following failure >>>> | set x y y2 | >>>> set := KKIdentitySet database: dbOne. >>>> x := 1@1. >>>> y := 2@2. >>>> set add: x. >>>> set add: y. >>>> self assert: (set includes: x). >>>> self assert: (set includes: y). >>>> self deny: (set includes: 1@1). -->fails >>>> >>>> set = (2@2,1@1) >>>> so it seems to think that x and 1@1 are the same. Which to me seems correct but I may be misunderstanding the testcase. >>>> >>>> Any thoughts or pointers to update my mistakes in using Goods db would be helpful. >>>> >>>> S. >>>> On Oct 31, 2011, at 5:49 PM, Marcus Denker wrote: >>>> >>>>> 13320 >>>>> ----- >>>>> >>>>> Issue 4945: Weird Settings filtering >>>>> http://code.google.com/p/pharo/issues/detail?id=4945 >>>>> >>>>> -- >>>>> Marcus Denker -- http://marcusdenker.de >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >> > >

Nov. 1, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Mariano Martinez Peck

On Tue, Nov 1, 2011 at 4:25 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Oct 31, 2011, at 9:56 PM, Mariano Martinez Peck wrote: > > - Once again... I would LOVE to have a really working-out-of-the-box > multithreaded FFI with callbacks. > This is a MUST if Pharo wants to be business friendly. > > - Unify the VMs. Have only ONE place where a single pharo user can go and > pickup a VM. Have ANOTHER place for those bleeding edge or experiment VMs. > This means merging gforge, jenkins, pharo website, pharo one click, etc. > In addition, we need a way to IDENTIFY a VM. So that when someone reports > a bug, we can exactly know which VM to reproduce it. > > - Integrate Nautilus with RB. Nobody (ok, most of us) cannot work without > RB integration. Ok, integrations could live without that, but they > INTEGRATE. If you are DEVELOPING you cannot develop without RB. If nobody > will make OB to work in 1.4, then someone needs to integrate Nautilus with > RB, otherwise people will stick with 1.3 and never change. > > > I am on it, but it's long, i have to understand fully how it works, and > since I never really used it (I am still a newbie ^^) it's not so easy. > Moreover I have to go through OB code which is still obscure to me. > > that's why I say "someone" and not Ben :) > But it progresses step by step :) > > > Sure, and continue like that! > Ben > > - Make development really tools work in Pharo 1.4: OCompletion, Shout > > - Continue pushing Coral, Zinc, Ocean, DBXTalk, Fuel, Nautilus, etc. > > - Maintain issue tracker: let's give Marcus a rest. This means tagging > issues, close them, validate, etc etc etc. > > Cheers > > On Mon, Oct 31, 2011 at 8:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> I can't take credit for thinking of the bridge, I was simply >> acknowledging it and the breadth of its audience as part of my shameless >> attempt to direct effort toward another feature that would get a lot of use >> :) >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. >> DeNigris [sean(a)clipperadams.com] >> Sent: Monday, October 31, 2011 3:22 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo >> Consortium Engineer :) >> >> Schwab,Wilhelm K wrote: >> > >> > The object-c bridge is probably a big deal to the Mac users among us, >> > right? >> >> Yes! Thank you for the reminder, I'd temporarily given up and forgotten >> about this. A stable, well-documented ObjC bridge would be /huge/. My >> inability to effectively use it was one of the key drivers in my delving >> into debugging the VM. Like FFI, I think documentation will be extremely >> important here. >> >> Sean >> >> -- >> View this message in context: >> http://forum.world.st/Brainstorming-on-the-roadmap-for-first-Pharo-Consorti… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Nov. 1, 2011

[Pharo-project] Someone bought Smalltalk?

by Damien Cassou

I just received this email: ---------- Forwarded message ---------- I heard some rumors about Smalltalk. Apparently, an american enterprise bought Smalltalk and is trying to make money by sueing users. Therefore, they changed the licence agreements (and maybe other stuff). In my company we have a strict interdiction to use Smalltalk. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 1, 2011

Re: [Pharo-project] Goods Test Runner Pharo 1.3 Issues

by Mariano Martinez Peck

On Tue, Nov 1, 2011 at 4:18 AM, mail list <mail.list(a)ficonab.com> wrote: > I am trying to deploy a Pharo 1.3 image using Goods and running into some > basic issues where my objects are not persisted by reachability. > eg I put dictionary x at root under a key 'test' > eg db root at: 'test' put x. > db commit. > Then at x i updated instance variable and add something to its dictionary > and committ > eg x intancevariable y at: 'key' put 'zzzz' > db commit > > looking at the root x does not get updated with y. > > I have the majority of the test cases pasing except for testIdentitySet > and testFlushAllRemovesAllUnreferenced. > > In testIdentitySet the following failure > | set x y y2 | > set := KKIdentitySet database: dbOne. > x := 1@1. > y := 2@2. > set add: x. > set add: y. > self assert: (set includes: x). > self assert: (set includes: y). > self deny: (set includes: 1@1). -->fails > It looks like a bug in KKIdentitySet. Because if you use a regular IdentitySet instead, of course the test works. Maybe GOODS is outdated.... > > set = (2@2,1@1) > so it seems to think that x and 1@1 are the same. They are equal but not the same. How can we load GOODS? in which pharo image? and give us a test we can reproduce. > Which to me seems correct but I may be misunderstanding the testcase. > > Any thoughts or pointers to update my mistakes in using Goods db would be > helpful. > > S. > On Oct 31, 2011, at 5:49 PM, Marcus Denker wrote: > > > 13320 > > ----- > > > > Issue 4945: Weird Settings filtering > > http://code.google.com/p/pharo/issues/detail?id=4945 > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 1, 2011