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

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

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Igor Stasenko

2010/5/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> On Ma >> > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also >> > uses bits 1 through 4 >> > Â Â Â Â Â Â Â bit 0: 1 => open full screen, 0 => open using width & >> > height >> > Â Â Â Â Â Â Â bit 1: 1 => image floats are in little-endian format, 0=> >> > image floats are in big-endian format >> > Â Â Â Â Â Â Â bit 2: 1 => Process's 4th inst var (after myList) is >> > threadId to be used by the VM for overlapped calls >> > >> > Â Â Â Â Â Â Â bit 3: 1 => set the flag bit on methods that the VM will >> > only interpret (because they're considered too big to JIT) >> > Â Â Â Â Â Â Â bit 4: 1 => preempting a process does not put it to the >> > back of its run queue >> >> >> I was not clear how to read >> Â Â Â Â bit 3: 1 >> this information is not in the compiledMethods? > > For the Cog JIT I want to measure which methods get interpreted to determine > the threshold at which to decide to JIT methods. Â It makes little sense to > JIT methods that are large and only executed once, typically class > initialization methods. A simple criterion is to set a limit on the number > of literals in a method. Â But I still need to know whether my threshold is > affecting frequently used methods. Â So I added the option of setting the > flag bit in any method which the JIT refuses to compile because it has too > many literals. Â Since I need to see which methods are interpreted on > start-up putting a flag in the image header was convenient. Â The effect is > that the JIT will set the flag bit on any method it refuses to JIT. Â I can > then browse these in the image and decide whether any are important and > adjust the threshold accordingly. Â Arguably this should be a command line > argument, not an image header flag. Eliot, i beg you, instead of using an obscure flags in image header, just add (or reserve unused) splObject indice and read/write whatever you want from there. I guess that Cog having substantial changes all around places, so adding a convenient API for VM flags and removing a bit fiddling from image header, would make things transparent and easy to use from language side. >> >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 18, 2010

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

by Miguel Enrique CobÃ¡ Martinez

