- Pharo-dev - lists.pharo.org

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Marcus Denker

On 22.02.2009, at 22:42, Keith Hodges wrote: > > The traditional approach that Pharo is using produces a new image, > developed by a new team as a complete break from the past, and > everyone > is forced to code to a moving target. This is the process that squeak > has been using since before the flood, and it is this process that I > have identified as the problem. (I accept that I may be wrong) > So nobody is actually *using* 3.11? (would 4.1 the name of it now?) The problem I see here is that this 3.11 will not have been tested at all. Is that correct? > I myself haven't adopted Pharo, not because you aren't making good > changes, or making things better, but because your development process > guarantees that there will be problems down the line. Not only do you > make it difficult for me to port my current deployments to Pharo with > anything other than a step change, since that is your avowed intent. > But > also Pharo 2 will inevitably be incompatible with Pharo1 and so on, > due > to the process. > Yes. Beeing incompatible with the past is the only way to make progress. > I thank the pharo team for performing lots of useful research on > behalf > of the squeak community, I expect that we will be able to adopt most > of > your innovations, but this will take time, and will be carefully > considered, with the backward compatabiity issue in mind. Pharo is not Research. Research you can find here (for example): http://www.iam.unibe.ch/~denker/mdpubs.cgi?byCategory Enabeling Software Evolution one of the themes of that Research, interestingly. The direction this is going might get clearer from a quote from http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Nier08a : Backward compatibility is the enemy of forward-evolvability. Nevertheless, we cannot live in a world were the old is ignored. A snapshot of an old Windows machine can run on a virtual machine forever, whereas keeping an operating system compatible forever will be bound to fail. Programming languages for eternal systems should provide backwards compatibility in the same way: we need a first class description of the history of all code of the system, freeing the present from being compatible with the past while at the same time providing the possibility to go back in time easily. The system should provide complete, runnable snapshots of the system at any point in the past. Eternal systems need languages that support continuous development and evolution. But there is another aspect to the language: to think that we can envision the perfect language to realize all future systems is to treat language design like a finite game. Thus a language suited for implement- ing ever-evolving, eternal software systems needs to be itself an eternal program. An eternal language must evolve to incorporate new ideas and practices while it is used. It needs to be extensible and growable from within. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Igor Stasenko

2009/2/23 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: > >> Indeed. It is difficult, but possible :) >> I want to refactor VM code to make all windowing stuff be exclusively >> driven from language side. >> So, when you run: >> squeak -headless myimage.image >> >> and -headless flag is handled not by VM itself, but by language side. >> So, you can ignore such flag, or can honor it - all is in your hands. > > Well, while you are at it ;-) everything related to display, input and > clipboard should be moved out of the core VM into plugins so one could > build a truely headless VM e.g. for running scripts. > exactly, that's my point. In a longer perspective, i'd also would like to be able to build VM as a library, so one can embed it into own project. > Michael > > _______________________________________________ > 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.

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Michael Rueger

Igor Stasenko wrote: > Indeed. It is difficult, but possible :) > I want to refactor VM code to make all windowing stuff be exclusively > driven from language side. > So, when you run: > squeak -headless myimage.image > > and -headless flag is handled not by VM itself, but by language side. > So, you can ignore such flag, or can honor it - all is in your hands. Well, while you are at it ;-) everything related to display, input and clipboard should be moved out of the core VM into plugins so one could build a truely headless VM e.g. for running scripts. Michael

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Igor Stasenko

2009/2/22 Michael Rueger <m.rueger(a)acm.org>: > Todd Blanchard wrote: >> And WOW the new UI skins are beautiful! >> >> So pretty, I almost hate to ask about integrating the mythical >> ffenesteri native window support that I've never been able to make >> work (which would obsolete all that work, but would help squeak fit >> into the real world better). > > The event support is part of the new VMs and native windows per se > wouldn't obsolete the current UI work. It is rather difficult though to > make Morphic work with multiple windows AFAIK. > Indeed. It is difficult, but possible :) I want to refactor VM code to make all windowing stuff be exclusively driven from language side. So, when you run: squeak -headless myimage.image and -headless flag is handled not by VM itself, but by language side. So, you can ignore such flag, or can honor it - all is in your hands. > Michael > > _______________________________________________ > 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.

