- Pharo-dev - lists.pharo.org

[Pharo-project] [TODO] Open bugs in 1.3

by Marcus Denker

http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.3 Core: 4840 Schedule>>between:and:do can iterate over the wrong dates. 4753 Implementors browser doesn't show decompiled source 4745 Debugger opens when trying to get unimplemented calls External Packages: 4889 RBSearchTest has undefined iVar reference 4947 Imported Script Manager scripts disappear 4926 Trait Browsing -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011

Re: [Pharo-project] Issue tracker states

by StÃ©phane Ducasse

Yes I like that list Stef On Oct 28, 2011, at 5:42 PM, Marcus Denker wrote: > 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 > > -- > Marcus Denker -- http://marcusdenker.de > >

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

Hi doru I will spend amos time to do an analysis of the possible paths. Right now RPackage Organizer is fill up based on PackageOrganizer so a category is mapped to a package and extensions are managed well (probably some funky case still do not work 100%). Now what marcus and igor were afraid is that big packages with a lot of subcategories would become a lot of packages. Examples: Morphic -> Morphic-Menu, Morphic-Basic, Morphicâ¦. To me this is not a problem but I introduced at the level of packages the possibility to tag classes: This way we could take MCWorkingCopies as package (but with the fucking matching that nobody understand really) and the large packages could be displayed in browser Package Morphic Morphic-menu classes Morphic-Basic classes â¦ Now I do not like that because it means that we will have to do all the matching i.e. *Morphic-Menu methods belong to Morphic because there is Morphic and not Morphic-Menu as packages. > B. > > Actually, I really do not understand what the issue is. We said from the very beginning that the strategy is the following: > > Stage 1: Get RPackage in the image and pretend that it acts like a smart cache for categories. Everything is expressed in terms of categories and mirrored in RPackage. Tools can now be built on top of RPackage. At this stage, no modification is needed and the new tools will work next to the old ones. yes we have already that. Probably with some bugs with the matching in edge cases. > Stage 2: Leave the logic of Monticello loading as it is now (n-to-1 Categoeies-to-MonticelloPackage), but modify Monticello publishing to rely on 1-to-1 RPackage-to-MonticelloPackage. This will basically force people to start changing the configurations. Yes this is what afraid marcus and igor because people will cry that they have to change the configurations and that they will lose the subcategory. For me I want to get rid of categories this is a bogus concept #cat #Cat 'Cat' 'cat' string bad management and pattern matching as well as the monolithic systemOrganizer is terrible. > > Stage 3: Change the Monticello loading to only allow 1-to-1 RPackage-to-MonticelloPackage. At this point, we can safely remove the Categories. > > > So, why should this not work? Cries: "oh my nice package now is split in multiple onesâ¦.. kind of problems" > Btw, there is a working basic GlamorousClassicCoder using RPackage. I did not announce it yet because there are still details to deal with. Nautilus is fully working on RPackage too. :) So I will continue to see what I can do. To me I would simplify everything. We have too many concepts. I would love to remove category and have packages. We have a good implementation of packages. > > Cheers, > Doru > > > On 28 Oct 2011, at 13:20, StÃ©phane Ducasse wrote: > >> Hi guys >> >> so what do we do with RPackage >> - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. >> but this means that we will stay with the old browsers. Sounds like a promising future. >> - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. >> - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose >> a real plan to get towards a solution. >> >> Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. >> Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. >> Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this >> means that we will have to match the complete system with subcategories ( >> Graphics-Core >> should match Graphics* >> >> So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete >> discussions. Apparently nobody care anyway. So this should not be important after all. >> >> Stef > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > >

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by StÃ©phane Ducasse

I do not buy your analysis at all. Look at the state of package organizer and other. Then I do not see why 1.3 is a dead-end. In any case thank for the positive feedback. Stef On Oct 28, 2011, at 2:55 PM, Lukas Renggli wrote: > In 2008 I wrote: > > There is a clean 1:1 mapping between categories/protocols and > packages. If X is the package name, then ... > > 1. Category X is the core-package. > 2. Category X-y is a sub-package y. > 3. Protocol *X are extension methods. > 4. Protocol *X-y is an extension to the y protocol. > > I see this as a way to move from the naming conventions to a first > class package model. It is critical to have a browser that hides those > naming conventions, while still keeping them (at the moment) for > backward compatibility. > > Since there is no clean migration path, I vote for (A). > > When looking at Pharo today I don't see the current packaging system > (or the lack thereof) as a major problem. The current infrastructure > works reasonably well and does not hinder progress. What is really > painful is that everything breaks with every release. Thus, what would > be way more important is a module/namespace system so that we can load > and run different versions of the same code without interfering. In > the current state Pharo 1.3 is a dead end, because I will never be > able to load my code into Pharo 1.4. > > Lukas > > On 28 October 2011 14:40, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >> On Oct 28, 2011, at 1:20 PM, StÃ©phane Ducasse wrote: >> >>> Hi guys >>> >>> so what do we do with RPackage >>> - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. >>> but this means that we will stay with the old browsers. Sounds like a promising future. >>> - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. >>> - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose >>> a real plan to get towards a solution. >>> >>> Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. >>> Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. >>> Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this >>> means that we will have to match the complete system with subcategories ( >>> Graphics-Core >>> should match Graphics* >>> >>> So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete >>> discussions. Apparently nobody care anyway. So this should not be important after all. >>> >>> Stef >> >> >> Cool ... >> >> Ben >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Oct. 30, 2011