El lun, 17-05-2010 a las 09:49 +0200, StÃ©phane Ducasse escribiÃ³: > I like the idea of tags. > Now I still would like to be able to freeze a version. This way we could have a pharo10 distribution on a CD > with all the code included. But look at Debian for example. They release a stable release, lets say 5.0 on January 15th. This is a iso image that includes a given set of package versions, lets say Package A version 1.1 Package B version 2.0 Package C version 2.1 then they continue working on testing and unstable versions of the distro. Of course as the software is used all around the world, the users report bugs and the developers push new versions with the fixes to the debian repositories. The fixes can be bug fixes, security fixes and new features. Only the security fixes and severe bug fixes are pushed to the stable release (as well as to the testing and unstable branches of course). This security fixes are part of the security updates for stable installations of the distro. But.. after a given number of security fixes and severe bug fixes are collected, they release an update for the stable release, even generating new .iso files. Suppose that they release an update in May 1st. They could call it Debian GNU/Linux stable 5.0.1. The point is, even if I downloaded the stable release on January 15th, it is different from the version you download on May 1st. They are both called debian 5.0 stable and nobody expect that they are bitwise identical. But, when you install from the version from January and after updating it from the update stream, I get the same packages that the person that install its server from the version of May 1st. I think the same can happen to Pharo. You release a given set of versions (in the form of configurationOfXXX) but that doesn't means that those are inmutable. They will be updated to match the packages that fix bugs in a given external package. Now for the generation of the release, you simply script it to use the latest #released version of a configuration. That is the way that Metacello works currently, installing the latest released version by default. Cheers > > Stef > > > > I was thinking about the "folders" to store copies of ConfigurationOfXXX > > for a given release. I think that this will have problems, for example > > for the simplest package that load fine in 3 consecutive release we will > > have exactly 3 copies of the ConfigurationOfXXX package (not that the > > disk space is a problem). On the other side, if a package has 19 > > versions for a given release (lets say RFB has 19 version methods in the > > ConfigurationOfXXX for Pharo 1.0), then when Pharo 2.0 is released, a > > copy of it will be made. This copy will be full, having the 19 version > > methods, or you just take the last version method. Also, what about the > > pre/post do its, they will likely be similar or exactly equal between > > releases of Pharo. > > If you delete the methods, you also lost the history and the opportunity > > that new users can learn or use the previous versions. > > > > Some time ago I proposed the idea that Metacello should have tags to > > mark that a version method has been tested in a given fork/release. As > > the time pass, the tags in a method will grow to mark the version has > > been tested on. > > But for this to work, Metacello or the tools (I would prefer Metacello) > > must honor this tags and before loading the code in a given image by > > comparing what image is being installed on. > > > > Lets put an example: > > > > 1. Initial creation of the configuration for package Package for Pharo > > 1.0 uploaded to MetacelloRepository: > > > > ConfigurationOfPackage>>baseline01 > > "initial baseline" > > > > ConfigurationOfPackage>>version01: spec > > <version: '0.1'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: 'Pharo1.0' > > ... ]. > > > > 2. A new version for Pharo 1.0 (lets say a bug fix): > > > > ConfigurationOfPackage>>version02: spec > > <version: '0.2'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: 'Pharo1.0' > > ... ]. > > > > 3. A new Pharo release is made, no changes to the package are needed, > > that is, it works correctly in Pharo1.0 and Pharo 1.1 > > > > ConfigurationOfPackage>>version03: spec > > <version: '0.3'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' ) > > ... ]. > > > > At this point the ConfigurationOfPackage has four methods: baseline and > > three versions. Also, before loading, Metacello checks the worksIn: > > list against a standard release string in the image is working on. If > > it match it install the package. That is, if I start with a Pharo1.1 > > image and load the configuration, the only possible candidate version > > to install is the 0.3, because is the only one marked to work in Pharo1.1. > > > > 4. A port to Squeak 5 is made. This likely will need a new baseline > > because will need squeak specific packages to be included > > (compatibility packages) and also maybe a Pharo compatibility package > > will be made. Anyway, a new baseline indicating new packages > > relationships will be made: > > > > ConfigurationOfPackage>>baseline02 > > "second baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version04: spec > > <version: '0.4'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.0' 'Pharo1.1' 'Squeak5.0' ) > > ... ]. > > spec for: #squeak do: [ > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > At this point the ConfigurationOfXXX is capable of install the last > > version in Squeak and Pharo. > > > > If I start on Squeak 4.0 then even if I load the > > ConfigurationOfPackage, no package will be installed because nobody has tested this. > > > > If I start on Squeak 5.0 only version 0.4 can be installed. > > > > If I start on Pharo 1.0 versions 0.1, 0.2, 0.3 and 0.4 can be installed > > > > If I start on Pharo 1.3 no package will be installed > > > > 5. Nobody updates the configuration for the Squeak 6.0 and 7.0 releases > > but new versions are created for Pharo 1.3 and Pharo1.4. The code no longer works in Pharo 1.0 and Pharo1.1 > > > > ConfigurationOfPackage>>baseline08 > > "second baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version09: spec > > <version: '0.9'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' ) > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > 6. Installing on Squeak 8 is again supported together with support for Squeak 7.0: > > > > ConfigurationOfPackage>>baseline04 > > "third baseline, it accounts for install in Pharo and Squeak" > > > > ConfigurationOfPackage>>version10: spec > > <version: '1.0'> > > > > spec for: #common do: [ > > spec blessing: #release. > > spec worksIn: #( 'Pharo1.3' 'Pharo1.4' 'Squeak7.0' 'Squeak8.0' ) > > ... ]. > > spec for: #squeak do: [ > > ... ]. > > spec for: #pharo do: [ > > ... ]. > > > > So the tags come and go as the support for given forks and releases are > > tested. > > Different versions of the Package package can work in different forks > > and in different releases of those forks. > > It is always the job of the interested parties to add support (that is > > version methods and baselines, or simply tags to the worksIn: list) for > > a package in a given combination. > > > > What do you think? > > > > Cheers > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 18, 2010

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

by Igor Stasenko

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? 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 - #++ -- Best regards, Igor Stasenko AKA sig.

May 18, 2010