- Pharo-dev - lists.pharo.org

Re: [Pharo-project] build #14430 feedback needed

by Esteban Lorenzano

Hi, I removed the functionality that was causing the problem... is not so easy to get it ready for windows, and shouldn't be a delay for 1.4 release. The fix can wait to next version. Now... I'm not sure that same functionality was responsible from the delays... so, I'm still interested in know if delay is there in last build (form 1hr) or not. cheers, Esteban On Apr 17, 2012, at 7:07 PM, Ben Coman wrote: > I can confirm that delay on Windows 7, but it also exists for 14427 so I would say that is not related to the fix. I would search further but I can't see how to get more history from Jenkins. In any case, the startup delay disappears after a Save&Quit and restart. > I am looking into testing the bug fix - and adding a TestCase. > Esteban Lorenzano wrote: >> thanks, >> >> anybody else can confirm that delay? >> >> btw... what I'm looking for is a crash that happened while initiating windows, because of lookup of preferences... it is not completely fixed, but should be partially working now. >> cheers, >> Esteban >> >> On Apr 17, 2012, at 2:46 PM, Henrik Johansen wrote: >> >> >>> On Apr 17, 2012, at 2:14 PM, Esteban Lorenzano wrote: >>> >>> >>>> Hi, >>>> >>>> I just released #14430 with a bugfix for windows. Problem is that we don't have enough windows tastes to be sure the fix work. >>>> Can windows users take a look at: https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… >>>> >>>> and see if it is working? >>>> I'm looking for some info about: -vista >>>> -win7 >>>> >>>> but any other will be ok too :) >>>> >>>> thanks, >>>> Esteban >>>> >>>> >>> Opened on Win7. >>> Was unresponsive for 20-30 seconds, then started responding to clicks etc. (What on earth is it doing on startup now?) >>> Could open Browser, Finder, check Monticello reps. >>> >>> Anything in particular the bug fix is for? >>> >>> Cheers, >>> Henry >>> >>> >>> >> >> >> >> > >

April 17, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by Eliot Miranda

On Tue, Apr 17, 2012 at 10:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I think that we missing a way to determine to which package some > global belongs to. > When you loading a package it can declare new global, but there is no > reflective mechanisms in system to tell, to which package it belongs. > If we could have that, then clearly, if you serialize the package, you > would want to serialize its globals as well, > and if not, you can just leave a reference to it, which will be > rewired at materialization. > +1. Some construct that defines a module, analogous to a class definition? > > On 17 April 2012 18:20, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> Hi guys. In Fuel, we need to identity which globals present in Smalltalk > >> globals are NOT classes or traits, because we need to manage them as > >> globals. So far we have a hardcoded list: > >> > >> defaultGlobalSymbols > >> > >> ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display > >> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor > >> #ImageImports #SystemOrganization #World) > >> > >> So...as every hardcoded stuff, this is not nice because as soon as > globals > >> change, we need to fix this. So it would be nice if the system (pharo) > can > >> provide us this information. > >> > >> What do you think? > > > > > > What I think is that the set of globals depends on usage. Some time I > might > > actually want to serialize the SourceFiles Array, sometimes I might not > want > > to. So this should be configurable, with a sensible default. Just as > when > > one serializes a set of classes, references to classes outside the set > are > > not serialized, serializing some subset of global objects in Smalltalk > > should serialize those objects, not references. So design some > convenient > > API that allows one to specify which objects are not globals, and have > the > > default be e.g. all global objects in Smalltalk. > > > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

April 17, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by Igor Stasenko

I think that we missing a way to determine to which package some global belongs to. When you loading a package it can declare new global, but there is no reflective mechanisms in system to tell, to which package it belongs. If we could have that, then clearly, if you serialize the package, you would want to serialize its globals as well, and if not, you can just leave a reference to it, which will be rewired at materialization. On 17 April 2012 18:20, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Hi guys. In Fuel, we need to identity which globals present in Smalltalk >> globals are NOT classes or traits, because we need to manage them as >> globals. So far we have a hardcoded list: >> >> defaultGlobalSymbols >> >> Â Â Â ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display >> #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor >> #ImageImports #SystemOrganization #World) >> >> So...as every hardcoded stuff, this is not nice because as soon as globals >> change, we need to fix this. So it would be nice if the system (pharo) can >> provide us this information. >> >> What do you think? > > > What I think is that the set of globals depends on usage. Â Some time I might > actually want to serialize the SourceFiles Array, sometimes I might not want > to. Â So this should be configurable, with a sensible default. Â Just as when > one serializes a set of classes, references to classes outside the set are > not serialized, serializing some subset of global objects in Smalltalk > should serialize those objects, not references. Â So design some convenient > API that allows one to specify which objects are not globals, and have the > default be e.g. all global objects in Smalltalk. > >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

April 17, 2012

Re: [Pharo-project] build #14430 feedback needed

by Ben Coman

