March 2015 - Pharo-dev - lists.pharo.org

Moose Issue 1118: GT Inspector: Double Click Doesn't Always Select Text Properly

by Sean P. DeNigris

https://code.google.com/p/moose-technology/issues/detail?id=1118 It took me a while to figure out that GT has a feature I've wanted for a long time: when you activate a workspace by clicking, the selection is preserved. Very cool! One thing though, where it also took me a while to figure out what was going on... 1. Type in the playground: 'aString'. 'anotherString'. 2. "Go" to bring up a second pane - doesn't matter which 3. Click in the second pane to put the keyboard focus there 4. Double click on one of the lines in pane #1 It is selected - great! 5. Repeat #3 6. Double click on the unselected line The selection will be cleared, but the other line will not be selected. NB: an interesting thing is that if you do the above exercise with a text editor outside the same GT window, like another GT Inspector, steps 5 and 6 work correctly just like the previous. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Moose-Issue-1118-GT-Inspector-Double-Click-Doesn-t-Al… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 31, 2015

Re: [Pharo-dev] Pull Request for UpdatedPharoByExample

by Sean P. DeNigris

Gaurav Singh wrote > Kindly review the pull request. Thanks! I reviewed and commented there. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pull-Request-for-UpdatedPharoByExample-tp4816485p4816… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 31, 2015

Issue regarding print block in the playground

by Gaurav Singh

The print block in the Pharo 4.0 image playground sometimes seems to create problem. I have created a case in the issue tracker. Link : https://pharo.fogbugz.com/f/cases/15273/Issue-regarding-print-block-in-the-… , Can anyone look at the issue?

March 31, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by Nicolas Cellier

