- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Managing Pharo external packages with Metacello, please read!

by StÃ©phane Ducasse

I understand nicolas. Now my agenda is more than full. and the proposal is here. Simple ========================================================== One repo per version Pharo1.0, Pharo11 ... MetacelloRepository containing **published** configurationOfXXX -> all the dependent packages are copied locally + configuration ready to load using load. A project contain its single/or several configurationOfMyProject with the complete history people commit the config to their repository and if they want they **publish** from their repository to the version repository a version. This version is frozen -> all the dependent packages are copied locally + configuration ready to load using load. For Pharo core or pharo packages that we maintain we want to maintain it as a project. with its own repository and packages. We can use automatic build server to validate the status or migration between different repositories ========================================================== Stef On May 17, 2010, at 11:00 PM, Nicolas Cellier wrote: > The meaning of my message was don't do it for squeak, but do it for yourself. > I don't doubt the mailing list is a mine of information, but even in > the best mine you need to dig a lot before extracting the gold > nuggets. > Of course, I've got no right to control your agenda, who am I ? > You can consider the subject close, and I won't find your attitude > shocking at all. > But next time, consider writing a rationale for your own, it will > increase quality of Pharo decision process. > > Best regards > > Nicolas > > 2010/5/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> nicolas >> >> all the information is in the metacello mailing-list and we already posted many mails on that topics in this mailing list. >> I'm sorry but I do not have the time to repeat again what we said. Now since I'm in a really good mood >> in a nutshell >> >> one repo per version Pharo1.0, Pharo11 ... MetacelloRepository >> containing configurationOfXXX frozen = all the dependent packages are copied locally + configuration ready to load using load. >> >> a project >> contain its single/or whatever configurationOfMyProject >> people publish the config to their repository and if they want they push from their repository to the version repository >> a version that they freeze (may be using tags) >> >> For Pharo core or pharo packages that we maintain we want to maintain it as a project. >> with its own repository and packages. >> >> Then we have a server that load configuration and barks if something wrong happen. And may be we kick out >> the configurationofXXX from MetacelloRepositories >> >>> Steph, >>> I understand how boring it may seem: >>> - you already discussed the subject over and over >>> - you already took decisions >>> and now we come later with new proposals, and ask you to reconsider >>> the work again... >> >> more than that. :) >> It looks like if we did not talk or think about what we are doing. >> >> >>> As for the Preferences/Settings, Pharo choices are probably very weel thought. >>> >>> However, every solution will come with trade offs, and it would be >>> good to have a rationale justifying the choices you made, and perhaps >>> more importantly justifying why you did abandon some solutions, >>> because some questions might be repeated in Pharo 1.2, 1.3, 2.0 ... >>> and find different answers in different context. Note that Squeak >>> evolutions might have influence on Pharo too, and it's part of the >>> context... >>> >>> I strongly encourage you to establish your rationale on Pharo grounds >>> - independently of Andreas proposals, put it on the Pharo wiki and let >>> us know the URL. >>> >>> You also know that Squeak goals are not exactly those of Pharo w.r.t. >>> backward compatibility, so Squeak can't just blindly replicate Pharo >>> solutions without a rationale. >>> >>> The merit of Andreas proposal is to try and establish such a >>> rationale. Without it, we're bound to repeat discussions again and >>> again, >> >> So to fix the problem consider that as our proposal. >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] condensing changes file

by StÃ©phane Ducasse

I will do a condense changes in the beta like that it will clean up the problems. Stef On May 18, 2010, at 12:33 AM, Mariano Martinez Peck wrote: > Hi Laurent: I suffer that too. Actually, much more than everybody as I build the dev images. > > Stef: condeseChanges is automatically called after installing ConfiguratioOfPharo as the default grouo loads the DEV group which includes all the dev tools an ImageForDevelopers. This, does some cleanUps included condeseChanges. In the past, there was no poblem to do it even if it was not strictly needed. Now, it's different. > > So, my proposal is: remove the condenseChanges from the cleanUps of ImageForDevelopers, and I add it to my post bash scripts when building the dev image. > > Do you agree? > > Cheers > > Mariano > > 2010/5/17 laurent laffont <laurent.laffont(a)gmail.com> > It has just finished :) > > Laurent > > > > On Mon, May 17, 2010 at 10:40 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > I'm starting to wonder if this condensing will ever finish ! > > Laurent > > > On Mon, May 17, 2010 at 10:37 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > don't bother :) > > It is taking long but fully working. We will condense it for may be beta or rc depending on the size. > > Stef > > > > Hi, > > > > I've just started playing with ConfigurationOfPharo 1.1 and I'm currently experiencing the looooong "condensing changes file". I have currently troubles trying to follow all the traffic of this mailing-list :) but is there some work to make it far less longer ? or optional ? > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Michael Roberts

