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

[pharo-project/pharo-core] c9ddee: 40318

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c9ddeec02d7b62c2dfead6d52527427d68a4bad3 https://github.com/pharo-project/pharo-core/commit/c9ddeec02d7b62c2dfead6d5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-22 (Wed, 22 Oct 2014) Changed paths: A KeyChainTest.package/ManifestKeyChainTest.class/README.md A KeyChainTest.package/ManifestKeyChainTest.class/class/meta data/rejectClasses.st A KeyChainTest.package/ManifestKeyChainTest.class/class/meta data/rejectRules.st A KeyChainTest.package/ManifestKeyChainTest.class/class/meta data/ruleLongMethodsRuleV1FalsePositive.st A KeyChainTest.package/ManifestKeyChainTest.class/definition.st A KeyChainTest.package/PharoUserPermissionsTest.class/README.md A KeyChainTest.package/PharoUserPermissionsTest.class/definition.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanBrowse.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanDebug.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanDropOSFile.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEditCode.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEditUser.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEvaluateCode.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanInspect.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanRunStartupScript.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanSaveImage.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanShowMorphHalo.st A KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testIsRoot.st A KeyChainTest.package/PharoUserTest.class/README.md A KeyChainTest.package/PharoUserTest.class/definition.st A KeyChainTest.package/PharoUserTest.class/instance/tests/testUsername.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToGroupAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToMCAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToSystemAnnouncements.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToTestAnnouncements.st A NetworkTests.package/UDPSocketEchoTest.class/README.md A NetworkTests.package/UDPSocketEchoTest.class/definition.st A NetworkTests.package/UDPSocketEchoTest.class/instance/accessing/localhost.st A NetworkTests.package/UDPSocketEchoTest.class/instance/accessing/port.st A NetworkTests.package/UDPSocketEchoTest.class/instance/private/receiveUDPDataFrom_.st A NetworkTests.package/UDPSocketEchoTest.class/instance/private/withUDPEchoServer_.st A NetworkTests.package/UDPSocketEchoTest.class/instance/testing/clientSend_.st A NetworkTests.package/UDPSocketEchoTest.class/instance/testing/runServer.st A NetworkTests.package/UDPSocketEchoTest.class/instance/testing/testEcho.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script318.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40318.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40318 14276 Add UDPSocketEchoTest test/example https://pharo.fogbugz.com/f/cases/14276 14222 Tests around KeyChain https://pharo.fogbugz.com/f/cases/14222 14281 Replace Announcer>>#on:send:to:s senders in Nautilus https://pharo.fogbugz.com/f/cases/14281 http://files.pharo.org/image/40/40318.zip

Oct. 22, 2014

Clickable class side example and initialize methods in Pharo 4.0

by Torsten Bergmann

One addition I implemented for Nautilus is that one can run examples directly in the browser just by clicking on class side example methods icons. See https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-… for a picture. SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE CLASS SIDE AND LET THE SELECTOR START WITH "example". This way people will easily see that it is an example and can run them. Additionally it would help to put them into a category like "examples". So be a good citized and provide not only class comments but also examples for others to study. Side note: ========== It is also possible to click on the icon of class side initialize methods so the class get reinitialized (after a confirmation to avoid false clicking). https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-shoul… Both issues are already integrated.

Oct. 22, 2014

Re: [Pharo-dev] Smalltalk running on Dart VM?

by ClÃ©ment Bera