Feb. 23, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by John M McIntosh

Old news. http://www.nabble.com/An-issue-with-Slang,-the-interpreter---the-VM,-and-a-… Could be other important VMMaker changes between 2007 and today... On 22-Feb-09, at 4:47 AM, Bruce O'Neel wrote: > Hi, > > I downloaded Ian's image/changes bundle named unix-3.10-4.vmm.tar.gz > from http://www.squeakvm.org/unix/ > and looked into it a bit. > > In ObjectMemory biasToGrow it looks like the problem is > > biasToGrow > | growSize | > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) > self growObjectMemory: growSize > > there are no '.'s after the lines. Shouldn't it look like: > > biasToGrow > | growSize | > growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock). > self growObjectMemory: growSize. > > that? > > It looks like the slang interpreter/translater must be coughing a > bit on what is basically > slight invalid syntax, right? > > I guess that next up I have to figure out how to actually run vm > maker :-) > > cheers > > bruce -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 23, 2009

Re: [Pharo-project] httpProxyServer username and password

by Geert

I am struggling in understanding Proxy settings (I am still very new here and I am now using the latest pharo0.1-10236dev09.02.2 image). I specified the httpProxyServer and httpProxyPort in the http proxy category in the preferences browser. Since the corporate proxy here requires everyone to authenticate, I also specified my username and password using: HTTPSocket proxyUser: 'myUsername' password: 'myPassword' in a Workspace. I am not really getting an error message, but when trying to do an system update for example I get a message saying that "all code update servers seem to be unavailable" and when trying to install refresh a list of packages from the network in the Universe (Basic) browser nothing happens? I did an "Inspect It" of HTTPSocket and I noticed it says "Proxy-Authorization: Basic"? When I type "InternetConfiguration useHTTPProxy" in my Workspace and do "Print It" I get "false"? I am sure I am doing something wrong here but can't seem to figure out what? On a side note, maybe the proxy settings in the preference browser should be in a category called "Network" rather then "http proxy" and be more in the standard format of: Network - No Proxy - Manual Proxy Configuration -- HTTP Proxy _____ Port __ -- Username ___ Password _____ (this is currently missing) - Automatic Proxy Configuration URL -- ___________ (this is missing too) Anyway, any help or advice is very much appreciated. Geert wrote: > > I am running my Pharo image from a USB stick and I am having problems > connecting to the internet at work . I can't seem to find how to set the > corporate http proxy username and password anywhere ... I did manage to > find the httpProxyPort and httpProxyServer settings using the preference > browser but how do I specify the username and password? > -- View this message in context: http://n2.nabble.com/httpProxyServer-username-and-password-tp2331762p236975… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 23, 2009

Re: [Pharo-project] Just downloaded pharo

by Michael Rueger

Todd Blanchard wrote: > And WOW the new UI skins are beautiful! > > So pretty, I almost hate to ask about integrating the mythical > ffenesteri native window support that I've never been able to make > work (which would obsolete all that work, but would help squeak fit > into the real world better). The event support is part of the new VMs and native windows per se wouldn't obsolete the current UI work. It is rather difficult though to make Morphic work with multiple windows AFAIK. Michael

Feb. 22, 2009

Re: [Pharo-project] Deleting Mantis Pharo project

by Keith Hodges

>> Adrian Lienhard wrote: >> >>> I just noticed, that in the Squeak Mantis bug tacker there is a >>> project called Pharo. This should be deleted to avoid confusion. Does >>> anybody know who to contact? >>> >>> Adrian >>> >>> >>> >> I will ask to get that sorted >> >> Keith >> >> Ken Causey <ken(a)kencausey.com> says ask him cheers Keith

