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

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

by Thierry Goubier

Hi Eliot, Le 17/09/2014 00:12, Eliot Miranda a Ã©crit : > Hi Thierry, > > On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > 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. Ok. I'll have a look and maybe profile a bit; SmaCC has plenty of those optimisations that I had to remove in the Pharo port, and I should have a look on the cost of doing all thoses Character value: XXX and ^ Dictionary new... I also had nice optimisations in VW for my trace tool (like replacing a class lookup by a Literal which was then replaced by the singleton instance in the method bytecode) which do not have any effect in Squeak/Pharo anymore. > 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. I have colleagues in the same department working on localized, template based JiT of computational kernels and they do 3 inst of JiT for one instruction (and prove that they go faster on some matrix math code, including the JiT overhead, than anything statically optimised off-line). At the same time, a one ms pause at 2.2GHz is a hell of a long time if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at 25 MHz. > 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 ;-). I used some of the intel cycle CPU counters in the past to benchmark code. I'll ask around for accessing Intel's cycle count registers. I'm sure the Bochs x86 simulator has those. > 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 problem is that even a simple JiT is considered too much Jitter :) The Ocaml guys told once they had to do a special, interpreted VM for a real-time use case. The problem is not going fast, the problem is being predictable. They turn off CPU caches in some cases. Thierry

Sept. 17, 2014

Re: [Pharo-dev] [ANN] Pharo Sprint Lille 26th september

by Marcus Denker

On 17 Sep 2014, at 16:25, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Where: http://rmod.inria.fr/web/contact > Ups, yes, this is the correct links. > > 2014-09-17 16:24 GMT+02:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > RMoD > > The requested object /web/pier/contact was not found on this server. > > You might want to try one of these options: > > Click on a link on this site. > Jump to the RMoD homepage. > If you typed the page address, make sure that it is spelled correctly. > > 2014-09-17 15:10 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > What? Pharo Sprint > When? Friday, 26th September, starting at 10:00am > > Where? > RMoD, Inria Lille, Building B, third floor > http://rmod.lille.inria.fr/web/pier/contact > > As the building is not open to the public, please contact > us before if you plan to come. > > > >

Sept. 17, 2014

Re: [Pharo-dev] AppeX

by Thierry Goubier

Le 17/09/2014 06:08, Tudor Girba a Ã©crit : > Hi Thierry, > > Thanks for the feedback. > > Indeed, the styling part works fine. What I do is have a first level > parser that creates commands for styling. When I detect a Smalltalk > block, the command delegates further to Shout. > > I guess that this type of design will be useful also for handling > Helvetia multi languages. Yes. Is Helvetia still active or are most of its components moved/incorporated in Moose? I had a look because I have to work on DSL for the next few weeks / months. > But, we still cannot have actions that are segment specific :). Why? As soon as you have a parser that can structure the contents (build a tree of it), then it's easy to have specific actions. Unless you're talking of segment specific keyboard shortcuts (and even those could be accomodated). > I would > love to be able to have some sort of composite editor where the leaf > editors correspond to a segment. Yes, it sounds like a reasonable vision. But hard when you consider the fact that editing the text may make it flow between segments (and hence between editors). Copy/paste of text over segment boundaries (or simply selection) could really be a challenge. This is why StÃ©phane doesn't like my vision of a code editor which displays and edit an ast instead of a text understood by a parser. Now we should really have enough text display capabilities to display nicely formatted pillar documents as documentation. The current Help format is ... very nicely minimalistic :( Thierry

Sept. 17, 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:55 PM, Chris Muller <ma.chris.m(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. > > Ah, good. Choice is good. :) > > > 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. > > Yes, I don't doubt that at all, especially during the time when > Windows NT / XP was the defacto platform one could expect anywhere and > everywhere. > > I am curious now, however, in this technologically-splintered world > where Windows XP dying out, Windows 7 barely hanging on, everybody > hating Windows 8, and the promise of cheap upgrade to Windows 9, Plus > don't forget OSX widgets and then all the "widgets" people use on > their phones and tablets being basically different from app to app: > what IS "native" widgets these days? Native widgets means simply use of the platforms native widget set in constructing user interfaces. I don't dsee different widgets across iOS devices. I see lots of consistency. > I wonder what those manager > folks who shunned the > non-native-but-perfectly-usable-and-in-some-cases-better widgets are > asking for now? :) > I assume good looking applications using native widgets in the host look-and-feel that follow the platform's style and usability guidelines. Thats a reasonable request. Look at how coherent and well-engineered the interface components in something like Apple's iOS is are and one soon realises one the one hand the interface quality is high and on the other that the only feasible way to construct interactive applications in that context is to build it out of those widgets, not emulate, not provide an alternative. There are exceptions, e.g. parts of games where all one needs is touch events and all imagery is custom. But for stereotypical interaction one surely has to use native widgets. -- best, Eliot

