- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

How about new source code management? In terms of: - better abstraction of source code access in image - create a shared repository (database) , which can be used to browse the history of all source code of Pharo and its predecessor up to Squeak 1.0. We are discussed this idea couple times, and we already having some pieces of puzzle , like Ring. Also, there is already a project made by someone (forgot the name) , who already storing all source code in database and managing it there. -- Best regards, Igor Stasenko.

Nov. 2, 2011

Re: [Pharo-project] Comment Syntax

by Igor Stasenko

On 1 November 2011 18:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Oct 31, 2011 at 2:22 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> The problem is that both #/* and #/* are valid binary operators, so >> they don't work well for comments. >> >> I don't really remember what I proposed a few years ago, although I >> remember that exactly the same proposal was made. What would work is >> to use something like "* and *" (or any other double thing that starts >> with a double quote). Like this the comments could contain double >> quotes. > > Gilad Bracha chose (* & *) for Newspeak. Â These are not valid binary > selectors and * can't follow ( in valid code. Â A good choice. > Hehe. Pascal has the same syntax for comments. >> >> As a short term solution you can also put your comments into single >> quotes. Unused string literals are removed by the compiler. >> >> Lukas >> >> On 31 October 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> > Me too. >> > >> > Sean lukas proposed a syntax for that in the mailing-list a year ago. >> > If you find it please resent it. >> > >> > Stef >> > >> > On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: >> > >> >> Would it be difficult/valuable to create an alternate comment syntax? I >> >> often >> >> find myself wanting to comment a large block itself containing >> >> comments. It >> >> would be nice to have something like C++'s /* */. I feel like this may >> >> have >> >> been brought up before, but couldn't find it searching the lists. >> >> >> >> Sean >> >> >> >> -- >> >> View this message in context: >> >> http://forum.world.st/Comment-Syntax-tp3961451p3961451.html >> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >> > >> > >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Nov. 2, 2011

Re: [Pharo-project] curl?

by Henrik Sperre Johansen

On 02.11.2011 12:31, Sean P. DeNigris wrote: > p := PipeableOSProcess command: 'curl "http://google.com"'. > p output. > > -- > View this message in context: http://forum.world.st/curl-tp3972448p3972641.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > There is also a plugin in (some?) vm's calling curl directly, whose image-side glue is part of the package found at: http://www.squeaksource.com/CurlPlugin.html (Class Curl afaict) Cheers, Henry

Nov. 2, 2011

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

by Norbert Hartl

Am 31.10.2011 um 11:54 schrieb StÃ©phane Ducasse: > 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 I like to add environments so we can have multiple versions in the same image and get rid of default global state. I think you have that already on your mind even with separate object memories. Norbert

Nov. 2, 2011

Re: [Pharo-project] curl?

by Sean P. DeNigris

p := PipeableOSProcess command: 'curl "http://google.com"'. p output. -- View this message in context: http://forum.world.st/curl-tp3972448p3972641.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 2, 2011

[Pharo-project] Small tool to edit bloc code

by Hilaire Fernandes

>From DrGeo I would like the user to edit Smalltalk code in the form of block of code. The user interface I need is maninly to let the user write and compile code. When compiled, DrGeo should get a notification to fetch the code for internal use. What is the best candidate to do that ? Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

Nov. 2, 2011

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

by mail list

So i now have GOODs working semi reliably and as expected on Pharo 1.3 (squeaksource GOODS). I still don't know the root cause but I will work on it. I will just document my problem and how i fixed it in case anyone else runs into the same issue. I will also look at submitting the new test cases to the GOODs on squeaksource The root of the object database in goods is a Dictionary - pointing to various objects including a dictionary of users for seaside. When I would login the user into the seaside session, I would look up object previously from the dictionary of users. I then assume that any changes to the users would be persisted by the db commit command. eg establish xDict:= lookup dictionary of users from Goods session establish connection to database session login user using xDict to check for password etc. change user or subobjects ---> changes to the subojects were not saved here! session db commit --> write it all to the database. session logout -- disconnect db. the problem was that xDict was not linked to Goods anymore or had grown stale. So i could make a change to user and it would save but the sub objects would not be updated. The fix is during the session login user I need to traverse the entire goods db to retrieve the user. Then all commits etc work. eg: establish xDict:= lookup dictionary of users from Goods session establish connection to database session login user ---from xDict tUser:= traverse Goods until you find user save tUser (not the one found from xDict) . change user or subobjects session db commit --> write it all to the database. session logout -- disconnect db. S. On Nov 1, 2011, at 7:41 PM, mail list wrote: > 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. 2, 2011

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

