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

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

by Sean P. DeNigris

Can you put the image up online? -- 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 Mariano Martinez Peck

Sorry, I have no idea :( On Sat, Oct 29, 2011 at 7:34 PM, Larry Kellogg <mac.hive(a)me.com> wrote: > Anyone? > > -- > 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. > > -- Mariano http://marianopeck.wordpress.com

Oct. 29, 2011

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

by Larry Kellogg

Anyone? -- 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. 29, 2011

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

by blake

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===

Oct. 29, 2011

Re: [Pharo-project] Is RPackage dead?

by Tudor Girba

Hi, On 28 Oct 2011, at 21:30, Lukas Renggli wrote: >> 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. > > If this works like this then that would be perfect, but I had a > different impression from the mail ("yes people will have to change > the configurations" and "does not tell me that this is easy but > propose a real plan to get towards a solution"). To make RPackage > usable there is the need to have both ways work simultaneously and > transparently together for some time. Similar to how this was done > with the transition of underscore assignments ... For all practical purposes, every change in the base system is reflected in RPackage. This was the point of the SystemAnnouncement. What does not work yet is the mechanism of having modifications at the level of RPackage reflected in categories. There are two ways around this: 1. Have tools take care to only affect categories and not RPackage directly, and only read from RPackage. 2. Build an intermediary support for this sole purpose. I think both are doable. Perhaps we can start from 1. and generalize a layer for 2. Cheers, Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Oct. 28, 2011

Re: [Pharo-project] Is RPackage dead?

by Lukas Renggli

> 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. If this works like this then that would be perfect, but I had a different impression from the mail ("yes people will have to change the configurations" and "does not tell me that this is easy but propose a real plan to get towards a solution"). To make RPackage usable there is the need to have both ways work simultaneously and transparently together for some time. Similar to how this was done with the transition of underscore assignments ... Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 28, 2011

Re: [Pharo-project] Issue tracker states

by Bernardo Ezequiel Contreras

there was a issue work flow in that page, but now it has disappeared. On Fri, Oct 28, 2011 at 2:03 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > THanks Marcus :) > Maybe we should put that explanation somewhere? > For example, in http://www.pharo-project.org/community/issue-tracking > > > On Fri, Oct 28, 2011 at 5:59 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> Thanks for the explanation. I was wondering... >> >> -- >> View this message in context: >> http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 28, 2011

Re: [Pharo-project] Is RPackage dead?

by Tudor Girba

Hi, 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. 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. 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? Btw, there is a working basic GlamorousClassicCoder using RPackage. I did not announce it yet because there are still details to deal with. 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. 28, 2011

Re: [Pharo-project] 1.3Core build moved to Jenkins

by Lukas Renggli

Thank you, I am building from this URL now. On 27 October 2011 17:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 27, 2011, at 3:54 PM, Marcus Denker wrote: > >> Hi, >> >> With https://pharo-ic.lille.inria.fr being decommissioned, we are moving everything to Jenkins: >> >> Â Â Â https://ci.lille.inria.fr/pharo/ >> >> >> >> TODO: >> >> Â Â Â -> Full (building now) > > This now builds successfully: > > Â Â Â Â https://ci.lille.inria.fr/pharo/view/Pharo%201.3/job/Pharo%201.3/ > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Lukas Renggli www.lukas-renggli.ch

Oct. 28, 2011

Re: [Pharo-project] Porting to newer image

by Brian Brown

I must say that Pharo has a come a long way and the community support for the newer tools is great... To solve my problem, I just had to read the opening text in the Pharo Image and do: DEVImageWorkspaces openExternalProjectWorkspace. Reading that, I learned about how MetaCello is being used, and was able to do: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside28'; load. ((Smalltalk at: #ConfigurationOfSeaside28) project latestVersion) load. Then I loaded my code in. With only a minor fixup to changes with the MIME* subsystem, I'm up and running on a new image with a CogVM. - Brian On Oct 27, 2011, at 11:38 AM, Brian Brown wrote: > Hello all, > > It's been a while since I showed my digital face around here ;) > > > I've got a number of Seaside based web applications that I would like to move into newer pharo images and take advantage of the VM advances that have been made. > > My stuff is all running under Seaside 2.8/Kom/Dynamic Bindings, etc.... which presents several problems when trying to load into a 1.3 Pharo Core. > > For example, Dynamic Bindings extends BlockContext, but now BlockClosure is the class that is receiving messages previously intended for BlockContext. I'm sure there will be many more issues like this, so I'm looking for advice on how to proceed. > > Is there a new Kom/DynamicBindings that works with the newer closure images? Have folks gone to a different web server, and if so, can it work with 2.8? > > If I can get this all running in a newer image, then my next step would be to port it Seaside 3, but I'm playing serious catchup in the incredible amount of changes since I was using Seaside/Pharo. > > Thanks for any advice you can give me! > > > - Brian

Oct. 28, 2011