August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Future of Spec

by Martin Saurer

Dear Stef, Dear Pharo Community, Many thanks for answering my question about the future of Spec. What I have done for the J platform, and now will try to do for Pharo is not directly comparable to Phobos (XULrunner) or Cocoa Widgets. At least I think so. If you are interested please take a look at: http://www.jsoftware.com/jwiki/Scripts/qjide The qfe (Qooxdoo Frontend Engine) which is part of the qjide on the J platform is based on the Ajax Framework "Qooxdoo" http://www.qooxdoo.org. The qfe is a JavaScript library which acts like Qt, WinForms, Cocoa, Morphic, etc. for the desktop, but lives entirely in the web browser. The web application itself is written in 100% J (now), or 100% Pharo (in the future). To build a qfe based web application, there is no need to use HTML, CSS, XULrunner, etc. The qfe may be bound to nearly any programming platform which has a web server. Pharo together with the Zinc server is a great environment for creating web applications that use a rich widget set like qfe provides. The final goal will be to create a Pharo GUI extension (probably based on Spec), where applications can be opened like MyGUIApp openInWorld. or MyGUIApp openInWeb. The first one opens a Spec (or Morphic) desktop GUI application in the Pharo window. The second one serves the same application with (nearly) the same look-and-feel as a web application. I will be happy to answer any questions on qfe. Cheers Martin

Aug. 29, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Tudor Girba

Hi, Cmd+o cannot be mapped on Cmd+s because when you are in the code editor of the inspector, you want to both be able to accept the code and open the result of a selection. In the moose image we remove the global bindings altogether, so I would be certainly fine with rebinding them. That is until we find a better solution :) Cheers, Doru On Fri, Aug 29, 2014 at 10:54 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi guys, > > We are on our way to integrate (finally) GTools into Pharo. > For now it will be the Playground and the Inspector, since the Debugger is > still not ready. > > Now, Iâm facing a problem. The new command for playground (cmd+o) > conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot > handle both, we need to choose one. > I do not have a clear idea, so I want your opinions. > So far, I think this: > > 1) cmd+o in playground is not so clear, maybe we could map thet to an > âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ > 2) we could map cmd+o+etc. to something else. But I do not know to what. > > So, I hear opinions :) > > Esteban > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 29, 2014

Re: [Pharo-dev] about to integrate GTools, there is a command conflict who needs attention

by Tudor Girba

Hi, The difference is that Cmd+o will open a new pane on the result. It's like Cmd+i only it does not spawn another window. Doru On Fri, Aug 29, 2014 at 12:34 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-29 12:26 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > >> On 29 Aug 2014, at 12:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> > >> > On 29 Aug 2014, at 12:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> I have no idea what current (cmd+o+[w|t|etc]) stands for, so for me >> itâs ok to trash it. >> > >> > ehhhh, we are not talking about trash itâ¦ just remapping if needed :P >> > and those are commands for opening transcript, workspace, etc. >> >> oh, then this is useful :) >> >> > >> > Esteban >> > >> >> >> >> I think that cmd+s can make sense. >> >> >> >> And as we are here, Iâd like to point out that I donât like this >> shortcut chains. Iâd prefer to have cmd+x to remove what is currently >> focused rather then >> >> cmd+c+x, cmd+m+x and so on. >> >> >> >> Uko >> >> >> >> On 29 Aug 2014, at 11:54, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> >> >>> Hi guys, >> >>> >> >>> We are on our way to integrate (finally) GTools into Pharo. >> >>> For now it will be the Playground and the Inspector, since the >> Debugger is still not ready. >> >>> >> >>> Now, Iâm facing a problem. The new command for playground (cmd+o) >> conflicts with some menyu commands: (cmd+o+[w|t|etc]). Since we cannot >> handle both, we need to choose one. >> >>> I do not have a clear idea, so I want your opinions. >> >>> So far, I think this: >> >>> >> >>> 1) cmd+o in playground is not so clear, maybe we could map thet to an >> âacceptâ (cmd+s) or an âexecureâ (cmd+e)â¦ >> >>> 2) we could map cmd+o+etc. to something else. But I do not know to >> what. >> >>> >> >>> So, I hear opinions :) >> >>> >> >>> Esteban >> >> >> >> >> > >> > >> >> >> > > What's the difference between cmd+o and cmd+d for the Playground? > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 29, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by Esteban A. Maringolo