I can confirm that delay on Windows 7, but it also exists for 14427 so I would say that is not related to the fix. I would search further but I can't see how to get more history from Jenkins. In any case, the startup delay disappears after a Save&Quit and restart. I am looking into testing the bug fix - and adding a TestCase. Esteban Lorenzano wrote: > thanks, > > anybody else can confirm that delay? > > btw... what I'm looking for is a crash that happened while initiating windows, because of lookup of preferences... it is not completely fixed, but should be partially working now. > > cheers, > Esteban > > On Apr 17, 2012, at 2:46 PM, Henrik Johansen wrote: > > >> On Apr 17, 2012, at 2:14 PM, Esteban Lorenzano wrote: >> >> >>> Hi, >>> >>> I just released #14430 with a bugfix for windows. Problem is that we don't have enough windows tastes to be sure the fix work. >>> >>> Can windows users take a look at: https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… >>> >>> and see if it is working? >>> I'm looking for some info about: >>> -vista >>> -win7 >>> >>> but any other will be ok too :) >>> >>> thanks, >>> Esteban >>> >>> >> Opened on Win7. >> Was unresponsive for 20-30 seconds, then started responding to clicks etc. (What on earth is it doing on startup now?) >> Could open Browser, Finder, check Monticello reps. >> >> Anything in particular the bug fix is for? >> >> Cheers, >> Henry >> >> >> > > > >

April 17, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by Eliot Miranda

On Tue, Apr 17, 2012 at 3:50 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. In Fuel, we need to identity which globals present in Smalltalk > globals are NOT classes or traits, because we need to manage them as > globals. So far we have a hardcoded list: > > defaultGlobalSymbols > > ^ #(#Smalltalk #SourceFiles #Transcript #Undeclared #Display > #TextConstants #ActiveWorld #ActiveHand #ActiveEvent #Sensor #Processor > #ImageImports #SystemOrganization #World) > > So...as every hardcoded stuff, this is not nice because as soon as globals > change, we need to fix this. So it would be nice if the system (pharo) can > provide us this information. > > What do you think? What I think is that the set of globals depends on usage. Some time I might actually want to serialize the SourceFiles Array, sometimes I might not want to. So this should be configurable, with a sensible default. Just as when one serializes a set of classes, references to classes outside the set are not serialized, serializing some subset of global objects in Smalltalk should serialize those objects, not references. So design some convenient API that allows one to specify which objects are not globals, and have the default be e.g. all global objects in Smalltalk. > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

April 17, 2012

[Pharo-project] [update 1.4] #14432

by Esteban Lorenzano

14432 ----- Issue 5620: clean up pre-release http://code.google.com/p/pharo/issues/detail?id=5620 Issue 5596: DosFileDirectory>>preferencesRootPath broken http://code.google.com/p/pharo/issues/detail?id=5596 3 builds in a day, yeah! (and more comming)

April 17, 2012

Re: [Pharo-project] build #14430 feedback needed

by Gary Chambers

Seems fine on Vista. First startup was a bit slow, as noted. Regards, Gary ----- Original Message ----- From: "Esteban Lorenzano" <estebanlm(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, April 17, 2012 1:14 PM Subject: [Pharo-project] build #14430 feedback needed Hi, I just released #14430 with a bugfix for windows. Problem is that we don't have enough windows tastes to be sure the fix work. Can windows users take a look at: https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/lastSucces… and see if it is working? I'm looking for some info about: -vista -win7 but any other will be ok too :) thanks, Esteban

April 17, 2012

Re: [Pharo-project] SourceFiles

by Martin Dias

Thanks! On Tue, Apr 17, 2012 at 8:49 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 17, 2012, at 9:12 AM, Martin Dias wrote: > > > Hi all > > > > I vaguely remember some discussions about enhancing SourceFiles, > something about to reify a code manager, about to stop logging fileIns into > .changes file, and about to inspire the new mechanism on the VW's one. > > > > Am I right? > > Yes. > > > There is consensus on this? > > About a better Interface (SourceManager): yes, consesus. About not having > course and changes, I think everyone > knows that it should be done eventually, but some argue that it works and > is stable and changing it now would > be problematic... there are good reasons for both views, I think. > > > Do you think I could do it as part of Fuel Injector GSoC project? > > > > Yes, that could be an idea. > > -- > Marcus Denker -- http://marcusdenker.de > > >

April 17, 2012

[Pharo-project] lagging in the interface

by Hilaire Fernandes

When using Pharo under tablet (both iPad and Android), we have noted some lag in the user interface when clicking a button. Indeed sometime you have to press twice a button to get the press event caught by Pharo. This problem does not occur with Squeak 3.9 and same StackVM. Any idea? Hilaire -- Dr. Geo -- http://www.drgeo.eu

April 17, 2012

Re: [Pharo-project] How to globals that are NOT classes or traits?

by Tobias Pape

Am 2012-04-17 um 15:20 schrieb Guillermo Polito: > Be careful that #isBehavior is false for Traits :). To fix I think. oO I did not expect that. However, I think Traits should respond with true to traits. Well thenâ¦ 1) send isTrait, if applicable defaultGlobalSymbols ^ (self environment "or 'Smalltalk globals' or 'Smalltalk', to your taste" reject: [:g | (g isBehavior) or: [ (g respondsTo: #isTrait) and: [ g isTrait]]]) keys or 2) make Traits respond true to isBehavior ;) Best -Tobias

April 17, 2012