- Pharo-dev - lists.pharo.org

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. KernelTests.Chronology.DateTest.testDateAndTimeNow

April 12, 2013

Re: [Pharo-project] [update 3.0] #30038

by stephane ducasse

strange I could not get the diff on System-Support On Apr 12, 2013, at 4:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30038 > ----- > > 10278 Bug in semantic annotator > https://pharo.fogbugz.com/f/cases/10278 > > 10279 fix an undeclared in #condenseSources > https://pharo.fogbugz.com/f/cases/10279 > > 10258 DivideByZero in SystemProgressMorph > https://pharo.fogbugz.com/f/cases/10258 > > 10275 DNU on code completion > https://pharo.fogbugz.com/f/cases/10275 > > > > Diff information: > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/System-Support-MarcusDenker.… > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/NECompletion-MarcusDenker.108 > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Core-MarcusDenker.125 > http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Semantic-MarcusDenker.25 > >

April 12, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. KernelTests.Chronology.DateTest.testDateAndTimeNow

April 12, 2013

Re: [Pharo-project] call for a deprecate code transformation

by stephane ducasse

>> >> >> Any takers? > > Me. > I wanted something fancier: when you deprecate a method you attach a transformation rule so that when a deprecated method is executed, the deprecated warning can also propose to rewrite the sender. yes ;) but you need to general everything automatically :) and you need a solution for when the rewrite engine is not present. > >> >> Stef > >

April 12, 2013

Re: [Pharo-project] [3.0] Actions done in 3.0...

by stephane ducasse

yes because after it takes me **hours** to extract it. On Apr 12, 2013, at 10:53 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > This time we should just write it down when we do itâ¦ > > Actions in Pharo 3.0 > https://pharo.fogbugz.com/default.asp?W64 > > > Marcus

April 12, 2013

Re: [Pharo-project] Is renamePackage in Nautilus correct ?

by stephane ducasse

On Apr 12, 2013, at 9:12 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 11/04/2013 17:41, Benjamin a Ã©crit : >> Most probably yes :) > > Ok then, I'll do something like : not allow rename on a MC Package, allow rename on a RPackage. I don't know what renaming a Monticello package is really doing, regarding things like the package historyâ¦ yes it is probably totally broken. > >> Did I implemented myself or is this part of the refactoring engine ? > > It links directly to RPackageOrganizer without dependencies on the refactoring engine, so it's probably you :) There is a method which may be of interest to note, which is isValidPackageName:; why not moving it to RPackage so that we keep a bit of self-documenting validation there? > > Thierry > > >> Ben >> >> On Apr 11, 2013, at 2:47 PM, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>> wrote: >> >>> Hi, >>> >>> I'm trying to rename packages, so I'm adding the command to AltBrowser >>> using the Nautilus renamePackage as the way to do it. But looking at >>> the code, I wonder : does this really work ? >>> >>> If I select a subcategory of my Monticello package, it looks like it >>> will work (call RPackageOrganizer>>renamePackage:in:). But, if I >>> select my Monticello package itself (the one with the curly M ico) >>> then it seems it will rename just the RPackage and not much else (i.e. >>> for example, if I rename AST-Core, AST-Core-Matching, AST-Core-Nodes, >>> etc... will stay unchanged). Did I got that right ? >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

April 12, 2013

Re: [Pharo-project] Open window out of my pharo environment

by Igor Stasenko