2014-08-29 8:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 29 Aug 2014, at 12:53, GÃ¶ran Krampe <goran(a)krampe.se> wrote: >> Just for some "food for thought", you may want to read the parts under heading "Literal Smalltalk arrays" and the section following - "Sidestory: Adding literal Dictionaries to Smalltalk?" > Since we had those discussions long ago, I've actually grown quite used to writing > > { #foo->1. #bar->2 } asDictionary > > I know it is not super efficient, or super compact, but I can certainly live with it. Plus, It doesn't require further changes. I got used to it too. BUT... ... I'd also love to have something like #{'foo' -> 1. #bar -> false} :) Esteban A. Maringolo

Aug. 29, 2014

Re: [Pharo-dev] ObjectLiterals thoughts....

by Damien Pollet

Are you considering a form of compile-time expression or quasi-quotes? On 29 August 2014 11:35, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > we are looking at STON and ObjectLiterals with Christophe and for handling > metadata. > > > And I was brainstorming.... I was wondering if it would be possible to have > a bit more use of self evaluating > > for example > 1@3 > #k -> 2 instead of (Association #k 123) > > > my brainstorming is how could we minimize new syntactic constructs and still > support a literal object format. > So object literal cover that so may be this is good. > > 1@3 as (Point 1 3) > and > #k -> 123 as (Association #k 123) > > So I'm not clear but this is interesting to think about it. > I would like to have also a dictionary literal syntax.... but this another > story. > > Stef > > PS: Sven I added support for Association into the ObjectLiteral project to > see how it works. > > > > > > > > > > I took Igor's initial code and created a new project: > > http://smalltalkhub.com/#!/~SvenVanCaekenberghe/ObjectLiterals/ > > and I added ObjectLiteralParser to convert any Character Stream or String > into a Smalltalk Literal Array and eventually into an Object. > > This proof of concept moves the ObjectLiteral format/notation away from the > Smalltalk compiler and will help us discuss more concretely the actual > details of the specification (which is still not 100% finished). > > I also added 12 unit tests and cleaned up the code and comments. > > Please have a look at the code. > > This is one of the tests: > > ObjectLiteralParserTests>>#testMixed1 > | input output | > input := ' > #(Array > 1 > foo > #''foo-#bar'' > true > false > nil > 3.14159 > -100 > ''string'' > (#OrderedCollection 7 8 9) > #(Set 10) > (Dictionary > x 1 > y 2) ) '. > output := { > 1. > #foo. > #'foo-#bar'. > true. > false. > nil. > 3.14159. > -100. > 'string'. > OrderedCollection withAll: #(7 8 9). > Set with: 10. > Dictionary newFromPairs: #(x 1 y 2 ). }. > self assert: (self parserOn: input) nextObjectLiteral equals: output > > I like this format, its simplicity and elegance is appealing, it offers > distinctive advantages in the Smalltalk context while its slight readability > disadvantage is acceptable. Like any format it is a compromise and a > tradeoff, but a rather good one. > > Regards, > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 29, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30856 Home: https://github.com/pharo-project/pharo-core

Aug. 29, 2014

[pharo-project/pharo-core] e4dcdb: 30856

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: e4dcdb646718637bcb03d89564764067ba8f4800 https://github.com/pharo-project/pharo-core/commit/e4dcdb646718637bcb03d895… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-29 (Fri, 29 Aug 2014) Changed paths: M Gofer-Tests.package/GoferResource.class/instance/running/setUpMonticelloRepository.st A Metacello-TestsMCResources.package/MetacelloTestsMCPackage.class/instance/accessing/species.st M NativeBoost-Core.package/NBExternalStructureType.class/instance/emitting code/coerceReturnPointer_.st A NativeBoost-Tests.package/NBFFIExternalStructTests.class/instance/tests/testStructWithPointerAccess.st A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/README.md A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/class/as yet unclassified/fieldsDesc.st A NativeBoost-Tests.package/NBTestStructureWithPointer1.class/definition.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script118.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30856.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30856 13912 backport: 13911: Metacello test packages not properly unload https://pharo.fogbugz.com/f/cases/13912 13725 NativeBoost crashes when reading null pointer field in a structure https://pharo.fogbugz.com/f/cases/13725 http://files.pharo.org/image/30/30856.zip