2014-10-22 4:34 GMT+02:00 askoh <askoh(a)askoh.com>: > Dart is climbing in popularity. And Dart VM is going to be built into > Chrome. > Would it be advantageous to run Smalltalk on the Dart VM ? Since Dart is > very Smalltalk like, wouldn't it be relatively easy? > > Hello, I think Ryan Macnak is working on having NewSpeak, which is a smalltalk-like language, running on the Dart VM. The typical problems to run smalltalk on other VMs are how to implement this list of features with good performance: - non local return - become: - thisContext Not having become means you cannot add an instance variable to a class that has instances (Of course you could get it right from the first time you created the class :) ) and means no database proxies. Non local returns can be implemented using exceptions but in this case it is usually slow (VMs such as hotspot optimizes exceptions, if the Dart VM does it, then it may be ok). Not having thisContext means that you need to implement Continuations, Exceptions and the Debugger differently. If the language features Continuations and Exceptions, these two features can probably directly be mapped. The debugger can probably be mapped to the other VM debugging features too, admitting they have as much. But what happen when you edit the top method in the debugger, can the new VM use this method in the top context instead even if you do things such as adding literals or temporaries ? Then there are little details such as what do happen when you compile and install a method at runtime (I'm talking about the Smalltalk IDE) ? Is everything compliant and fast ? I think there are guys working on the Dart VM that worked on a smalltalk VM before (I'm thinking of Gilad Bracha and Lars Bak). To go in that direction one should ask them what they think about it and how they would implement these 3 features. You can also ask Ryan Macnak about what he is doing. Regards, Clement > Thanks, > Aik-Siong Koh > > -- > View this message in context: > http://forum.world.st/Smalltalk-running-on-Dart-VM-tp4785841.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 22, 2014

Re: [Pharo-dev] Inspector for Opal IR -> source mapping

by Marcus Denker

> On 21 Oct 2014, at 20:35, kilon alios <kilon.alios(a)gmail.com> wrote: > > great work Marcus , look like GT tools have a huge potential . Would that work with a debugger too ? > This code directly not. But GT contains a debugger, too (which is not yet ready for Pharo4). I think the this âmoldable debuggerâ should help with building a bytecode-level (or AST, IR) debuggerâ¦ but I have not yet looked into that. Marcus

Oct. 22, 2014

ProtoObject/Proxies

by Esteban A. Maringolo

I've been hit by a few side effects of using proxies (GLORP ones), because some tools like the Debugger and/or inspectors expect some objects to respond to methods not defined in ProtoObject. I discovered this by accident because looking at the stack in the xterm console I saw a recursion triggered by a halt in UnitOfWork>>#register: Such halt caused errors that needed to be printed, and because it was trigger in the context of a Proxy, boom, infinite recursion. Why such methods are not implemented in ProtoObject, or at least with a "basic" version of it. Is this by design? Methods like #shouldBePrintedAsLiteral or #isSelfEvaluating (don't know what it means), along others like #printStringLimitedTo... etc. I remember Steph said a better support for Proxies was in the was roadmap, how far is that? What can be done to speed this up? Debugging a proxy object (even one that doesn't use #become:) is really tricky. If you look at the implementation of Glorp's Proxy>>#class it seems it should answer the class of the proxied object (if materialized), but all that is commented out returning the receiver class, it is returning Proxy. If you uncomment that weird things happen. I'll come back to this later, once I have time to reproduce it. Please don't forget not everything inherits from Object :) Esteban A. Maringolo

Oct. 22, 2014

Smalltalk running on Dart VM?

by askoh

Dart is climbing in popularity. And Dart VM is going to be built into Chrome. Would it be advantageous to run Smalltalk on the Dart VM ? Since Dart is very Smalltalk like, wouldn't it be relatively easy? Thanks, Aik-Siong Koh -- View this message in context: http://forum.world.st/Smalltalk-running-on-Dart-VM-tp4785841.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 22, 2014

Re: [Pharo-dev] Spec Understandability

by HernÃ¡n Morales Durand

2014-10-21 16:51 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > >>> I didn't check but I wonder how they perform with resizing layouts? Do >> they use spacers? Do they use constraints? >> >> >>> >>> > I don't know/ remember for the other 2 (I have used them a couple of times > long time ago) but Lazarus is basically an open source recreation of Delphi > so those are pretty standard features. Even the standard library of Delphi > has been ported to Lazarus / Free Pascal and it directly support specific > Delphi versions. What you describe are standard features for most if not > all GUI designers anyway. > > In Delphi I vaguely remember they were called anchors, you could pin them > on a specific layout or choose sides or pin them in absolute positions > though the last option was the least desirable if you wanted an easily > resizable interface but overall you had tons of options. > > I remember too but in those builders you mention you were not using constraints, you are just aligning by snapping widgets. Most GUI builders do not include a built-in constraint-based solver. They are difficult to implement, and maintain (over-constraints are a symptom of a tedious UI design process too). High-level constraints for automatic layout is a relatively active research topic. > I remember the Delphi ("Mastering Delphi 6") book have once bought around > 1000 pages , I still have it with me, 300 pages was the designer itself. > But I dont count in the overall architecture where everything worked with > drag and drop. So basically if you wanted to add a database engine inside > your app , the engine was represented as a GUI button you drag and drop on > top of the form of your app like any other GUI element but of course it was > not visible when you run the app. > > Delphi is minimising code this way which is paradigm that Lazarus follows > very closely too. So the designer went and still is going far beyond to > just designing GUIs. > > Of course I dont expect something of such power in Pharo, actually not > even Visual Studio has been able to compete with Delphi in RAD (Rapid > Application Development) or even its main competitor Visual Basic. Borland > was very powerful and quite well funded company with very big experience on > programming languages and IDEs. Unfortunately like Visual Basic they lost > traction when Java came out and Delphi was sold to a much smaller company. > But still Delphi is quite popular. On the other hand modern IDEs do have > many of these features. > > I was mainly talking about basic GUI designers. Draging , droping, > resizing, setting layouts and constraints and at least having access to > basic widgets for fast creation of GUI is absolute essential for a GUI > based IDE like Pharo. > > Agree, but if your priority is having a GUI Builder, Pharo is not the best choice today. But you have MT GUI Builder, Smalltalk/X GUI Painter, Cincom GUI Painter Tool, Dolphin View Composer, etc. Cheers, HernÃ¡n

Oct. 21, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Eliot Miranda