I am surprised too. would it not be safer to just apply the same reversion of the code so that 1.1 is the same as 1.0? Then when someone has the time to do a full review, a "new" network can be applied to the start of a dev cycle, with some form of integration tests. cheers, Mike On Tue, May 18, 2010 at 6:31 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Alex, > > One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. > > If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). > > Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. > > Hope you have a productive weekend! > > Cheers, > Adrian > > On May 18, 2010, at 02:49 , Alexandre Bergel wrote: > >> Mariano, Stef, Adrian, >> >> I would like to focus the Pharo sprint this week end on helping Pharo 1.1. >> In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? >> >> Cheers, >> Alexandre >> >> >> On 16 May 2010, at 18:26, Alexandre Bergel wrote: >> >>>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >>> >>> >>> I will go over some this week. >>> >>> Alexandre >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 18, 2010

Re: [Pharo-project] Decoupling Shout and Styler

by Fernando olivero

Lukas, i've looked at the petit parser info in your blog but couldn't find an example of a Shout-like parser and styler. Could you please point to one example? And the RB class that's used for styling is? Thanks, Fernando On May 18, 2010, at 12:48 AM, Mariano Martinez Peck wrote: > I agree, but in such case let me know so that I can update the metacello conf ;) > > > On Mon, May 17, 2010 at 5:49 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Yes, that makes sende. > > Another possibility would be to use the RB or PetitParser (this is > what I do in Helvetia) parser instead. > > Lukas > > On Monday, May 17, 2010, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > can be a good idea. > > > > Stef > > > > On May 17, 2010, at 5:21 PM, Fernando olivero wrote: > > > >> I would like to decouple the Styler Object ( For example SHTextStyler) from the Shout packages. > >> > >> Since Shout purpose it to add: 'Syntax Highlighting that updates after each key stroke so that the highlighting remains correct during the editing of a method'. > >> > >> I think it would be beneficial to style any piece of text, independently from the editing of a method. > >> > >> For example, when working on the NewTextMorph i do not need any functionality of the TextMorphForShout or TextMorphForShoutEditor classes, but only the Styler related classes. And in its current state, these two are coupled in the same package. > >> > >> I propose Shout could be spitted into 2 packages, that better reflect the classes intentions. > >> > >> 1. Code Styler: which would include Shout-Parsing, and Shout-Styling. > >> > >> 2. TextMorphShout: Shout-TextSupport, Shout-Windows. > >> > >> What do you think? > >> > >> Fernando > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <ATT00001..txt>

May 18, 2010

Re: [Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by Carla F. Griggio

Oh, I forgot,* Compiler>>compiledMethodFor: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag* has no senders. Was that replaced by* Compiler>>evaluate: textOrStream in: aContext to: receiver notifying: aRequestor ifFail: failBlock logged: logFlag *? On Tue, May 18, 2010 at 3:52 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Hi everybody! > > Well, maybe you are already aware of this... maybe not. I tried to find an > issue about this and unless I didn't think of the right keywords, it's not > there. > > I was debugging a template method and sudenly I found myself spending ours > trying to find out why I got different results when printing the result of a > message sent to super and when steping into that message and printing the > (same) result there. > > Imagine this simple situation (I attatch the complete code and some tests > so you can reproduce this): > > AverageTotalization inherits from Totalization. > WeightedAverageTotalization inherits from AverageTotalization. > > Totalization>>total > ^self summatory > > AverageTotalization>>total > ^*(**super total)* / self denominator > > AverageTotalization>> denominator > ^values size > > WeightedAverageTotalization>> denominator > "Weights is a dictionary" > ^self weights values sum > > > If I debug aWeightedAverateTotalization total and try to print *super > total* in the debugger ParagraphEditor, I'll get this result: > > (self summatory / self denominator) > > instead of just: > > self summatory > > This only happens when I print or inspect or other do-its in the debugger > window. The method lookup works OK when just evaluating the code (the tests > I made are green). > > I think that when you print or inspect (etc) *super total*, the evaluation > context takes WeightedAverageTotalization class instead of > AverageTotalization, so when total is sent to super under that context, the > code is looked up on AverageTotalization instead of Totalization. > Could that be possible? Am I thinking right? > > I spent a *while* chasing this bug, and I found a solution, but I don't > know if it's OK or if it's the best. It's simple and it seems to work. I > tested it in the last PharoCore1.1 unstable image. > > I attach some code to reproduce the error (you'll get a halt when you run > the test, read the comments, the problem is clear when you run the weighted > average test), and the code that fixes this. > > If you confirm that this was not a known issue, I'll register it on the > issue tracker with both these attachments. > > If it was a known issue... well, I learned :) (I think XD) > > Cheers! > > Carla. >

