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

Re: [Pharo-dev] Package tags for extensions

by Esteban Lorenzano

Hi Yuri, is no-issue and no-work in progress: is like that by design. extensions are package related and not tag related. soâ¦ you can name an extension MyPackage-B, but it will still be going to rpackage extensions. one of the things we need to continue improving is protocolsâ¦ now they are objects (before they were just strings), but extensions are still name matching conventions, and they should be also objects (like ExtensionProtocol) or something like that. but wellâ¦ future stuff. Esteban On 07 Apr 2014, at 05:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > Now we have tags for packages in Pharo 3, and itâs very cool. So if I select a tag âAâ in âMyPackageâ I will see all classes from category âMyPackage-Aâ. On the other hand if Iâm extending another class with a protocol â*MyPackage-Bâ I canât see that class under the âBâ tag. Is this some kind of issue or itâs still a work in progress. > > Cheers. > Uko

April 7, 2014

Re: [Pharo-dev] [Vm-dev] Pharo VM bug 11130

by Nicolas Cellier

2014-04-07 8:13 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > On 06 Apr 2014, at 23:08, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2014-04-06 22:29 GMT+02:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> Good news, >> I've managed to make your issue apparently vanish in Pharo3.0 VM. >> For this, I: >> - cleaned up unecessary differences with Eliot's VMMaker.oscog branch, >> - removed unecessary changes ahead of VMMaker.oscog-eem.333 version >> (those stamped LucFabresse) >> - carefully applied changes from VMMaker.oscog-eem.333 that were not >> applied >> Note that this version was marked as merged, which it was obviously not >> Please, if you do not fully merge, but just cherry pick some changes, >> it's better to not merge. >> - upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu >> - integrated the issues for which I emitted a pull request >> >> All this work can be found publicly at >> https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEl… >> >> I cannot tell which missing change exactly was the root cause, and I >> cannot dissect either, but I saw several + LiteralStart missing... Or it >> could be related to cogit method/block native code generation... >> The changes are most probably here >> >> https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d… >> >> Bad news, >> the structures at beginning of src/cm/cogit.c are generated out of order, >> and I didn't find the cause yet. >> Once solved, I think my branch should be carefully reviewed and >> integrated. >> >> > Haha! this is Class class>>superclassOrder: which break things... > The order of structures passed on input was mostly good but ruined on > output... > > The Squeak ChangeSet class>>superclassOrder: does not convert the list of > classes asSet, thus somehow preserves provided order. > The Pharo version does not take so much care it seems... > Apparently the method was changed again in Pharo3.0, but neither does it > preserve order. > > > Can you publish the change for the superclassOrder: as a bug entry? > we should add a test > > Yes, I did: https://pharo.fogbugz.com/f/cases/13180/Class-class-superclassOrder-should-… Of course, those kind of expectations should be asserted by a test (I didn't). > After fixing it, compilation went well... > > >> >> 2014-04-03 4:13 GMT+02:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >> >>> >>> >>> 2014-04-02 23:59 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: >>> >>> >>>> Nicolas wrote: >>>> >Hmm, don't waste too much time. >>>> >All these methods are unchanged in github pharo-vm head revision >>>> (VMMaker-oscog-StefanMarr.313) >>>> >The cause must be completely different in latest pharo vms. >>>> >>>> Uhm, why? They haven't changed. >>>> >>> >>> Sorry, haven't changed means that there's no diff with the corrected >>> version. >>> IOW, the fixes from Eliot have been integrated for a long time already. >>> You are seeing another symptom, probably another bug impacting the same >>> code. >>> There are many diffs between pharo's and Eliot's branch, but not where >>> you're looking at. >>> >>> Pharo vms 105 and later no longer crash, but all reliably show the bug. >>>> And 236 is the last Squeak one to show the problem. >>>> >>>> I might take a look at Esteban's versions from the same time, >>>> 228 and 229 >>>> >>>> Stephan >>> >>> >>> >> > >

April 7, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Henrik Johansen

On 06 Apr 2014, at 5:36 , Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. > > The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. > > The pharo's PolyMorphDiffTool is good looking but awfully sloooow > It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. > But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. > > But worse than all, there are insane caches operating in MCVersion that drove me crazy. > Here is the scenario: > 1) I diff working copy against package.branchA-version.mcz > 2) I cherry pick and install a few methods > 3) I diff against package.branchA-version.mcz again to check if I missed smthing > 4) Huh? it looks like my cherry pick have not been installed??? > Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! > What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. > So I had to change MCVersion>>changes > ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot > > This is so broken that I have to report here. > Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! > > Guys, it makes me wonder, who is eating the dog food? > Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) > Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version. Not only that, the simplest possible merge operation is broken: https://pharo.fogbugz.com/f/cases/12776/Cancelling-Previous-Contents-in-a-W… As it stands, MC in Pharo is nothing but a fancy change set applier, not a version control system. Cheers, Henry

April 7, 2014

Package tags for extensions

by Yuriy Tymchuk