Sept. 17, 2014

Interesting Date/Time Thread on Squeak Dev

by Sean P. DeNigris

From http://forum.world.st/Could-we-have-1-api-that-work-across-all-of-the-datis… : On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <[hidden email]> wrote: On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham <[hidden email]> wrote: > Ok. > > Date today + 15 days > Date today + 1 day > ((Date today + 1 day) - Date today) days > > That works. So, does this mean that we should deprecate the following > methods in Date so that the observed API doesn't confuse future users? > #addDays:, #addMonths:, #subtractDays:, #subtractDate: ? Well, you won't be able to replicate #addMonths: with the binary operators, because how long is "1 month?" And if we have addMonths: then it follows that we would have addDays: and addYears: for consistency (I see I have addYears: added in my own personal core-extensions package). Actually, you can add 1 month and 1 year, if you want. I have proposed alterations in the InBox that does this - Kernel-cbc.870 and Collections-cbc.582 (the later of which does not include Collections-cbc.581). These collections change #+ in DateAndTime to double-dispatch to the operand, sending the method #addToDateTime:. This does the same logic on all objects the previously could be added to a DateAndTime (as tested in KernelTests-cbc.277). This allows the introduction of GenericMonth and GenericYear, so that we CAN do things like DateAndTime now + 4 months This 'GenericMonth' simple holds the number of months that you want to add (or subtract), and then does the appropriate addition of days based on the DateAndTime. It handles different sizes of months, and leap years, just fine. SImilarly for GenericYear. It does make some assumptions on what a 'month' is. 1: If you add a month, you want the result to be in the next calendar month, never the following one. 2: If you add a month, you want the same day of the month if possible, and if not (becaue the next month has less days), then the closest that you can get to it. 3: Similarly, if you subtract a month, you want it in the previous calendar month, and as close to the starting day of the month as you can get. 4: If you add more than 1 month, you want to end up in the right calendar month that you would expect, and as close to the starting day of the month as you can. 5: Similarly with years - next year, same month, same day (or as close as you can get - February is fun!); same for subtracting. So, adding 1 month to August 31 would give September 30th; adding 2 months to August 31 would give October 31st. And adding 1 month to September 30th would give October 30th. I did this because I think a desired API should be as complete and consistent as we can get it - I really didn't like having to mix the two (or more) styles: DateAndTime now + 1 day DateAndTime now addMonths: 1 -cbc ----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2014

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

by Sean P. DeNigris

Esteban A. Maringolo wrote > I don't see the > advantage of Morphic/Custom drawn UI over traditional widgets, even > HTML widgets. >From an "IDE for business apps" perspective, there may be little. But I only find "Pharo is a better IDE" moderately interesting. The blue plane idea is that Pharo is a Dynabook implementation. Here uniformity, liveness, and directness make all the difference in the world *. For example, as a brand new Smalltalker, I hated that the dialog window for adding a new directory repo in the MC Browser always started in a standard directory. Since I always use the same root repo folder, this required extra work for me to navigate there every time. But how to start implementing this? Morphic provided the answer... to my dreams! Instead of asking on the list, hunting around the system code for a hook, or reading through documentation, like I would in almost any other system *I was able to do the same thing I would do to understand a physical object in the real world*!! I "took apart" the +Repository button and figured out how it worked by bringing up the halos, inspecting the model, and the button action was revealed for understanding and modification. As important as it is to find "what Pharo is good for" in the pink plane, I have certainly not invested so much time, energy, and emotion for incremental improvement, and would find a system without beautiful blue plane ideas like Morphic (or a successor that sticks to its principles) much less interesting. * My concern with Spec is that huge layers of symbol interpretation logic subvert these properties ----- Cheers, Sean -- View this message in context: http://forum.world.st/The-Dilemma-Building-a-Futuristic-GUI-for-Ephestos-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2014

Re: [Pharo-dev] Monticello superslow/freezing

by kilon alios

