- Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

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

Re: [Pharo-dev] Spec Understandability

by kilon alios

> > >> 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 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. You can't work as fast with code for GUI design. Its very slow and this is why GUI designers have been so popular and considered standard practice.

Oct. 21, 2014

Re: [Pharo-dev] Spec Understandability

by Nicolai Hess

2014-10-21 14:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > I may have but then halos have been abandoned in pharo at least > functionality wise , I have not seen any improvement to them from when I > started using Squeak 2 years ago and if I remember there were once a time > you had to enable them in pharo settings. > > Also both a gui builder for squeak and another for pharo have been > abandonware . > abandoned by developers or users? > So it looks pharo is not doing well on GUI front especially when it has to > compete with gui designers in visual basic, visual studio, QT, GTK and many > more. > > more important than a gui designer is actually a gui library/toolkit. glamour, spec, athens, txtext, morph cleanup ... I think pharo does a great job on the GUI front.

Oct. 21, 2014