Hi guys, Now we have tags for packages in Pharo 3, and itâs very cool. So if I select a tag âAâ in âMyPackageâ I will see all classes from category âMyPackage-Aâ. On the other hand if Iâm extending another class with a protocol â*MyPackage-Bâ I canât see that class under the âBâ tag. Is this some kind of issue or itâs still a work in progress. Cheers. Uko

April 7, 2014

Re: [Pharo-dev] ghost windows

by Pharo4Stef

Yes it happens to me form time to time but it is difficult to debug the situation. On 07 Apr 2014, at 08:53, Johan Brichau <johan(a)inceptive.be> wrote: > Hi there, > > I often get in a situation where 'ghost windows' remain in the Pharo window (see screenshot). > These windows are closed (see taskbar) and I cannot select nor click these ghost windows to remove them. > > Is there a way to remove them programmatically? > They cause visual clutter when working with multiple real windows and I do not want to rebuild an entire development image each time this occurs. > > Though this is in Pharo3, I think I occassionally had these in Pharo1.4 as well. > > cheers > Johan > > <PharoScreenshot.png>

April 7, 2014

ghost windows

by Johan Brichau

Hi there, I often get in a situation where 'ghost windows' remain in the Pharo window (see screenshot). These windows are closed (see taskbar) and I cannot select nor click these ghost windows to remove them. Is there a way to remove them programmatically? They cause visual clutter when working with multiple real windows and I do not want to rebuild an entire development image each time this occurs. Though this is in Pharo3, I think I occassionally had these in Pharo1.4 as well. cheers Johan

April 7, 2014

Re: [Pharo-dev] WhatsUp from: 2014-04-07 until: 2014-04-20

by Pharo4Stef

On 07 Apr 2014, at 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: > - Presented Pharo to a well known group doing HCI in france. Kind of planting seed. - Working on new chapter or old chapters - Preparing release > > ### What's next, until 2014-04-20 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION > > (*) we'll be expecting results by then ;) >

April 7, 2014

Re: [Pharo-dev] [Vm-dev] Pharo VM bug 11130

by Pharo4Stef

On 06 Apr 2014, at 23:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2014-04-06 22:29 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Good news, > I've managed to make your issue apparently vanish in Pharo3.0 VM. > For this, I: > - cleaned up unecessary differences with Eliot's VMMaker.oscog branch, > - removed unecessary changes ahead of VMMaker.oscog-eem.333 version (those stamped LucFabresse) > - carefully applied changes from VMMaker.oscog-eem.333 that were not applied > Note that this version was marked as merged, which it was obviously not > Please, if you do not fully merge, but just cherry pick some changes, it's better to not merge. > - upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu > - integrated the issues for which I emitted a pull request > > All this work can be found publicly at https://github.com/nicolas-cellier-aka-nice/pharo-vm/compare/fixMergeWithEl… > > I cannot tell which missing change exactly was the root cause, and I cannot dissect either, but I saw several + LiteralStart missing... Or it could be related to cogit method/block native code generation... > The changes are most probably here > https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d… > > Bad news, > the structures at beginning of src/cm/cogit.c are generated out of order, and I didn't find the cause yet. > Once solved, I think my branch should be carefully reviewed and integrated. > > > Haha! this is Class class>>superclassOrder: which break things... > The order of structures passed on input was mostly good but ruined on output... > > The Squeak ChangeSet class>>superclassOrder: does not convert the list of classes asSet, thus somehow preserves provided order. > The Pharo version does not take so much care it seems... > Apparently the method was changed again in Pharo3.0, but neither does it preserve order. Can you publish the change for the superclassOrder: as a bug entry? we should add a test > > After fixing it, compilation went well... > > > > 2014-04-03 4:13 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > > > 2014-04-02 23:59 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > > > Nicolas wrote: > >Hmm, don't waste too much time. > >All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313) > >The cause must be completely different in latest pharo vms. > > Uhm, why? They havenât changed. > > Sorry, haven't changed means that there's no diff with the corrected version. > IOW, the fixes from Eliot have been integrated for a long time already. > You are seeing another symptom, probably another bug impacting the same code. > There are many diffs between pharo's and Eliot's branch, but not where you're looking at. > > Pharo vms 105 and later no longer crash, but all reliably show the bug. > And 236 is the last Squeak one to show the problem. > > I might take a look at Estebanâs versions from the same time, > 228 and 229 > > Stephan > > >

April 7, 2014

WhatsUp from: 2014-04-07 until: 2014-04-20

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-04-20 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

April 7, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by ClÃ©ment Bera