On Tue, Oct 21, 2014 at 1:02 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The more I tried to change/fix the compiler and checking the failing > testcases, > the more I learn about it. > Finally I think the compiler and testcases are mostly right and my > understanding was wrong. > > My (wrong) assumptions were: > - the "numTemps" in the method header is always the number of declared > temps, regardless whether they end up in an indirection vector > Ah, no. It is the sum of the arguments and the local temporaries. So it is the position to set the stack pointer to on activating a method. > - the inlined ifTrue: and the inlined whileTrue: blocks are handled the > same way, > > both assumptions are wrong: > A method that starts with > foo > | a b c| > > and all temps end up in an indirect vector has only 1 tempvar, the > "indirection vector" and even "numTemps" in the method header is 1. > > ifTrue and whileTrue are handled differently for example in this case > > |a| > a:=1. > (...) ifTrue:[ > ... assign to "a" > ... create a block which uses "a" > ] > > the block only needs a copy of "a", as it is not changed after the > creation of the block > Right. > > |a| > a:=1. > [...] whileTrue:[ > ... assign to "a" > ... create a block which uses "a" > ] > > here we need a indirection vector, because the while-block *can* loop > repeatedly and change the value of "a" after > an block was created. > Right. In general the compiler cannot tell whether the whileTrue: will be executed 0, 1 or many times. In cases where it can tell it would take lots of machinery to do so and only be able to tell in relatively few cases. So the compiler always assumes the whileTrue: is evaluated more than once, and hence that it is possible for a block to be created and a modified in a subsequent iteration of the loop. Hence it must put a in an indirection vector. > If this is all correct, there is only one problem in this special case (my > example above): > If there is no assignment within the loop at all, there is no need to > create a indirection vector and > all used vars (a b c) can just be copied. > > > Or am I still confused ?! > No you're not. You get it now :-). One question is whether you can explain it all better than I did on my blog, because people seem to find this area of teh system hard and take a while to "get it". nicolai > -- best, Eliot

Oct. 21, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Nicolai Hess

The more I tried to change/fix the compiler and checking the failing testcases, the more I learn about it. Finally I think the compiler and testcases are mostly right and my understanding was wrong. My (wrong) assumptions were: - the "numTemps" in the method header is always the number of declared temps, regardless whether they end up in an indirection vector - the inlined ifTrue: and the inlined whileTrue: blocks are handled the same way, both assumptions are wrong: A method that starts with foo | a b c| and all temps end up in an indirect vector has only 1 tempvar, the "indirection vector" and even "numTemps" in the method header is 1. ifTrue and whileTrue are handled differently for example in this case |a| a:=1. (...) ifTrue:[ ... assign to "a" ... create a block which uses "a" ] the block only needs a copy of "a", as it is not changed after the creation of the block |a| a:=1. [...] whileTrue:[ ... assign to "a" ... create a block which uses "a" ] here we need a indirection vector, because the while-block *can* loop repeatedly and change the value of "a" after an block was created. If this is all correct, there is only one problem in this special case (my example above): If there is no assignment within the loop at all, there is no need to create a indirection vector and all used vars (a b c) can just be copied. Or am I still confused ?! nicolai

Oct. 21, 2014

Re: [Pharo-dev] Configurations and Github for a specialised configuration browswe

by kilon alios

Thank you Dale very much , this is very clear :) On Tue, Oct 21, 2014 at 10:53 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On Tue, Oct 21, 2014 at 12:04 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> Thank you Dale, this is more simple than I expected. >> >> From what you linked it looks like by [:comitish] you mean the git branch >> .Which in my case is master so it should be >> >> Metacello new >> baseline: 'BaselineOfXXX'; >> repository: 'github://kilon/phEphestos:master/' >> get; >> load. >> >> https://github.com/kilon/phEphestos >> > > From looking at your repo on githug, the expression would be: > > Metacello new > baseline: 'Ephestos'; > repository: 'github://kilon/phEphestos:master' > get; > load. > > A commitish is a branch, SHA or tag. Note also, that my example was wrong > ... the 'BaselineOf' shouldn't be used in the baseline: argument, just the > base name of the project. > > You also need to create a BaselineOfEphestos which specifies package load > order. BaselineOfEphestos would be created as a subclass of BaselineOf and > have a single method: > > baseline: spec > <baseline> > spec > for: #pharo > do: [ > spec package: 'Ephestos' ]. > > Then the above expression would load the Epestos package. > > If you were to add another package, say EphestosTests, then you'd update > the baseline to declare that EphestosTests requires Ephestos to be loaded > first you'd edit the baseline: method: > > baseline: spec > <baseline> > spec > for: #pharo > do: [ > spec > package: 'Ephestos'; > package: 'EphestosTests' with: [ spec requires: #( 'Ephestos' ) > ] ]. > > You commit the BaselineOf along with the rest of the packages for your > project ... > > For more information see the Metacello chapter in Pharo by Example... > > Dale > > > > >

Oct. 21, 2014