On 12 April 2013 14:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 12, 2013, at 2:35 PM, Henrik Johansen wrote: > >> >> On Apr 12, 2013, at 1:08 PM, phil(a)highoctane.be wrote: >> >>> One crappy hack would be to have two host windows started by the VM and the Pharo Display bitmap split in two and each half being painted in its own window at the VM level. >>> >>> Which could even be extented to 'n' windows. >>> >>> The current display code uses a nxn matrix to repaint, refreshing in two windows is doable without too much fuss. >>> >>> For a Proof of Concept, that's workable. >>> Phil >> >> The painting itself isn't the real bear though, but event handling/distribution with multiple concurrent "worlds" and/or displays (or, in another term, WindowManagers). >> I mean, Areithfa Ffenestri (http://wiki.squeak.org/squeak/3862) has provided a workable multiple-windows API / VM implementation (on MacOS at least) for years, but the image-side code changes needed to make it work with source-aware events are still MIA. And that's not just due to lack of interest. >> >> Cheers, >> Henry > > On a positive note, I should say; there HAS been progress in Pharo lately that would make this work easier than it used to; for example. the move away from use of a global Sensor :) > yes.. we know where we going and what we want :) Actually i always wanted to do a nice multi-window support for squeak.. and even started writing new plugin prototype once in a while.. but then switched to something else. I could try to find this code, if i not lost it under tons of other started/drafted and then quickly abandoned hacks. > Cheers, > Henry -- Best regards, Igor Stasenko.

April 12, 2013

Re: [Pharo-project] Open window out of my pharo environment

by Igor Stasenko

On 12 April 2013 14:35, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Apr 12, 2013, at 1:08 PM, phil(a)highoctane.be wrote: > >> One crappy hack would be to have two host windows started by the VM and the Pharo Display bitmap split in two and each half being painted in its own window at the VM level. >> >> Which could even be extented to 'n' windows. >> >> The current display code uses a nxn matrix to repaint, refreshing in two windows is doable without too much fuss. >> >> For a Proof of Concept, that's workable. >> Phil > > The painting itself isn't the real bear though, but event handling/distribution with multiple concurrent "worlds" and/or displays (or, in another term, WindowManagers). indeeeed! > I mean, Areithfa Ffenestri (http://wiki.squeak.org/squeak/3862) has provided a workable multiple-windows API / VM implementation (on MacOS at least) for years, but the image-side code changes needed to make it work with source-aware events are still MIA. And that's not just due to lack of interest. > the last time i checked this stuff, the platform support code exists only for windoze and mac, but no avail for linux. > Cheers, > Henry -- Best regards, Igor Stasenko.

April 12, 2013

Re: [Pharo-project] Open window out of my pharo environment

by Igor Stasenko

On 12 April 2013 12:22, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > From immediate perspective, why not hook up with NativeBoost to a C DLL one > can easily parametrize to serve as viable alternative / proof of concept > till Igor / Esteban's work becomes core to Pharo. > > Is this Windows / Mac / Linux or multi OS..? For Pharo, they will have to > ensure it multi OS compatible so may take time stabilizing. > > On Windoze i can create a window like a piece of cake (see NBOpenGL code which does that).. the only problem which i think will inevitably hit us is handling events for that window.. for that we will need to modify VM (even in case if we decide to handle events by image-side callback). It works in NBOpenGL case, simply because it creating a hidden window which is never shown on screen and never receives any events...and i using it to create an offscreen opengl context. > > On Fri, Apr 12, 2013 at 1:19 PM, Tristan Bourgois > <tristan.bourgois(a)gmail.com> wrote: >> >> Hi! >> >> all my question is in the object ^^ >> >> Does exist the possibility to open a window out of my pharo environment? >> (Or someone know the way to do that?) >> >> I'm working on a graphic framework and at my work they need a multi screen >> support. It's needed to validate Pharo as the smalltalk they will use! >> >> Thanks! >> >> Tristan > > -- Best regards, Igor Stasenko.

April 12, 2013

Re: [Pharo-project] Question on announcements when renaming a RPackage

by Igor Stasenko

On 12 April 2013 14:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi all, > > I'm looking at announcements seen when renaming a RPackage. From the > Nautilus renamePackage code, I see that this goes straight to > RPackageOrganizer>>renamePackage:in: > > In the two announcers to be followed in those cases, i.e. SystemAnnouncer > and RPackage organizer announcer, I see three events I kind of expected, but > not two I expected. > > In RPackage organizer announcer, I see > a RPackageUnregistered > a RPackageRenamed > a RPackageCreated > Where the system announcer shows only : > a RPackageRenamed > And that there is no mention of a CategoryAdded and a CategoryRemoved > events. Do those categories still exist? > > Yes, they do. Opening Browser (the original thing), I see that the system > category with the old package name is still there, and the new system > category as well but... there was no > CategoryAdded <- Why? > CategoryRemoved <- of course, no deletion of the old category :) > announcements. > > So, a few questions: > - is this a bug? > - will Monticello keep creating categories anyway (but not RPackage methods) > - does it matter that its incoherent now given that we will get rid of > system categories one day > - does it matter because there are only a handfull of guys hacking at the > IDE and that as long as one browser manages to hold it together, it's fine > ;) > IMO even if it not a bug, i think there should be 1 announcement per action, not 2,3 or 10.. system should be reasonable. > Thanks to Nautilus for documenting indirectly how to use RPackage :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

April 12, 2013