by Schwab,Wilhelm K

[This appears to have bounced - trying again] Ben, That's an interesting idea. I'm sad to say that we would need to think about security in the receipt of data. Just as we now have signed license agreements, we might need to have certificates and keys for publishing test results. Passwords might be sufficient and easier to manage. An existing server would likely end up with a Seaside app that allows mere mortals to request a signing or a password. After moderator approval (also part of the app), the tester would be given or emailed to retrieve the credentials needed to post test results. BTW, none of that makes it a bad idea or "too hard." I just fear that we would regret having a wide-open way to trash our test results data. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] Sent: Tuesday, November 01, 2011 10:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :) 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. 2, 2011

Re: [Pharo-project] Issue tracker states

by Nicolas Cellier

2011/10/28 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > We started to improve the states defined in the tracker... this now has: > > > FixToInclude Â Â Â Â = QA has verified that the fix worked, needs to be integrated > FixReviewNeeded Â Â Â = Code is there, but a review is needed > NoSourcesAvailable Â = fix proposed, but machine readable code missing > Workneeded Â Â Â Â Â = Next action is defined but not yet completed > NextActionNeeded = What is the next action? > Accepted Â Â Â Â Â Â = Problem reproduced / Need acknowledged > New Â Â Â Â Â Â Â Â Â = Nobody looked at this yet > OnHold Â Â Â Â Â Â Â = We will come back later to this issue, no action possible now > > > The issue tracker by default sorts the items to show the ones on top that have progressed > the most: > > Â Â Â Â http://code.google.com/p/pharo/issues/list > > > The idea is that the "FixToInclude" status should be integrated very quickly (within a day), > later maybe even automatically. > > Â Â Â Â Marcus > I think this is a good pragmatic list. One thing I wonder is whether we can mark our own fix as "FixToInclude" In theory, we should not because we are bypassing a peer review. We should not lower quality insurance. But practically it depends on two things: - the level of work supported by integrators - whether you have enough peer reviewers and how easy or involving is such a review (the reviewer throughput) I suppose Marcus would like to be replaced by an automaton and reduce integrator support. It shall then be mandatory to tag our own fixes as "FixReviewNeeded". But if ever you don't have enough reviewer throughput, then the "FixReviewNeeded" will start accumulating in the tracker. If we fail to increase the throughput (with an army of reviewers or some facilitating tools) then Marcus (and Stef) burden won't lighten. I repeat once again, but I prefer the squeak-trunk smooth process were the changes are published in a mailing list. They CAN BE reviewed more easily, and I'm sure they ARE reviewed more efficiently than in Pharo process (I mean by many more eyes). As a committer, I can then publish directly in trunk without the inbox stage. It's very like a direct "FixToInclude" But that does not mean there will be no review. But maybe I'm tainted ;) Nicolas > -- > Marcus Denker -- http://marcusdenker.de > > >

Nov. 1, 2011

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

by StÃ©phane Ducasse

Ben what we want is the following - we have different distributions for pharo1.0, 1.2.14 and automatically we run tests and rules checking systematically - when a package has too many flagged items -> goes into the inbox of the distributions - Package should embed their false positive to SmallLint so that we can run them for real. - when people propose fixes we want the system to automatically load and test. This is what Ulysse the Monkey is already doing and this is great >> >> >> 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. Yes this is a neat idea :) To contribute you can already load a fixe and tell us if the tests are ok. Or just if the fix is loading :). Stef > > cheers, Ben >

Nov. 1, 2011