nope it was not your mistake thats the default, I have been experiencing slow downs as well. Maybe filetree is to blame here, I am using it as well . On Wed, Sep 17, 2014 at 12:24 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I think that I've found why it got slow like that. > > I had the store diff instead of full versions (mistakenly selected I > guess) and switching things back did the trick. > > What's that option? Never noticed it and it for sure hurt or plain doesn't > work. > > Phil > > > > On Wed, Sep 17, 2014 at 11:18 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Is it caught in a kind of loop trying to find the base version? Scanning >> through the ancestors and adding all those to the package cache? >> >> Thierry >> >> 2014-09-17 11:07 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> Filesize is around 1MB. >>> >>> Here is what I do get in the debugger when stopping. >>> >>> TIA >>> Phil >>> >>> >>> >>> >>> On Wed, Sep 17, 2014 at 11:02 AM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> Hi Phil, >>>> >>>> how large is your package? We talked about very large packages with >>>> Sebastian Sastre not so long ago. >>>> >>>> Can you interrupt it to see where it is stuck? >>>> >>>> Thierry >>>> >>>> >>>> 2014-09-17 10:26 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>> >>>>> Monticello kinds of freezes my image for a *very* long time. >>>>> Long, meaning that it never completes I guess. >>>>> >>>>> Memory use shoots through the roof. >>>>> >>>>> What could cause that? >>>>> >>>>> I have been saving more than 200 versions of my package. >>>>> >>>>> Thanks for some advice from the trenches. >>>>> >>>>> Phil >>>>> >>>> >>>> >>> >> >

Sept. 17, 2014

Versioner does not work on Pharo 4

by kilon alios

So I tried today to open versioner to make a configuration for Ephestos and i got this error RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode EphPyParser class(Object)>>mustBeBooleanInMagic: EphPyParser class(Object)>>mustBeBoolean MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: EphPyParser class(Object)>>mustBeBooleanInMagic: EphPyParser class(Object)>>mustBeBoolean [ :cl | (answer includes: cl) ifFalse: [ (([ cl isMetacelloConfig ] on: Error do: [ :ex | ex return: false ]) and: [ cl name asString beginsWith: 'ConfigurationOf' ]) ifTrue: [ answer add: cl ] ] ] in MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | ... OrderedCollection>>do: MetacelloProjectRegistration class>>configurationClasses MetacelloToolBox class>>configurationClasses MBConfigurationRoot>>configurationClasses MBConfigurationRoot>>configurations VersionnerSpecBrowser class>>imageConfigurations VersionnerSpecBrowser class>>open [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser class>>menuCommandOn: in Block: [ VersionnerSpecBrowser open ] BlockClosure>>cull: [ | selArgCount | "show cursor in case item opens a new MVC window" (selArgCount := selector numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount = arguments size ifTrue: [ target perform: selector withArguments: arguments ] ifFalse: [ target perform: selector withArguments: (arguments copyWith: evt) ] ]. self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: ToggleMenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using:

Sept. 17, 2014

Re: [Pharo-dev] [ANN] Pharo Sprint Lille 26th september

by Santiago Bragagnolo

Where: http://rmod.inria.fr/web/contact 2014-09-17 16:24 GMT+02:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com >: > RMoD > > The requested object /web/pier/contact was not found on this server. > > You might want to try one of these options: > > - Click on a link on this site. > - Jump to the RMoD > <http://rmod.inria.fr/web?_s=qUUsgYCRA6EccLhv&_k=uBiY6VV3xNCuQW_Q&_n&11> > homepage. > - If you typed the page address, make sure that it is spelled > correctly. > > > 2014-09-17 15:10 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> What? Pharo Sprint >> When? Friday, 26th September, starting at 10:00am >> >> Where? >> RMoD, Inria Lille, Building B, third floor >> http://rmod.lille.inria.fr/web/pier/contact >> >> As the building is not open to the public, please contact >> us before if you plan to come. >> >> >> >

Sept. 17, 2014

Re: [Pharo-dev] [ANN] Pharo Sprint Lille 26th september

by Santiago Bragagnolo

RMoD The requested object /web/pier/contact was not found on this server. You might want to try one of these options: - Click on a link on this site. - Jump to the RMoD <http://rmod.inria.fr/web?_s=qUUsgYCRA6EccLhv&_k=uBiY6VV3xNCuQW_Q&_n&11> homepage. - If you typed the page address, make sure that it is spelled correctly. 2014-09-17 15:10 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > What? Pharo Sprint > When? Friday, 26th September, starting at 10:00am > > Where? > RMoD, Inria Lille, Building B, third floor > http://rmod.lille.inria.fr/web/pier/contact > > As the building is not open to the public, please contact > us before if you plan to come. > > >

Sept. 17, 2014