Aug. 29, 2014

Re: [Pharo-dev] Anonymous classes in Pharo 3 - must be instances of Class, not Behavior

by Oscar Nierstrasz

Thanks for the clarifications! Oscar On 29 Aug 2014, at 14:01 , Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 29 aoÃ»t 2014, at 13:38, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: > >> >> Following up: >> >> Behavior new compile: 't ^ trueâ >> >> fails since #compile: is defined in TBehavior and depends on #basicLocalSelectors which is defined only in Class, MetaClass and TraitBehavior. >> >> It seems like #basicLocalSelectors should be abstract in TBehavior. >> Alternatively the implementation should be moved to TBehavior and the field localSelectors should be pushed up to Behavior. Am I missing something? > > You're right, it should be possible to compile methods into an instance of behavior. > IIRW, it was possible in Pharo 2 but we didn't pay enough attention to ensure that it is always possible. So if we can make it work again we should add your test somewhere for that. > About moving localSelectors to Behavior: I'm not sure that Behavior should be aware of traits. I prefer to keep Behavior minimal (it is already too messy IMO). > Also for Pharo 4 there is other issues introduced by the integration of slots (slots are now needed by Opal for compilation): > - we should move slot API to Behavior > - make sure that iv and format ivs are consistent with each other > So there is some work to be done to make it work again... > >> Oscar >> >> On 29 Aug 2014, at 12:26 , Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> wrote: >> >>> >>> Hi folks, >>> >>> I was updating my lecture on Reflection for the Software Design and Evolution course, and I see now that anonymous classes can no longer be instances of Behavior but must be instances of Class. If you try to compile a method on an instance of Behavior, it fails. (basicLocalSelectors is not understood) >>> >>> Am I missing something? >>> >>> Cheers, >>> Oscar >>> >>> testPrimitiveChangeClassTo >>> | anonClass browser | >>> >>> anonClass := Class new. âmust be Class, not Behavior" >>> anonClass superclass: Browser. >>> anonClass setFormat: Browser format. >>> >>> browser := Browser new. >>> browser primitiveChangeClassTo: anonClass new. >>> anonClass compile: 'thisIsATest ^ 2'. >>> >>> self assert: browser thisIsATest = 2. >>> self should: [Browser new thisIsATest] >>> raise: MessageNotUnderstood. >>> >>> >> >> > >

Aug. 29, 2014

Re: [Pharo-dev] UndefinedObject(Object)>>doesNotUnderstand: #wait

by David T. Lewis

On Fri, Aug 29, 2014 at 11:42:24AM +0200, Yuriy Tymchuk wrote: > Sometimes when I save image I get this error: > > > UndefinedObject(Object)>>doesNotUnderstand: #wait > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] in [ > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... > BlockClosure>>repeat > [ > [ > event wait. > processSynchronizationDelay wait. "Avoids lost signals in heavy process switching" > self changed: #childProcessStatus ] repeat ] in UnixOSProcessAccessor>>grimReaperProcess in Block: [ ... > [ > self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ ... > > > Is it a known problem? Hi Uko, I have not seen this before, but I can say that the error is coming from OSProcess. OSProcess uses a background process that wakes up when a child OS process (that was started earlier by OSProcess) has exited. I do not know the reason for the failure that you are seeing, but I am guessing that it may be somehow related to image shutdown and startup processing when you save the image. Dave

Aug. 29, 2014

Re: [Pharo-dev] Spec wiring

by Yuriy Tymchuk

Yes, thatâs the first thing that I check Uko On 29 Aug 2014, at 12:23, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Have you checked this website: http://spec.st/docs/home/ ? > > > 2014-08-29 10:51 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, > > I need a little help to understand how spec works. Iâve encountered a problem, that when all children nodes of a tree are checked, the parent node remains partially checked instead of going fully checked. Iâve tried to figure out how to work with that, but failed. Any suggestions? > > Uko >

Aug. 29, 2014