May 18, 2010

[Pharo-project] Bug? ParagraphEditor do-its are not following the expected method lookup

by Carla F. Griggio

Hi everybody! Well, maybe you are already aware of this... maybe not. I tried to find an issue about this and unless I didn't think of the right keywords, it's not there. I was debugging a template method and sudenly I found myself spending ours trying to find out why I got different results when printing the result of a message sent to super and when steping into that message and printing the (same) result there. Imagine this simple situation (I attatch the complete code and some tests so you can reproduce this): AverageTotalization inherits from Totalization. WeightedAverageTotalization inherits from AverageTotalization. Totalization>>total ^self summatory AverageTotalization>>total ^*(**super total)* / self denominator AverageTotalization>> denominator ^values size WeightedAverageTotalization>> denominator "Weights is a dictionary" ^self weights values sum If I debug aWeightedAverateTotalization total and try to print *super total * in the debugger ParagraphEditor, I'll get this result: (self summatory / self denominator) instead of just: self summatory This only happens when I print or inspect or other do-its in the debugger window. The method lookup works OK when just evaluating the code (the tests I made are green). I think that when you print or inspect (etc) *super total*, the evaluation context takes WeightedAverageTotalization class instead of AverageTotalization, so when total is sent to super under that context, the code is looked up on AverageTotalization instead of Totalization. Could that be possible? Am I thinking right? I spent a *while* chasing this bug, and I found a solution, but I don't know if it's OK or if it's the best. It's simple and it seems to work. I tested it in the last PharoCore1.1 unstable image. I attach some code to reproduce the error (you'll get a halt when you run the test, read the comments, the problem is clear when you run the weighted average test), and the code that fixes this. If you confirm that this was not a known issue, I'll register it on the issue tracker with both these attachments. If it was a known issue... well, I learned :) (I think XD) Cheers! Carla.

May 18, 2010

Re: [Pharo-project] I really miss a binary bitOr: selector for integers

by Andreas Raab

On 5/17/2010 6:26 PM, Igor Stasenko wrote: > Hello, > C world using bitor-s extensively for passing various flags and options. > > And porting the code looks really awful with #bitOr: , because it > requires braces when you combining more than 2 flags. > > Can we , please , please, include #| as an alternative selector for > bitor-ing integers into a kernel? +1. But then we also need #& and something like #not. So that I can simply write: setFlag: aBool flags := aBool ifTrue:[flags | FlagConstant] ifFalse:[flags & FlagConstant not]. > Btw, Alien alredy adds it as extension. But i would really like to get > it into the core, so any other may use it. > > Meanwhile, i defined own awfull extension selector - #++ Eeeeeek! :-) Cheers, - Andreas

May 18, 2010

Re: [Pharo-project] Community Supported Packages

by Andreas Raab

