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

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

Hi Thierry, On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Ah! But! Sista has an advantage that other adaptive optimizers don't. >> Because it optimizes from bytecode to bytecode it can be used during a >> training phase and then switched off. >> > > Great. > > Would it also be possible from the outside to make sista-like > optimisations? I'm thinking of a few possibilities such as replacing some > dictionary constant building code and a few others (i.e. a kind of [ ] once > and the #(( )) of Dolphin) which could be handled at the user level (by > tracking if it has to be recompiled if someone, say, changes the > implementation of Dictionary). > There is no "outside" in Sista. It is an image-level optimizer, so you'll be able to interact with it at the same level one interacts with the Opal compiler. Of course doing this kind of strength-reduction is possible. Real time applications requires an upper bound guarantee in their response >>> time. In some cases, the lack of this guarantee can be just an annoyance, >>> as happens in video games. In some mission critical applications the >>> results can not be good, if this time constraint is not met. An example of >>> a mission critical system could the flight controls of an airplane, or the >>> cooling system of a nuclear reactor. >>> >>> For these application, it is not possible to rely in an adaptive >>> optimizer that can be triggered sometimes. In these application you have to >>> either: >>> - Extend the language to hand optimize some performance critical >>> sections of code. >>> - Use another language to optimize these critical section. >>> - Use another language for the whole project. >>> >> >> The additional option is to "train" the optimizer by running the >> application before deploying and capturing the optimised methods. Discuss >> this with ClÃ©ment and he'll explain how straight-forward it should be. >> This still leaves the latency in the Cogit when it compiles from bytecode >> to machine code. But >> >> a) I've yet to see anybody raise JIT latency as an issue in Cog >> > > How many instructions you spend on average in Cog per generated > instruction? > I have no idea. All I know is that the code generation side of the Cogit is extremely cheap, dwarfed by the costs of relinking when code is recompiled. But the cost is vanishingly small. The costs that do show up in the Cogit are the cost of discarding, compacting and relinking code when the working set grows (e.g. Compiler recompileAll), and pause times here are ~ 1ms on my 2.2GHz MBP; thats about twice the cost of a scavenge, at about 1/20th the frequency (these times are for Spur). If you open up the system reporter you'll be able to see for yourself. And if you use the VMProfiler you can see exactly here the time goes for your favourite synthetic benchmark. See if you can figure out how to create bytecoded methods cheaper than the JIT can compile them and profile it. If you've got a tool that can count instructions let me know and I may measure. I could could bytecodes per instruction generated in the simulator ;-). > b) it would be easy to extend the VM to cause the Cogit to precompile >> specified methods. We could easily provide a "lock-down" facility that >> would prevent Cog from discarding specific machine code methods. >> > > That one is interesting. It sounds like a great benefit would be to have a > limited API to the Cog JIT for that sort of requirements. > > And of course, you have to perform lot of profiling. >>> >> >> Early and often :-). >> >> Because we can have complete control over the optimizer, and because >> Sista is byetcode-to-bytecode and can hence store its results in the image >> in the form of optimized methods, I believe that Sista is well-positioned >> for real-time since it can be used before deployment. In fact we should >> emphasise this in the papers we write on Sista. >> > > I'm not sure of that "real-time" aspect is a good idea. More real-time > than others dynamic optimisers, maybe. Note that Java Real-Time suggest > turning off JIT and switch to ITC. > But thats because in Java VMs the adaptive optimizer is in the VM where one has limited control over it. Sista is different. > > The word you're looking for there is AoT Compiler :) > In fact a better term would be an interactive compiler ;-) Regards, > > Thierry > -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

On Tue, Sep 16, 2014 at 2:19 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: > > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre < > sebastian(a)flowingconcept.com>: > > > >> Well, a while ago in the business list Iâve raised the idea that making > >> Pharo able to do native OS windows would help it to gain market space > (as in > >> the opposite of staying at the margins of it). > >> > >> So, Iâd be very positively curious about being able to use Pharo to do > >> multiplatform native apps > > > > The trend is shifting to mobile devices, iOS and Android are eating > > the whole market. So if it is about the potential market size, native > > mobile (tablets/phones/TVs) should come as the first option, before > > desktop. > > +1. Desktop apps are "dead" aren't they? I'm doubtful that native > windows would help Smalltalk's popularity, as evidenced, I guess, by > the fact VA and VW have supported them for a long time; did they take > over the world yet? > > > For development, native windows could prove very useful. > > How so? For me, one of the worst aspects of trying to develop in > VisualAge or VisualWorks *is* the multiple host windows. It makes it > virtually impossible to work in more than one image, and reinforces > the "grand cathedral" thinking about Smalltalk; e.g. you're not > supposed to want or need anything outside your one, true, image. > Dinosaur! > > I constantly work in multiple images, not only for separate projects > but for the ability to quickly and easily fork images for multicore > processing on the same project. Other times simply to try something > temporary and possibly dangerous. The memory isolation is critical > for productivity, the UI isolation for usability, and the multi-core > capability for performance. > > I think we should focus on how to move to more and smaller > intercommunicating images rather than one big image. I understand its > appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware > of any other use-cases where multiple host windows would be preferable > to one host window per image. > That all makes sense from an experienced Smalltalker's POV. But for people exploring the technology the lack of native windows is usually a huge turn-off and often reason to reject the technology. The nice thing about Vassili's work is that it allows one to have *both*, without losing window state, and one can switch dynamically, and, IIRC, mix both, e.g. for development. So it isn't an exclusive choice. Re VisualWorks' support for native windows it was an essential component to VW staying in the market-place. If it hadn't supported native windows it would have died the commercial death long ago. Pre-web, one /had/ to have native windows for industry, and now with mobile native look and feel is even more important. Further, VWs huge lack in its GUI was lack of support for native widgets. We always used to tout MSWord's use of emulated widgets (apparently for performance reasons) as a defence but it didn't convince. The customer was always provided with poor emulations and a limited supply. IMO, native widgets would have made a big difference in hwo well-received VW was for GUI applications, where those using Windows could always turn to VSE. -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [squeak-dev] re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

Hi Kilon, On Tue, Sep 16, 2014 at 5:38 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > The problem with relying for everything on smalltalk code and not using > existing technology is two fold > > a) You cannot compete with existing solution, they come with more manpower > , have more features, better documention, more bug fixes, more, more ...... > more > > b) One day the authors of the library decide to give up on the library > because they went off to other things and of course it falls to the > shoulders of others that are much less motivated and have other things in > their plate too with higher priority for them. The library continues to > improve but at a glacial pace. > > Its perfectly ok to try your own things and follow your own road. Everyone > loves to experiment and do things his own way and that has many positive. > But the general refusal to embrace existing technologies even problematic > ones make the job of spreading the Smalltalk appeal much harder. Makes it > harder for people to transition from other languages too. > > This smalltalk mentality is wrong. The end. > I don't understand how your comment relates to the below. Can you fill in the gaps? > > On Tue, Sep 16, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Craig, >> >> On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <craig(a)netjam.org> wrote: >> >>> >>> > I don't think anybody ever even reported trying [Ffenestri]. >>> >>> I did; it worked. And I just said so again a few messages ago. Hm. >>> >> >> OK. It opens windows. But a snippet in a workspace can do that. It >> does not constitute a replacement for the current window system though does >> it? But Vassili's work can be. We had it in production at customer sites. >> We could use it for development. It was complete, in the sense that one >> could open arbitrary system windows as native windows, switch them back to >> "virtual" windows, snapshot etc and everything would keep working. That's >> "working". With great respect to Tim and John, their work in Ffenestri is >> not the same thing, is it? By the same criteria I don't think what Qwaq >> did constituted a real system; it allowed the login WIndow to be displayed >> natively, but it didn't support development tools and it certainly didn't >> support snapshot or dynamic switching. Being critical is not being >> insulting. It's merely being objective. At least I hope I'm being >> objective and not insulting anyone. It is not my intent. >> >> -- >> best, >> Eliot >> > > -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Chris Muller