[Pharo-project] [update 1.4] #14212

by Marcus Denker

14212 ----- Issue 4948: Request for a clearer and faster #asFloat conversion http://code.google.com/p/pharo/issues/detail?id=4948 Issue 2975: faster non-primitive String primitives by using #basicAt: instead of #at: + #asInteger/#asciiValue http://code.google.com/p/pharo/issues/detail?id=2975 Issue 2228: dont try to set the position of the file if its not possible http://code.google.com/p/pharo/issues/detail?id=2228 -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011

Re: [Pharo-project] Is RPackage dead?

by Alain Plantec

Le 28/10/2011 14:55, Lukas Renggli a Ã©crit : > > Since there is no clean migration path, I vote for (A). > > When looking at Pharo today I don't see the current packaging system > (or the lack thereof) as a major problem. The current infrastructure > works reasonably well and does not hinder progress. What is really > painful is that everything breaks with every release. I vote for B. But could'nt we adopt an Ubuntu like release scheme: - Decide that 1.3 is a Long Term Supported version: it means critical bogue fixes only, it stays LTS until another release is declared as LTS. - 1.4 and subsequent releases would be testing releases (RPackage in 1.4). Cheers Alain > Thus, what would > be way more important is a module/namespace system so that we can load > and run different versions of the same code without interfering. In > the current state Pharo 1.3 is a dead end, because I will never be > able to load my code into Pharo 1.4. > > Lukas > > On 28 October 2011 14:40, Benjamin<benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> On Oct 28, 2011, at 1:20 PM, StÃ©phane Ducasse wrote: >> >>> Hi guys >>> >>> so what do we do with RPackage >>> - (A) throw away 4 months or more of my work. I feel sorry for Nautilus and I could understand that benjmain gets really pissed off. >>> but this means that we will stay with the old browsers. Sounds like a promising future. >>> - (B) use it with a mapping one to one with category (and yes people will have to change the configurations). This is done. >>> - (C) somebody takes three hours to look at what I did and think a bit but does not tell me that this is easy but propose >>> a real plan to get towards a solution. >>> >>> Marcus, igor your wish to have labels (I added them to RPackage). I fixed SystemAnnouncement. >>> Now without help it will not work (if you do not put energy on the table). I have a lot of wishes too and something else to do too. >>> Because we have categories in additionâ¦ I discussed with Benjamin and we can fill up RPackageOrganizer with MCWorkingCopies but this >>> means that we will have to match the complete system with subcategories ( >>> Graphics-Core >>> should match Graphics* >>> >>> So since it does not seem that we are pragmatic or that we want to make progress on this topic, I will do A and we will wait for concrete >>> discussions. Apparently nobody care anyway. So this should not be important after all. >>> >>> Stef >> >> Cool ... >> >> Ben >> >> >> > >

Oct. 30, 2011

Re: [Pharo-project] Issue tracker states

by Marcus Denker

On Oct 28, 2011, at 7:03 PM, Mariano Martinez Peck wrote: > THanks Marcus :) > Maybe we should put that explanation somewhere? > For example, in http://www.pharo-project.org/community/issue-tracking Yes, I will add it. Marcus -- Marcus Denker -- http://marcusdenker.de

Oct. 30, 2011

Re: [Pharo-project] Smalltalk Job in L.A.

by Noury Bouraqadi

Hi, Do you have link or a contact email for the job offrer ? On 29 oct. 2011, at 18:28, blake wrote: > Hey, guys-- > > There's a job opening with Sempra, some kind of energy company, in the Los Angeles area (Marina Del Rey, Monterey Park--you can Google the locations), that requires C++ and Smalltalk. > > ===Blake=== Noury -- http://twitter.com/#!/NouryBouraqadi

Oct. 30, 2011

Re: [Pharo-project] Windows disappear in saved image on startup

by Max Leske

Since the .changes files (together with the .sources file) contains all your changes, have you tried to get a fresh image of the same version and open it with the .changes file of one of your problematic images? Max On 30.10.2011, at 05:04, Sean P. DeNigris wrote: > The startup list is processed before you can do a user interrupt. The only > way I know of to stop before that is to compile a debug version of the VM > and set a breakpoint on the VM side. > > See > http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.h… > > Sean > > -- > View this message in context: http://forum.world.st/Windows-disappear-in-saved-image-on-startup-tp3944123… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 30, 2011

Re: [Pharo-project] Windows disappear in saved image on startup

by Sean P. DeNigris

The startup list is processed before you can do a user interrupt. The only way I know of to stop before that is to compile a debug version of the VM and set a breakpoint on the VM side. See http://forum.world.st/Fwd-Oops-I-put-a-halt-in-a-startup-method-td3800729.h… Sean -- View this message in context: http://forum.world.st/Windows-disappear-in-saved-image-on-startup-tp3944123… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 30, 2011