Hi Torsten - Thanks for the thoughtful response. It'll take a little to respond to the points individually, so apologies for the length of the response. First of all, nothing is "decided" yet. I've made a proposal, people appear to like it, so we can start a phase of experimentation. If the experimentation works out, we can add this for 4.2 and if not, we'll see what's lacking and how to fix it. On 5/17/2010 5:14 AM, Torsten Bergmann wrote: > I tried to follow the discussion on both lists regarding supported packages and how/where to manage them by using Metacello. I can not give complete feedback > since I go with GÃ¶ran here who said "I need to read your thoughts once more > before giving proper feedback." and I think we all should take the time to > think about all the implications the different approaches have. Absolutely. One thing that took me by surprise is the response in the Pharo world. Given that this is a proposal for Squeak I thought that the response would at most be "see, we told you so". Instead it appears to be ... well, I'm actually not exactly sure. Seems like a mixture of feeling threatened and NIH. If you look at it objectively, my proposal is extremely similar to what Pharo uses, and I've explicitly mentioned that it was inspired by Pharo's use of MetacelloRepository. Outside of the community packages aspect, pretty much the only differences are: 1) Whether to use one configuration per package or not. 2) Whether configurations are preloaded in the image. That's about it. I really fail to see what the big hiatus is about. If you do decide to answer the above in a particular way (namely the way I've proposed it) you also gain a few additional advantages such as knowing that the code you have is trustworthy and such as having an easier time building a UI. But that's about it. > With this discussion we set up the base for the future of package maintenance > but also for collaboration amongst the communities, how images are built, ...! > > I'm sure we all want to blur the line between in and out of the (whatever) image > and share/reuse as many code/packages as possible within the broader community > (Squeak, Pharo, Cuis, Gemstone, ...). So: > > Goal Nr. 1 is: if it is not in my environment then just load it. > Goal Nr. 2 is: if it is loaded it should work in my environment since it brings > in anything it needs to work From my perspective that definition of the problem is a bit superficial. There's a reason why I called this post "community supported packages" and not just "package management" because we also need to work out a way to support packages in the long term. I agree that the above two goals are intrinsic part of what I'm talking about but there are other aspects to it which are just as important. We are a small community so we do need to set an artificial boundary on what we support. If we support "everything" we end up supporting nothing, which is what we see in Universes and Squeakmap. So an inseparable part of my proposal is an explicit community contract; there are certain requirements and benefits that we aim to gain by coordinating on the package maintenance. I *want* to separate projects like Omnibrowser and HelpSysstem from random garbage so commonly found on Squeakmap and Universes. It's because the people around it care and it's because of that that I want to have an explicit contract that basically says "you care, we care". No it's not free to become a community supported package, but it's *because* it's not free that it's also valuable. (there are several other aspects to it which I just deleted because otherwise this post will get positively exhaustive and really all I'm saying is that for me there's a bit more to it then the individual's desire to install some code ;-) > Currently the discussion and actions seem to focus on where to put the > configurations (into the image vs. in repositories per version). I'm in favour > of the latter since that is easier to handle and share between platforms > while having them in the image would limit people who work on various > platforms, it would not scale and eat more resources for maintenance. Nothing prevents us from doing just that if we find it preferable. I agree that updating is a little easier if you do it externally but then again, I feel this is part of what the community contract implies. Is it really asked too much to post an update to the inbox if you make a new version? On the other hand, having it in-image makes it easier to build a UI and it also provides implicit structuring simply because we can utilize system categories to provide a first level of structure. So under "Configurations-Network" you would find the WebClient config next to other network related configs. Simple and straightforward. > My fear is also that if you have the configurations within the image then > we all will end up with something similar to the unmaintained SqueakMap > registrations. With external repos we can also feed CI-Tools (Hudson build > server, ...) The issues in both Squeakmap and Universes originated from people using them for many different versions. The same appears to be happening in Pharo's Metacello repository. There are some configs that work only in Pharo 1.0 and some that work only in 1.1. That is the root cause for the problems both Squeakmap and Universes share. And as Squeakmap has proven, the other problem is that not all software is created equally. At some point you need to make a decision of what you consider "supported" (and consequently try to make work for the release) and what you consider "third party" and none of your business. There are of course other ways of dealing with that from what I am proposing. Having it in-image however, makes the status very explicit. There's no doubt about what is considered supported and when one achieves (or loses) that status. If it's in, it's supported, if it's out, it's not. Plus it uses our community processes for development so if there's an update for a package you'll find out simply by virtue of seeing the commit message. > But thats not the main question. Even if Squeak decides to have the configurations > "in-image" and Pharo decides for external configs one can mix them: > An in-image ConfigurationOfMyApp just loads the ConfigurationOfMyAppExternal > where the last one is maintained in an external repo and the internal > config is for convenience to just load it. Yes, that would be another fine option. > Lets think about the implications for anything above the virtual machine: > [... snip ...] > > If Squeak jumps on the Metacello config bandwagon it may also have to think about > jumping onto the "small core + external packages" model. At least to me > this would be the next logical step. Heh, where have you been over the last year? :-) If there's one thing where there has been absolute agreement on it's just that. But it's a matter of when to do it and how to do it - we don't just want to create bit rot, we want to keep supporting the packages we choose to support. And that requires some agreement on how the larger picture of "supporting" packages looks like. And that's where we get into community supported packages and the reason why it's not "just" a Metacello issue. > This leads to several questions: > > - could this small core could be the same for all of us - especially since > we currently fix stuff in Cuis, Squeak and Pharo mostly the same way Interesting thought. Is that perhaps the root of feeling threatened? In any case, it's an interesting question that deserves some thought. I'd say there are three questions to answer: * Does such a process requires some (or all?) participants to give up their original identity? * What would the development process look like? * How would a conflict resolution process look like? (and by conflicts I don't mean package conflicts :-) If anyone is seriously thinking about this (I'm not) you might want to approach it by staking out an area that's part of all the images and that has relatively few changes, like the Graphics package. I'd be curious what people come with about how to address the resulting questions. Cheers, - Andreas

May 18, 2010

Re: [Pharo-project] [Bug] Refactoring does not respect formatting

by Lukas Renggli

The thing is that the 'extract method' refactoring completely changes the structure of the code. It is hard to keep the formatting in this case without risking completely messed up source. I suggest you try RBConfigurable formatter, for me it provides quite good results. Lukas On Tuesday, May 18, 2010, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > http://code.google.com/p/pharo/issues/detail?id=2439 > > We are currently working on version 1.1, so please verify your issue with > the latest 1.1 Unstable version Â before reporting it - we improved a lot > the system. > > Pharo image: Pharo-core > Pharo core version: 1.1 #11364 > Virtual machine used: Squeak 4.2.4beta1U (mac) > Class browser used (if applicable): Â OBSystemBrowserAdaptor > > Steps to reproduce: > 1. Start with clean image > 2. Install OB with: > > 3. Select line "(MCPackage named: 'ProjectNotNamedForRepo') unload." from > following method: > Â Â testFromSqueakSourse > Â Â Â Â "" > > Â Â Â Â ImageSetup new > Â Â Â Â Â Â Â Â installProject: 'ProjectNotNamedForRepo' > Â Â Â Â Â Â Â Â fromRepository: 'ProjectNamedForRepo'. > > Â Â Â Â (MCPackage named: 'ProjectNotNamedForRepo') unload. > Â Â Â Â SystemOrganization removeCategory: 'ProjectNotNamedForRepo'. > 4. Extract method via refactor source->extract method > 5. Result does not respect whitespace and formatting: > Â testFromSqueakSourse > Â Â Â Â "" > > Â Â Â Â ImageSetup new installProject: 'ProjectNotNamedForRepo' fromRepository: > 'ProjectNamedForRepo'. > Â Â Â Â self projectShouldBeInstalled. > Â Â Â Â self shouldnt: [ Smalltalk at: #ClassInProjectNotNamedForRepo ] raise: > Error. > Â Â Â Â self extracted. > Â Â Â Â SystemOrganization removeCategory: 'ProjectNotNamedForRepo' > > Issue was discussed in 9/09 at: > http://forum.world.st/Is-there-a-way-to-use-rename- > refactor-while-preserving-whitespace-formatting-in-refactored-methods- > td1302148.html#a1302148 > > Ideas were: > * write your own formatter that formats as you like > * implement Gwenael's changes to the RBParser and AST, which preserve code > formatting > * use tools implemented in OB-Regex > > Sean > -- > View this message in context: http://forum.world.st/Bug-Refactoring-does-not-respect-formatting-tp2220567… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

May 18, 2010

Re: [Pharo-project] So...we freeze 1.1 ? (next steps?)

by Adrian Lienhard

Hi Alex, One thing that bothers me is the network code. Although nobody reported problems I cannot believe that it suddenly works without that we fixed it. The new implementation that is in 1.1 has been reverted in 1.0 and since then we haven't had any complaints. Now in 1.1 I guess that there are not that many people using it yet. If there are people at the sprint with different OS and configurations (Linux vs Mac; IPv4 vs. IPv6), you could try to reproduce the problems that were reported earlier (check the issue tracker). Another valuable help would be to (manually) test the tools, especially the ones loaded into Pharo to make sure we don't have any obvious problems there. Hope you have a productive weekend! Cheers, Adrian On May 18, 2010, at 02:49 , Alexandre Bergel wrote: > Mariano, Stef, Adrian, > > I would like to focus the Pharo sprint this week end on helping Pharo 1.1. > In addition to reviewing and fixing the issues tagged as 1.1, are there some particular actions you want to see realized this Saturday? > > Cheers, > Alexandre > > > On 16 May 2010, at 18:26, Alexandre Bergel wrote: > >>> - Integegrate the remaining fixes and crates a PharoCore-11XXX-alpha1.zip and put it in gforge >> >> >> I will go over some this week. >> >> Alexandre >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010