On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > >> Well, a while ago in the business list Iâve raised the idea that making >> Pharo able to do native OS windows would help it to gain market space (as in >> the opposite of staying at the margins of it). >> >> So, Iâd be very positively curious about being able to use Pharo to do >> multiplatform native apps > > The trend is shifting to mobile devices, iOS and Android are eating > the whole market. So if it is about the potential market size, native > mobile (tablets/phones/TVs) should come as the first option, before > desktop. +1. Desktop apps are "dead" aren't they? I'm doubtful that native windows would help Smalltalk's popularity, as evidenced, I guess, by the fact VA and VW have supported them for a long time; did they take over the world yet? > For development, native windows could prove very useful. How so? For me, one of the worst aspects of trying to develop in VisualAge or VisualWorks *is* the multiple host windows. It makes it virtually impossible to work in more than one image, and reinforces the "grand cathedral" thinking about Smalltalk; e.g. you're not supposed to want or need anything outside your one, true, image. Dinosaur! I constantly work in multiple images, not only for separate projects but for the ability to quickly and easily fork images for multicore processing on the same project. Other times simply to try something temporary and possibly dangerous. The memory isolation is critical for productivity, the UI isolation for usability, and the multi-core capability for performance. I think we should focus on how to move to more and smaller intercommunicating images rather than one big image. I understand its appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware of any other use-cases where multiple host windows would be preferable to one host window per image.