Feb. 22, 2009

Re: [Pharo-project] What about #ifNotNil and #ifNotNilDo:

by Keith Hodges

>> >>> Hi, >> >>> >> >>> is there a way to get the #ifNotNilDo: behavior to write compatible >> >>> Squeak and Pharo code? >> >>> >> >>> >> > >> >> -> do not use ifNotNilDo: >> -> use ifNotNil: without the > argument. >> >> The real fix of course would be for Squeak adopting > the optinal args >> changeset >> (this is from 2007...) > > The Author class is another > > incompatibility issue that I expect to have to address via LPF. Are > > there any more? > Thousands. Literally. > > I am highly skeptical about LPF. > > Marcus Hello Marcus, I don't think that you understand, LPF is only about providing a leg up for the older code, a migration path for fundamental stuff, like Monticello. You appear to have adopted the view that LPF ( http://installer.pbwiki.com/LevelPlayingField ) is supposed to make the whole image up to the same level for everyone. It isn't, it works for what it was intended to do, that is to provide Installer/MC/MCC/Sake/Packages/PackageInfo for all images. In this case, I do hope that Pharo hasn't made thousands of changes which prevent code from loading and compiling in Squeak. That is the issue that ifNotNil: [ :a | ] and Author raises, Syntax errors on loading. I am sure that LPF can help there in the majority of cases. Most projects are built in layers, the fundamental layers, once ported may support other layers across all images. LPF is primarily about loading code across images. Getting that code to work is another problem entirely which LPF may help with, but is not expected to solve. Perhaps a concrete example might help illustrate what the issues really are: You guys developed your Monticello for 3.9, and it wasn't compatible with 3.8, 3.8 code loaded into 3.9 but not the other way around, and the 3.9 Monticello implementation itself was never designed to be loaded in 3.8. In short the 3.8 Monticello became dead to innovation (a fork by default rather than by design), and unmaintained overnight, as did a lot of 3.8 code. This is the issue that LPF was designed to address. The purpose of LPF is to help prevent projects getting completely stuck on one image, particularly to enable projects stuck in 3.8 to move to 3.10. When you want to port a large commercial project from one image to another you want to support your existing users in the old image at the same time as working on the next version in the new base image.. You want to continue to manage your packages simply without having to keep two separate branches. MC in 3.9 would not save mcz files that would load into 3.8, and this fact alone was a real barrier to moving things forward. The new 3.11 development process, aims to address this. Tools, fixes, and API's that may be included in 3.11, will be developed and usable in 3.10. So both the current user base in 3.10, and the early adopters in 3.11 are able to use identical API's and Tools, and migration is both possible and probable. The traditional approach that Pharo is using produces a new image, developed by a new team as a complete break from the past, and everyone is forced to code to a moving target. This is the process that squeak has been using since before the flood, and it is this process that I have identified as the problem. (I accept that I may be wrong) I myself haven't adopted Pharo, not because you aren't making good changes, or making things better, but because your development process guarantees that there will be problems down the line. Not only do you make it difficult for me to port my current deployments to Pharo with anything other than a step change, since that is your avowed intent. But also Pharo 2 will inevitably be incompatible with Pharo1 and so on, due to the process. I thank the pharo team for performing lots of useful research on behalf of the squeak community, I expect that we will be able to adopt most of your innovations, but this will take time, and will be carefully considered, with the backward compatabiity issue in mind. regards Keith

Feb. 22, 2009

Re: [Pharo-project] Just downloaded pharo

by Alexandre Bergel

Thanks Todd for your nice words, and thanks (one more time!) to the Pinesoft crew to make it happen. Cheers, Alexandre On 22 Feb 2009, at 22:31, Todd Blanchard wrote: > And WOW the new UI skins are beautiful! > > So pretty, I almost hate to ask about integrating the mythical > ffenesteri native window support that I've never been able to make > work (which would obsolete all that work, but would help squeak fit > into the real world better). > > -Todd Blanchard > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009