- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Trello board for 1.4 items...

by phil＠highoctane.be

Added to the webmix Philippe 2012/4/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > Excellent. Marcus, what about adding it to > http://www.pharo-project.org/community ? > or somewhere there. ... > > And maybe also add it here: http://www.symbaloo.com/mix/pharo > > what else can we add there? it is really nice that symbaloo thing. > > > > On Mon, Apr 16, 2012 at 5:51 PM, Mark Smith <mark.smith(a)objectbynature.com > > wrote: > >> Very cool :). That makes it easier to see what's going on. >> >> On 16 Apr 2012, at 13:32, Marcus Denker wrote: >> >> > ... we are experimenting using Trello for coordinating the last stuff >> needed >> > to be done for 1.4: >> > >> > https://trello.com/board/pharo-1-4/4f8561e7aba027145b7f8ed0 >> > >> > Marcus >> > >> > -- >> > Marcus Denker -- http://marcusdenker.de >> > >> > >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.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

[Pharo-project] do we need contextForLocalVariables?

by stephane ducasse

Hi so far ContextPart>>contextForLocalVariables "Answer the context in which local variables (temporaries) are stored." self subclassResponsibility MethodContext>>contextForLocalVariables "Answer the context in which local variables (temporaries) are stored." ^self So we could get rid of it. Stef

April 16, 2012

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

by StÃ©phane Ducasse

Hi I think that methodNode should be moved as an extension of Compiler. Stef

April 16, 2012

Re: [Pharo-project] Domain pharo.org

by 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 16, 2012