not only the globals but the methods in MethodDictionary too :) It might be a feature, it's just that it's unused because of limited IDE and compiler. 2015-03-31 20:49 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > Hi > > Tommaso and I, while hacking on Fuel, today discovered that globals in > Pharo can have very weird bindings (I guess some of you already know that). > For example: > > class := Class new > setName: 4; > yourself. > Smalltalk > at: class name > put: class. > > So we now have a class with name 4 (which is a SmallInteger): > > self assert: (Smalltalk at: 4) == class. > > > There are basically two different issues: > 1. SystemDictionary will store any kind of association, not only symbols / > strings > 2. SystemDictionary is an IdentityDictionary and as such two equivalent > but not identical keys will not resolve to the same object: > > class := Class new > setName: (String streamContents: [ :s | s nextPutAll: > 'someName']); > yourself. > Smalltalk > at: class name > put: class. > > Smalltalk > at: (String streamContents: [ :s | s nextPutAll: > 'someNameâ]) > ifAbsent: [ false ]. âââ> falseâ > > > In Fuel we simply assume that any key to a global is either a ByteString > or ByteSymbol. If thatâs not the case bad things happen. > It would help us a lot if we could clear up the semantics of bindings in > SystemDictionary: > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol > guarantees identity)? > 3. If we allow ByteString, do we also allow WideString? > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > > Any suggestions are welcome. > > Cheers, > Max >

March 31, 2015

Re: [Pharo-dev] [squeak-dev] Bug whith contextOn:do:

by Eliot Miranda

Hi Tobias, first let me sympathize. This is such horrible code :-(. Ovr the years, getting this code to work with Cog's context-to-stack-mapping machinery has given me headaches :-). On Tue, Mar 31, 2015 at 9:01 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hey fellow Squeakers > > [Attention: low level lengthy stuff] > > I today encountered a strange behavior. > When running the Startup code, somewhen ContextPart>>#complete is called, > which, in the process issues #contextOn:do:, which subsequently somewhere > interanlly > does a jump: > > contextOn: exceptionClass do: block > "Create an #on:do: context that is ready to return from executing > its receiver" > > | ctxt chain | > ctxt := thisContext. > [chain := thisContext sender cut: ctxt. ctxt jump] on: > exceptionClass do: block. > "jump above will resume here without unwinding chain" > ^ chain > > The idea is that we end up right before '^ chain' as the comment indicates. > so what happens is that ctxt is the context of #contextOn:do: itself and > it gets > send #jump in the closure. > > Jump now does the following: > > jump > "Abandon thisContext and resume self instead (using the same > current process). You may want to save thisContext's sender before calling > this so you can jump back to it. > Self MUST BE a top context (ie. a suspended context or a abandoned > context that was jumped out of). A top context already has its return > value on its stack (see Interpreter>>primitiveSuspend and other suspending > primitives). > thisContext's sender is converted to a top context (by pushing a > nil return value on its stack) so it can be jump back to." > > | top | > "Make abandoned context a top context (has return value (nil)) so > it can be jumped back to" > thisContext sender push: nil. > > "Pop self return value then return it to self (since we jump to > self by returning to it)" > stackp = 0 ifTrue: [self stepToSendOrReturn]. > stackp = 0 ifTrue: [self push: nil]. "must be quick return > self/constant" > top := self pop. > thisContext privSender: self. > ^ top > > So. bytecode for #contextOn:do: is: > > 29 <8A 01> push: (Array new: 1) > 31 <6B> popIntoTemp: 3 > 32 <89> pushThisContext: > 33 <6A> popIntoTemp: 2 > 34 <12> pushTemp: 2 > 35 <13> pushTemp: 3 > 36 <8F 20 00 0A> closureNumCopied: 2 numArgs: 0 bytes 40 to 49 > 40 <89> pushThisContext: > 41 <D2> send: sender > 42 <10> pushTemp: 0 > 43 <E1> send: cut: > 44 <8E 00 01> popIntoTemp: 0 inVectorAt: 1 > 47 <10> pushTemp: 0 > 48 <D3> send: jump > 49 <7D> blockReturn > 50 <10> pushTemp: 0 > 51 <11> pushTemp: 1 > 52 <F0> send: on:do: > 53 <87> pop > 54 <8C 00 03> pushTemp: 0 inVectorAt: 3 > 57 <7C> returnTop > > > The jump lands right at 53 and does a pop. > HOWEVER, at this point the stack of this context is empty and the pop > actually pops the 3rd temp > from the temps that 'just happens' to be right under the stack. This > should be fatal. > HOWEVER again, Squeak actually does not pop but only decrement the SP so > the temp access still > works(this _could_ be fine but some implementations (Eg, RSqueak) tried > to separate temps and > stack; which is not possible currently). > > What could be the problem here? > - are the 'stackp = 0'-checks in #jump wrong and they actually should > check for the actual stack depth _after_ temps? > It does look like it. I would have expected this to be more correct: jump "Abandon thisContext and resume self instead (using the same current process). You may want to save thisContext's sender before calling this so you can jump back to it. Self MUST BE a top context (ie. a suspended context or a abandoned context that was jumped out of). A top context already has its return value on its stack (see Interpreter>>primitiveSuspend and other suspending primitives). thisContext's sender is converted to a top context (by pushing a nil return value on its stack) so it can be jump back to." | top | "Make abandoned context a top context (has return value (nil)) so it can be jumped back to" thisContext sender push: nil. "Pop self return value then return it to self (since we jump to self by returning to it)" stackp <= self numTemps ifTrue: [self stepToSendOrReturn]. (stackp <= self numTemps and: [self willJustPop]) ifTrue: [self push: nil]. "must be quick return self/constant" top := self pop. thisContext privSender: self. ^top > - should we put in a "sacrificial anode" in #contextOn:do: so that the pop > does not pop the empty stack? (like this: > > contextOn: exceptionClass do: block > "Create an #on:do: context that is ready to return from executing > its receiver" > > | ctxt chain | > ctxt := thisContext. > [chain := thisContext sender cut: ctxt. > ctxt push: nil. "sacrifical anode" > ctxt jump > ] on: exceptionClass do: block. > "jump above will resume here without unwinding chain" > ^ chain > That looks right. Once the on:do: is sent the thisContext of contextOn:do:'s stack contains only exceptionClass, block, context and the indirection vector containing chain. So it is in the stack = self numTemps case. > > - Or is there an even better way? > I'm not sure the other ways are any better. The way to transfer to a context without disturbing its stack is to do a process switch. So you do something equivalent to jump "Abandon thisContext and resume self instead (using the same current process)." | process semaphore | process := Processor activeProcess. semaphore := Semaphore new. [process suspendedContext unwindTo: self. process suspendedContext: self. semaphore signal] fork. semaphore wait This way no bizarre stack manipulations are going on, and no return value is pushed, because there isn't a return. One may get away with: jump "Abandon thisContext and resume self instead (using the same current process)." [| process | process := Processor activeProcess. process suspendedContext unwindTo: self. process suspendedContext: self] fork. Processor yield I'd be interested in your experience using either of these. One of the advantages the process switch versions have is in not updating the receiving context sp there's a chance the context-to-stack mapping machinery won't flush the context to the heap. In the end it might actually be faster. -- best, Eliot

March 31, 2015

Pull Request for UpdatedPharoByExample

by Gaurav Singh

Made changes in the Metaclasses chapter regarding syntax. Link to the pull request: https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/5 Kindly review the pull request.

March 31, 2015

Re: [Pharo-dev] Enhancing the AST API

by Bernardo Ezequiel Contreras

what about leftIndex? it's shorter On Tue, Mar 31, 2015 at 12:53 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 31/03/2015 11:04, stepharo a Ã©crit : >> >> Hi >> >> in Pharo 50 I would like to improve the AST API. >> often we do not know if an instance variable holds a position or a node >> and this should be clear. >> For example I propose to have leftPosition instead of left. > > > If you like. > >> Does anybody has a better suggestion? > > > Well, I'm allways under the assumption that an instance variable is internal > only and that, when querying an AST node, I should allways use its API (is > that usually #startPosition and #stopPosition?). > >> This is really annoying to have to look at the users of an instance >> variable to understand its role. > > > Or have a well commented class to understand its role? It is not allways > possible to have instantaneously understandable instance variable names. > > Thierry > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

March 31, 2015

Binding semantics of SystemDictionary

by Max Leske

Hi Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: class := Class new setName: 4; yourself. Smalltalk at: class name put: class. So we now have a class with name 4 (which is a SmallInteger): self assert: (Smalltalk at: 4) == class. There are basically two different issues: 1. SystemDictionary will store any kind of association, not only symbols / strings 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: class := Class new setName: (String streamContents: [ :s | s nextPutAll: 'someName']); yourself. Smalltalk at: class name put: class. Smalltalk at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) ifAbsent: [ false ]. âââ> falseâ In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: 1. Are bindings with keys that are not ByteString or ByteSymbol valid? 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? 3. If we allow ByteString, do we also allow WideString? 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? Any suggestions are welcome. Cheers, Max

March 31, 2015

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

by Sean P. DeNigris

Damien Cassou wrote >> Great! Can we add permalinks for latest for each platform? Then we can >> replace the CI links in the instructions e.g. on StHub... > please do. I tried but the files don't seem to be copied over to files.pharo.org, even though the console suggests that they are. Additionally, the "cp $generated_dmg.md5sum latest.md5sum" does seem to generate an artifact even though the console doesn't say anything about failing... ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Pharo-Launcher-package-for-Mac-and-Windows-tp4815… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 31, 2015

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

by Damien Cassou

Cyril Ferlicot <cyril.ferlicot(a)gmail.com> writes: > On 31 March 2015 at 17:22, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Ben Coman <btc(a)openinworld.com> writes: >> >> > Regarding Windows... Last that I looked, the PharoLauncher image is >> > installed into the "Program Files" System Folder. This causes a problem >> > since when a PharoLauncher Image is saved by a Standard User, they cannot >> > write to the System Folder so Windows *fakes* it and actually writes to a >> > User Fodler, but makes it look like the file is in the System Folder. >> That >> > is, the Standard User is looking at a Fake System Folder!! >> >> that's very strange. Can someone please evaluate this expression on your >> Windows box and give us the result? >> >> PlatformResolver forCurrentPlatform cache > File @ C:\Users\Cyril\AddData\Roaming looks good to me. So, I don't understand Ben's problem. >> > This confused me for quite a while - even as an IT Administrator of 15 >> > years. Its likely to cause chaos and pain for others down the track. So >> I >> > recommend that the installer be changed so that the PharoLauncher Image >> is >> > installed into a User Folder - at least by default, and maybe as the only >> > option. >> >> >> I disagree. The launcher should be installed with other applications. >> But the data is per-user. On Ubuntu, the launcher is happily installed >> under /usr/share/pharo-launcher and images are download to >> ~/.cache/Pharo/images. >> >> > I had meant to fix this in PharoLauncher myself, and also would offer to >> > test it - but unfortunately I currently don't have access to a Windows >> > machine. >> >> I hope someone else will try >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> >> -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 31, 2015