April 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] How to globals that are NOT classes or traits?

by Mariano Martinez Peck

Hi guys. In Fuel, we need to identity which globals present in Smalltalk globals are NOT classes or traits, because we need to manage them as globals. So far we have a hardcoded list: defaultGlobalSymbols ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor #ImageImports #SystemOrganization #World) So...as every hardcoded stuff, this is not nice because as soon as globals change, we need to fix this. So it would be nice if the system (pharo) can provide us this information. What do you think? -- Mariano http://marianopeck.wordpress.com

April 17, 2012

[Pharo-project] I need Pharo 1.4 for PowerPC

by Edgar J. De Cleene

Guys, not too long ago I was able to download clean Pharo 1.4 and run on olders John VMs on G4 PowerPC. Seems site now only have CogVm versions which older VM do not run. Any place for download or I run out of luck? Related: Any ARM VM which I could try? Have a 7Â² Android named Â³LittleAsimovÂ² now and canÂ¹t wait to have Pharo into. Edgar

April 17, 2012

Re: [Pharo-project] ContextPart>>methodNode -> Compiler?

by Guillermo Polito

Me too. And BlockClosure should have an alternative printOn: when there is no compiler/decompiler :). (It's bothered me a lot lately) Guille On Mon, Apr 16, 2012 at 10:11 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi > > I think that methodNode should be moved as an extension of Compiler. > > Stef > >

April 17, 2012

Re: [Pharo-project] Domain pharo.org

by Christoph Wysseier

Hey Marcus The easiest way to install alias domains of a cmsbox websites with proper redirection is to configure the DNS entry to point to 217.11.221.200 (Host: one.cmsbox.com) I already configured the webserver accordingly. Cheers, Chris Am 16.04.12 21:28, schrieb Yanni Chiu: > On 16/04/12 12:56 PM, Sven Van Caekenberghe wrote: >> >> On 16 Apr 2012, at 17:20, Marcus Denker wrote: >> >>> ... we do have the domain pharo.org now (configured to forward to >>> pharo-project.org) >> >> Yes! >> >> (And we also have pharo.st - my favorite). > > pharo.st and www.pharo.st forwarded to http://www.pharo-project.org/home > > pharo.org forwarded to http://www.pharo-project.org/home > > But, www.pharo.org return 400 Bad Request > >

April 17, 2012

[Pharo-project] SourceFiles

by Martin Dias

Hi all I vaguely remember some discussions about enhancing SourceFiles, something about to reify a code manager, about to stop logging fileIns into .changes file, and about to inspire the new mechanism on the VW's one. Am I right? There is consensus on this? Do you think I could do it as part of Fuel Injector GSoC project? Best regards MartÃn

April 17, 2012

[Pharo-project] Block with ^ examples ...

by James Ladd

Hi All, I want to write some more tests for Redline Smalltalk block handling. Where can I find a really good description of how blocks with ^ in them are handled? ie: [ ^ true. ] Rgs, James.

April 17, 2012

Re: [Pharo-project] Broken Pharo 1.4 and windows VM

by Eliot Miranda

Hi Hilaire, I guess you're running Windows 7 and that the VM is quite correctly answering something like 7.1 for Smalltalk vm getSystemAttribute: 1002 a.k.a. Smalltalk os osVersion. So I suspect the preferencesRootPath method needs to be updated to take into account Windows 7. On Fri, Apr 13, 2012 at 1:21 PM, Hilaire Fernandes < hilaire.fernandes(a)edu.ge.ch> wrote: > I took the Pharo 1.3 one-click package from Pharo-project then I > replaced the image with a Pharo 1.4 image. > > It looks like the code from DosFileDirectory>>preferencesRootPath is > broken or the the used VM does not return the expected value (Smalltalk > vm getSystemAttribute: 1002) > > I tested with the COG VM for Windows from Pharo web site, the problem is > the same. > > Fix may be easy but I don't know exactly the extent of the problem. > > I have tested under Wine as I don't have windows. > > > Hilaire > > > > preferencesRootPath > | list rootPath osMajorVer | > > "First try to adhere to hardcoded Microsoft conventions - though we > really should be reading environment variables since %SYSTEMDRIVE% might > not be C: " > "Windows OS Version numbers from > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%… > " > > osMajorVer := Smalltalk os osVersion first. > osMajorVer = $5 ifTrue: [ rootPath := 'C:\Documents and Settings\All > Users\Pharo\']. > osMajorVer = $6 ifTrue: [ rootPath := 'C:\ProgramData\Pharo\']. > > > -- > Dr. Geo -- http://www.drgeo.eu > > > -- best, Eliot

April 17, 2012

[Pharo-project] Image locked with Display fullscreenOn.

by phil＠highoctane.be

Hello, Got my image unusable after doing a Display fullscreenOn on Win XPSP3 with a 1.3 image. Never had the issue on the Mac. Weird. Any idea on how to solve this without shuttling my image on OSX, changing, saving, and bringing it back on Windows? I made a do.st file with Display fullscreenOff and tried a CogVM.exe xxx.image do.st but to no avail. Help! Philippe

April 16, 2012

Re: [Pharo-project] Block questions

by Eliot Miranda

On Sun, Apr 15, 2012 at 1:22 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > b := [ |a| a:=2 ]. > b asContext tempNames -> #('a') > b asContext tempNamed: 'a' -> Boom in MethodContext>>#tempAt: primitive > > tempAt: in Method context uses <primitive: 210>, which is failing. Maybe > there is a new primitive we are not aware of for Blocks... No, 210 is what is needed. The issue is my implementation of temporary initialization in blocks, which simply uses pushNil to allocate and initialize each temp. So if one inspects [|a|a:=2] and sends it self method symbolic you get: 13 <8F 00 00 05> closureNumCopied: 0 numArgs: 0 bytes 17 to 21 17 <73> pushConstant: nil 18 <77> pushConstant: 2 19 <81 40> storeIntoTemp: 0 21 <7D> blockReturn 22 <7C> returnTop And when you say self asContext pc you get 17, which is *before* the nil is pushed. So you'll want to modify tempNamed: to compare the index of the temporary with the stack pointer and answer nil if the index is beyond the stack pointer. The same bug exists in Squeak, e.g. the below gave an error until I fixed DebuggerMethodMap>>namedTempAt:in: | b | b := [ |a| a:=2 ]. { b asContext tempNames. b method debuggerMap tempsAndValuesForContext: b asContext } #(#('b' 'a') 'b: [closure] in UndefinedObject>>DoIt a: nil ') Why did I use pushNil to allocate temps? It was not a good choice; it means for example that to determine how many temps a block has one has to parse all the bytecodes and see where the stack pointer is at the end (since initial pushNils are ambiguous; an initial pushNil might be producing a parameter or result or initializing a temp). But not using pushNil would have meant a more complex bytecode for closure creation plus another inst var in BlockClosure. I made another similar misstep in not storing the method in a BlockClosure, hence preventing simple implementation of clean blocks (one needs to synthesize an outerContext also). We live and learn. > > On Sat, Apr 14, 2012 at 1:09 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I'm taking some times to go back the block closure chapter and I was >> wondering how I can get access to block temporaries >> >> [ |a | a :=2. a] >> >> for example I tried >> >> [ |a | a :=2. a] >> >> outerContext contextForLocalVariables tempAt: 1 and variations but none >> worked. >> >> Stef >> >> >> >> > -- best, Eliot

April 16, 2012

Re: [Pharo-project] Pharo in OpenShift

by phil＠highoctane.be

Send me the link once it is ready so that I can add it to the symbaloo webmix http://www.symbaloo.com/mix/pharo Philippe 2012/4/16 garduino <garduino(a)gmail.com> > Hi Sven: > > > That is great news indeed. > > Thanks! > > >An alternative to getting the environment variables with OSProcess would > be > to pass their values to the >image via the command line. > > >I have a script to control an image in the way unix expects it, it is part > of this demo: > > > > http://forum.world.st/Updated-Pharo-HTTP-Server-Single-Command-Line-Demo-td… > > > Thanks, I was justing thinking in take this way, to avoid the issues I'm > having with OSProcess (I have not still discovered the origins). > > > >Yes, please do write about it. > > Sure, I will do. > > Cheers. > > -- > View this message in context: > http://forum.world.st/Pharo-in-OpenShift-tp4560365p4562081.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

April 16, 2012