February 2009 - Pharo-dev - lists.pharo.org

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

[Pharo-project] Just downloaded pharo

by Todd Blanchard

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

Feb. 22, 2009

Re: [Pharo-project] Deleting Mantis Pharo project

by Adrian Lienhard

thanks, Keith Adrian On Feb 22, 2009, at 18:55 , Keith Hodges wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by Gary Chambers

Evil legacy source code... I remember such "dodgy" characters (look like withespace)... Regards, Gary ----- Original Message ----- From: Rob Rothwell To: Pharo-project(a)lists.gforge.inria.fr Sent: Sunday, February 22, 2009 3:01 PM Subject: Re: [Pharo-project] [update] #10241 Wow. I bow to the depths of the Squeak neural connections that must be going on in your brain... I can only seem to find stuff like that in procedural languages when I don't know the system at all. Anyway, you are right! All I did was recompile PluggableTextMorph>>drawOn: and Smallalk condenseChanges ran to completion. I'm not quite sure how to test the Trait problems mentioned at the beginning of the thread to see if they are fixed by this, though... Rob On Sun, Feb 22, 2009 at 9:25 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: Found it... PositionableStream>>#backChunk chokes on parsing the preamble of PluggableTextMorph>>#drawOn:. String>>#asCharacter is the method that comes just before #drawOn: in the changes file: ---------- !String methodsFor: 'converting' stamp: 'marcus.denker 2/20/2009 20:16' prior: 31206904! asCharacter "Answer the receiver's first character, or a strange round non-ascii character if none. Idiosyncratic, provisional." ^ self size > 0 ifTrue: [self first] ifFalse:[$Â·]! ! !PluggableTextMorph methodsFor: 'drawing' stamp: 'marcus.denker 2/20/2009 16:30' prior: 27409324! drawOn: aCanvas ---------- When parsing #asCharacter, the UTF8 encoder fails with an errorMalformedInput because it seems to read back to the strange dot character. The question is whether this character should not be used, or whether parsing is bogus. Looking at #backChunk and related methods, latter seems possible. Looks a bit fishy with sends to #oldBack, #oldPeekBack, but also to #back. Damien, can you verify your changes in these methods? As a workaround recompiling PluggableTextMorph>>#drawOn: solves the problem (because then the source position of this method is moved away from the asCharacter method). Adrian ___________________ http://www.adrian-lienhard.ch/ On Feb 22, 2009, at 14:18 , Adrian Lienhard wrote: > I'm debugging it right now. > > What you see are only secondary symptoms because the debugger cannot > read the sources anymore because the source pointers have already > been modified but the sources file is still the old one... > > To avoid this and still see the problem, modify #moveChangesTo: to > not move the source (moveSource: false). > > The actual problem seems to be related to UTF8 conversion or stream > positioning (UTF8TextConverter>>errorMalformedInput). Backlog > attached. > > Adrian > > <SqueakDebug.log> > > On Feb 22, 2009, at 14:00 , StÃ©phane Ducasse wrote: > >> I added a trace in condenseChanges >> >> >> PluggableTabBarMorph >> PluggableTabButtonMorph >> PluggableTextAttribute >> PluggableTextEditorMorph >> PluggableTextFieldMorph >> PluggableTextMorph >> (and is Undeclared) (See is Undeclared) (Unless is Undeclared) >> (works is Undeclared) (Portions is Undeclared) (Copyright is >> Undeclared) >> >> >> >> Stef >> >> On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: >> >>> I tried >>> - to recompile the method licenseString on Smalltalk >>> - remove it completely from the system >>> >>> I still get the same problem >>> >>> Stef >>> >>> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: >>> >>>> Adrian in 10241 when i did Smalltalk condenseChanges >>>> >>>> I got a ClassDescription >>>> >>>> syntax error on the license >>>> >>>> >>>> " >>>> use and modification subject to a liberal open source license. See >>>> the main Squeak website for details. Unless stated to the >>>> contrary, >>>> works submitted for incorporation into or for distribution with >>>> Squeak >>>> shall be presumed subject to the same license. >>>> >>>> Portions of Squeak are: >>>> >>>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >>>> Copyright (c) 1997-2001 Walt Disney Company, and/or >>>> Copyrighted works of many other contributors. >>>> All rights reserved. >>>> ' >>>> >>>> " >>>> >>>> I think that fixing the condensing is the next key items since >>>> now we >>>> cannot work with Moose anymore. The changeset is getting too >>>> close to >>>> the limit. >>>> >>>> Stef >>>> >>>> >>>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >>>> >>>>> #10241 >>>>> >>>>> Issue 167: >>>>> - Traits implementation refactoring (no sharing of compiled >>>>> methods >>>>> and source) >>>>> - New tests for Traits MOP >>>>> >>>>> >>>>> Since this changes the handling of sources, the following issues >>>>> with >>>>> condensing changes may be resolved: >>>>> http://code.google.com/p/pharo/issues/detail?id=466 >>>>> http://code.google.com/p/pharo/issues/detail?id=470 >>>>> >>>>> Can somebody check these issues? >>>>> >>>>> Adrian >>>>> ___________________ >>>>> http://www.adrian-lienhard.ch/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > 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

Feb. 22, 2009

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

by Marcus Denker

On 22.02.2009, at 19:31, Marcus Denker wrote: >>> >> ok, we shall add that to LPF, where is it? >> > > http://bugs.squeak.org/view.php?id=6426 > > The solution is to adopt vasilie's fix: > > http://blog.3plus4.org/2007/04/22/notnil-then-what/ > I added a comment to the squeak bugtracker to suggest that this should be done. >> >> What would help though is if you told us what you are changing/ >> breaking >> so that we can do something about it. 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. To clearify: I am not skeptical about the *intention* of LPF. I am only very sure that it is impossible to do. Especially considering complexity involved and the interdependencies of changesets. e.g. we will soon check this fix for the ifNotNil stuff: http://code.google.com/p/pharo/issues/detail?id=327 this for sure overrides code touched by the changeset of vasili. So, in turn, LPF can not just load the original changeset for pharo, as it will revert the fix. Then, do Lukas compiler changes for literal byte-arrays touch the same methods? They should not, but are you sure? So you need to check this, by hand.... As soon as there are changesets that touch the same code, it starts to get *very* messy. (it's the same reason why overrides do not work. I override a method, second package overrides same method. So my changes are reverted. Ups. So I fix my package to take the changes into account. Now two things happen: 1) dependency. my package can only be installed *after* the other package. 2) un-installing. Un-installing, even if you track the method's versions, can only be done in reverse-order of installation, and thus is useless for most cases). Inter-dependencies of changesets is something that I completely underestimated at first. Another thing that is true especially for Squeak is that changes have a very non-linear effect: everything is entangled. That means that things depend on each other in ways that are absolutely astonishing. You change something small, and it breaks something else in a way that you would bet your house on that it would have no effect. (like changing a method comment for a good joke braking compacting of the .changes, as we saw today). This means, there is nothing else that one can do then *testing*. And as sooner code is in general use, the sooner it will get more stable. There is no other way to work on Squeak than in tiny increments and "release early, release often". Everyting else *will* fail. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 22, 2009