Hello, Currently on the VM one of the next step is to speed up numerical computation, it should happen in around a year. Right now it would not worth it because even in arithmetic intensive benchs (I'm talking abut floating pointer benchs) the VM spends most of its time in the GC or iterating over collections, but once both of these 2 performance bottlenecks will be fixed (the new GC is about to be integrated, but the VM still needs to be ported to 64 bits to have more efficient floating pointers and collection speed-ups will be ready in 11 months), the next step is to speed up arithmetics, especially floating-pointers arithmetics. Distributed / Cloud processing is kind of a work in progress too. For that we need the threaded FFI working with the new GC to have #forkAndExec which spawn an image and fork the process in it efficiently. It's a 3-months project for a competent guy but no one is planning to do that on the short term AFAIK (there are other things to do first with the current resources). In addition for this problem we need things as a well identified kernel to spawn another image quickly (but thanks to Pavel we kind of have it). I guess in a few year we will have a framework to spawn new images and having them communicating through sockets efficiently. The communication layer would be inspired from Metatalk. A prototype was done with Metatalk (named ImageWorker) but the VM does not have support for #forkAndExec so this part was done with OSProcess, unfortunately making it a toy instead of a real framework... About Flexible Presentation, Spec is on the way as it has a morphic back end and a native UI back end. I guess at some point it will have a web back end too (maybe with amber ?). We "just" need to find someone willing to do it... So I think we kind of are doing what you expect. 2014-04-06 19:01 GMT-07:00 S Krish <krishnamachari.sudhakar(a)gmail.com>: > > "...Coherent and robust philosophy..." > > We got to be aware of the fact that Wolfram is recognized as a renegade > scientist with a great work in Mathematica but the work on cellular > automata and his theory on New kind of Science is controversial to put it > lightly. > > What appeals to me as ideas / concepts that will make a great impact in > Pharo if we can bring it in, without crossing swords on IP / patents..!!.. > Kind of pick on priori art on all of them. > > http://www.wolfram.com/language/principles/ > > *For Pharo:* > > The great work done in Pharo so far and with core roadmap ahead.. this > will probably be add on to the core / or as an extension: > > * *Cloud/ distributed processing*: A semi connected distributed language > / programming environment that is knowledge aware of each node, scalably > working with one or more nodes available at any given time. Backend data > awareness linked to any type of data storage: RDBMS, NoSQL, flat files.. > > * *Power of algorithmic computation:* The framework for distributed AI > algorithm that works with available knowledge base in time defined manner ( > synchronous or asynch ) of the defined "execution". The power user can then > plugin additional algorithms, modify and create a web as reqd > > * *Symbolic Expressions*: Syntactically cryptic but like a DSL it makes > sense to have power user the brevity in his daily grind, though it can be > left to the power user group to evolve the same given a foundation of a > framework that makes it quick work to get it stitched together. > > * * Flexible Presentation*: DSL or the scripting driven quick > presentation capability that can be any from a html / morphic / image / > video / textual presentation. Kind of moldable, flexible to the core with > defaults that feel almost intuitive to the processing > > * *NLP*: Natural language processing that is incremental, perhaps > smalltalk already has been there in a small measure and static for a very > long time, need to make it really NLP.. http://emerge.mc.vanderbilt.edu/natural-language-processing-nlp-survey-tool… > <http://www.nltk.org/> > > * *Numerical computation*: Fast, highly efficient perhaps Native Boost > enabled all kinds of maths: calculus, statistical computation, image > processing et als. > > All the above are greatly relevant in the enterprise world development and > will be a great fit to Pharo's capability with the GTInspector, > Rossal+Athens presentation along with Morphic, meta programming, debugger > that is live and can be interconnected with fuel, syntatically as close to > NLP to any mainstream language can be ... > > > *-Skrish* > > > On Wed, Apr 2, 2014 at 11:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Indeed, I read this article several times over the last couple of days. >> This work is impressive particularly when combined with the cloud part. >> >> The language itself is less interesting for me, but what makes it stand >> out is that it has a coherent and robust philosophy behind and phenomenal >> goals to reach. In Pharo, we have the luxury of building on top of coherent >> and robust philosophy (even if different from the Wolfram one) and we >> should try as much as possible to keep our eyes on phenomenal goals that >> seem unreachable. >> >> Another thing I like in Wolfram's work is attention to details: >> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ >> >> Details are crucial, and all the effort in Pharo around naming and >> redesigning what already exists is incredibly important. But, it is >> precisely at the moment when we are knee-deep in details that is crucial to >> keep our eyes on the phenomenal long term goals. >> >> There is so much to build. Let's be bold. >> >> Doru >> >> >> >> On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> >>> On 31 Mar 2014, at 06:21, S Krish <krishnamachari.sudhakar(a)gmail.com> >>> wrote: >>> >>> > How about impact of this: >>> > >>> > >>> http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-s… >>> > >>> > I would agree it is quite complex for any beginner, but utility of a >>> programming language on these lines seems cut out for the future.. >>> >>> Wow, this is really powerful stuff, a long read, but well worth it. By >>> recombining and reusing all their technology they seem to be able to move >>> into more and more territory. >>> >>> It is closed source and (very) expensive, and I don't like the syntax, >>> but we sure can get good ideas from them. >>> >>> Thanks for sharing the link. >>> >>> Sven >>> >> >

April 7, 2014