Sept. 16, 2014

Re: [Pharo-dev] AppeX

by Thierry Goubier

Hi Doru, I'm looking through it. Interestingly simple :) You do have the styler inside another styler stuff working (smalltalk code styler inside a Pillar code bloc) which is very neat. Thierry Le 15/09/2014 06:44, Tudor Girba a Ã©crit : > Hi, > > As you could see in the Pillar highlighting support, Rubric can now > handle any syntax highlighting in a rather straightforward way. You > can also easily embed this in a Glamour browser. > > You can see the example in the GT-InspectorExtensions-Pillar. You can > load the code in a Moose image like this: > Gofer new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration; > loadStable. > Gofer new > smalltalkhubUser: 'JanKurs' project: 'PetitParser'; > configurationOf: #PetitParserIslands; > load. > #ConfigurationOfPetitParserIslands asClass loadDevelopment. > Gofer new > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load. > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 16, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Tudor Girba

Great! I will go over it more thoroughly in the following weeks and get back to you with feedback. Cheers, Doru On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Dear all, > > We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro > Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for > Pharo) and Hapao2. > Hapao2 is about assessing the test coverage of your code and is a major > revamp of Hapao1, which was presented a couple of years ago by Vanessa. > Hapao2 does not only list covered and uncovered methods, as most test > coverage tool on Earth will do. Hapao gives a great visualization to easily > navigate in your code, assess its complexity, and give you a great visual > output telling its coverage. > > You need Roassal in your image: > > Gofer new smalltalkhubUser: 'ObjectProfile' > project: 'Roassal2'; > package: 'ConfigurationOfRoassal2'; > load. > (Smalltalk at: #ConfigurationOfRoassal2) load > > > and you need S2py: > MCHttpRepository > location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' > user: '' > password: '' > > > New entries will appear in the world menu: > > > You can run the test coverage on : > - the class classes you have modified, > - on a particular > - on a particular class category > - on the last class categories you have modified > - on the last packages you have modified > > Here is a portion of a large coverage: > > > A technical description of Hapao may be found on > http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf > > We are daily using Hapao to help us understand our tests. > > Cheers, > Ricardo, Alejandro & Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 16, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Esteban A. Maringolo

2014-09-16 14:37 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > Well, a while ago in the business list Iâve raised the idea that making > Pharo able to do native OS windows would help it to gain market space (as in > the opposite of staying at the margins of it). > > So, Iâd be very positively curious about being able to use Pharo to do > multiplatform native apps The trend is shifting to mobile devices, iOS and Android are eating the whole market. So if it is about the potential market size, native mobile (tablets/phones/TVs) should come as the first option, before desktop. For development, native windows could prove very useful. Regards!

Sept. 16, 2014

Re: [Pharo-dev] Looks like implementors in smart suggestion does not work anymore

by stepharo

removing SugsNautilusContext>>tools fixes the problem but may be it open new ones On 16/9/14 20:49, stepharo wrote: > Hi > > can somebody confirm? > in Nautilus in text pane implementors in smart suggestion does not > work anymore > > Stef > >

Sept. 16, 2014

Re: [Pharo-dev] DateModel not working in 3.0

by stepharo

Super we will have a look, just buzy buzzy buzzzy > Sean P. DeNigris wrote >> Will someone please review... > Ready to integrate in 3.0 - merges and passes manual test > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/DateModel-not-working-in-3-0-tp4778355p4778420.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 16, 2014

Looks like implementors in smart suggestion does not work anymore

by stepharo

Hi can somebody confirm? in Nautilus in text pane implementors in smart suggestion does not work anymore Stef

Sept. 16, 2014