- Pharo-dev - lists.pharo.org

Re: [Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)

by Alain Plantec

Le 11/05/2010 21:00, Mariano Martinez Peck a Ã©crit : > > > > Actually, I want to change two things: FastDragging (to true) and > "Show update option in World menu" (to false). > > So, how can I do that ? ---------------- UITheme currentSettings fastDragging: true. WorldState showUpdateOptionInWorldMenu: false ---------------- Cheers Alain > Thanks > > Mariano > > > > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

May 11, 2010

Re: [Pharo-project] could we start to organize MetacelloRepository?

by StÃ©phane Ducasse

May 11, 2010

Re: [Pharo-project] could we start to organize MetacelloRepository?

by Dale Henrichs

May 11, 2010

Re: [Pharo-project] could we start to organize MetacelloRepository?

by StÃ©phane Ducasse

On May 10, 2010, at 8:14 PM, Dale Henrichs wrote: > Stef, > > Just thinking off the top of my head a bit. > > Conceptually a separate repository makes sense ... then Gofer Project could be > setup to to use this repository by default and the standard instructions for > loading things would be reduced to simple expressions like: > > Gofer project load: 'FFI'. > Gofer project load: 'Magma'. > > The difficulty comes in keeping the repository up-to-date....First you'd need > to qualify configurations for inclusion (a hudson server for validation) makes > sense. For hudson, it would be nice if there were a list of candidate > configuration/version pairs that would be tested against ... tomorrow we will sit with lukas and marcus to see how we can setup an hudson server on pur server. > In reality we are really looking for an approved list of configuration/version > pairs that are known to work in Pharo 1.0. So we're probably really interested > in expressions like the following: > > Gofer project load: 'FFI' version: '1.2'. > Gofer project load: 'Magma' version: '1.0r44'. > > At this point a separate repository becomes a little less useful ... it's not > the Configuration alone that the end user is interested in as the version is > very important and the important information is that it is "known to work" For me I thought that we separate repository so that we can have distributions. > This leads me to think along the lines of > > - configs from MetacelloRepository > - hudson server validating each version for each config > - list of config/(latest passing version) pairs published > > It would seem to me that a relatively simple morphic/glamour window could be > written that read the config/version pairs from the hudson server and > provided a means for selecting/loading the config/version pairs. > > How does this sound? I do not know because I do not foresee the use well. Gofer for: #Pharo1.0. Gofer project load: 'FFI' looks simple to me. Then if I want to load a specific version Gofer project defaultVersionFor: 'FFI' '1.2' Gofer project load: 'FFI' version: '1.1' if I need the one before 1.2 if it makes sense. Stef > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | Hi Dale and others > | > | I would like to have a > | Pharo1.0 folder in the MetacelloRepository and ideally all the > | configurationOf... inside should work for Pharo 1.0. > | How can we proceed to get that. > | In the future we should also have a process to avoid that we get junk > | inside. any idea (I was thinking about an hudson > | server that would validate the configuration automatically) > | > | Stef

May 11, 2010

Re: [Pharo-project] DEVImageCreator >> setDefaultPreferences (alain?)

by Mariano Martinez Peck

On Tue, May 11, 2010 at 3:44 PM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Le 11/05/2010 15:22, Alain Plantec a Ã©crit : > >> Le 11/05/2010 14:13, Mariano Martinez Peck a Ã©crit : >> >>> >>> >>> >>> >>> But maybe the default value in the "PharoCore" is not the same as >>> PharoDev? I mean, suppose these are the default prefrences we used in the >>> pharo dev image >>> >> ok, there is only one default. >> For this need, you should have to create a setting style for pharodev and >> load it. >> > I've re-thougth about this and maybe building a style class and let it in > the dev image is a bad solution > because then, the style class depends on all other packages. This is > exactly what we wanted to avoid by > introducing the settings. > So, maybe the default state for the preferences in the dev should be the > one of the core > plus the state decided by maintainers for additional packages. Ok...but how can I do the following: there is a setting that in Core has XXX value and I want to change it for the Dev image. Creating whole Style doesn't make sense as I only want to change one setting. In addition, happens what you told me in this mail, and finally it is difficult to manage I think: imagine today I create a Style and tomorrow you create ore settings...do I need to update my style to contemplate such setting ? Actually, I want to change two things: FastDragging (to true) and "Show update option in World menu" (to false). So, how can I do that ? Thanks Mariano > > > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2010

Re: [Pharo-project] VMs for Pharo 1.1

by StÃ©phane Ducasse

excellent! Stef On May 11, 2010, at 6:52 PM, John M McIntosh wrote: > > On 2010-05-10, at 11:16 PM, laurent laffont wrote: > >> >> Mac: John, I am not sure which VM we should use for Pharo 1.1. Can you give us a hint ? known problems ? does it include freetype ? > > > Let me build and upload a 32bit bias macintosh V5.x VM for people to try later today, since I'd suggest that should be used. > > > > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Nicolas Cellier

2010/5/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > nicolas > > do you have an idea where we can look? > > Stef > Sorry, I don't have time to dig into it... But I think invent is a more appropriate verb than look in this case. The ideas of Igor sound good to me, delegate some to CompiledMethods and maybe use a mass becomeForward Nicolas > On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote: > >> Sorry for the infinite loop, it was my fault. >> I thought it had been detected and solved already (in squeak ?). >> >> Destroying source pointer of un-installed methods was just a >> workaround to be used in case of already broken sources. >> There is another strategy : detect the source pointer of un-installed >> methods and store them in the new change log. >> This has to be done before logging source code of installed methods. >> >> Nicolas >> >> 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: >>> On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >>>> >>>>> Ok, i took the 11343 >>>>> - fixed the #condenseChanges >>>>> - ran Â Smalltalk condenseChanges >>>>> - changed the single method >>>>> - saved image >>>>> - ran Â Smalltalk condenseChanges again >>>>> >>>>> no crash reported. >>>>> >>>> >>>> Indeed, with 11343 it seems ok. >>>> With 11326 (updated -> 11346), crash during the second condenseChanges :( >>> >>> Alain, could you please send me an image +.changes saved just before >>> running a second condenseChanges? >>> I'll try to find the cause of it. >>> >>>> Alain >>>>> >>>>> >>>>>> >>>>>> Alain >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2010

Re: [Pharo-project] Single threaded Pharo IDE?

by Schwab,Wilhelm K

Sig, If you give us "overlapped calls," we'll make a statue of you. I'll bring the chissels :) On sockets, I'm not terribly worried about the blocking part: what I don't want is for the whole image to go under because of mis-typed URL or something. In short, I'm worried about too much blocking, not the absense of it. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Monday, May 10, 2010 6:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Single threaded Pharo IDE? 2010/5/11 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Andrei > Having do-its block the UI is a feature, especially since you can > explicitly fork a new (Smalltalk) process to do the work.Â What is > **NOT** acceptable (and I fear I will discover is "easy" to cause to > happen) is for DNS and socket operations that have been forked to block the main thread. > someone still has to do that for you, i.e. wait for a completion of blocking operation. > Dolphin has a feature called overlapped calls that allow external > functions to be executed on a new OS thread specifically to avoid > hanging the entire image.Â There are restrictions and disclaimers even > then, and the default behavior is to block the UI. > Btw, its good that you mentioned this feature. Given that i have a full control, what happens with NativeBoost, i could create a native thread to serve for handling such 'overlapped' calls, and at image side, it will just put a process, which made a call into a waitable state, while other processes could still continue to run. > Bill > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Andrei Stebakov > Sent: Monday, May 10, 2010 5:31 PM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Adrian Lienhard > Subject: Re: [Pharo-project] Single threaded Pharo IDE? > > > > 2010/5/10 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> >> 2010/5/10 Andrei Stebakov <lispercat(a)gmail.com> >>> >>> >>> I just started to use Pharo 1.0. So please bear with me since I may >>> not fully understand the full concept of the IDE. Sometimes the >>> whole IDE freezes indefinitely. >> >> Welcome ! we hope you enjoy ;) >> >>> >>> So questions: >>> 1) Looks like evaluating anything from the Workspace freezes the >>> whole UI for the time of execution. Is it a bug or a feature? >> >> More or less. Pharo has a green thread implementation. I will tell >> you what I understand. Green threads means, there is only ONE OS >> thread, and then, internally (in Smalltalk) there exists their own >> threads, scheduler, priorities, etc. The UI is just a process that is >> running, with a certain priority. Go to the world menu, then "Tools" >> -> "Process Browser". There you will see all the current processes >> with their priorities. You can notice the UI process. >> > But you must agree that it still looks fishy when your whole UI blocks > when you execute something lengthy (like new package install)... > Well, if the majority of Pharo users think that it's OK who am I to argue? > ;) > > >> Â So...whatever you do here, it will be done inside that process. If >> you do normal things, then yes, I guess the UI freezes. However, you >> way want to launch another thread to do what you want and with a >> lower priority than the UI. >> >> Do this test: open a workspace and a transcript. In the workspace, >> evaluate: >> >> [ 1000 timesRepeat: [Transcript show: 'mariano'; cr] ] forkAt: >> Processor userBackgroundPriority >> >> there, you will see that you are able to use the ide, while the block >> of writing to Transcript is working "at the same time". >> >> Here the most important message is forkAt:Â Â Â . fork just fork the >> block with the standard priority ("Processor activePriority"). If you >> want to specify the priority, you have to use forkAt: > > Yes, the [ HTTPSocket httpGet: 'http://www.pharo-project.org/home'] forkAt: > Processor userBackgroundPriority doesn't block the UI anymore... > If it's the way to go, shouldn't we have a "special non-blocking" > Workspace which does exactly this (or have an option to run your > Workspace command with a background priority)? > >> >> >>> >>> 2) Sometimes executing something freezes the UI indefinitely. Is >>> there a way to cancel the operation (other than restarting the image)? >>> Strangely in my case the IDE froze on evaluating HTTPSocket httpGet: >>> 'http://www.pharo-project.org/home' >>> >> >> Yes, Sockets are an example where sometimes they block the whole image. >> Are you behind a proxy ? do you have a timeout error after a while ? >> I have just tested and it also freezes for me in Mac OS. I have no idea. >> Maybe other can help. > > If I execute HTTPSocket httpGet: 'http://www.pharo-project.org/home'. > in a Workspace having a Transcript window open, I got a never-ending > messages in the Transcript window like: > "redirecting to http://www.cmsbox.com/errors/hostnotfound.html". > Yes, I am behind a firewall, but other urls work with the same command. > > >> >> But yes, usually (sometimes it doesn't work) there is a combination >> of keys that send a system interruption. Check this links: >> >> http://wiki.squeak.org/squeak/899 >> http://wiki.squeak.org/squeak/1542 >> > Great! Alt-. works. >> >> BTW Adrian, I think this deserves a FAQ entry as it has been asked >> several times. >> >> Cheers >> >> Mariano >> >>> >>> Thank you, >>> Andrei >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 11, 2010

Re: [Pharo-project] VMs for Pharo 1.1

by Mariano Martinez Peck

2010/5/11 John M McIntosh <johnmci(a)smalltalkconsulting.com> > > On 2010-05-10, at 11:16 PM, laurent laffont wrote: > > >> Mac: John, I am not sure which VM we should use for Pharo 1.1. Can you >> give us a hint ? known problems ? does it include freetype ? > > > > Let me build and upload a 32bit bias macintosh V5.x VM for people to try > later today, since I'd suggest that should be used. > > Thanks John. NO hurry. Just let us know. Torsten and Laurent: thanks for the other links! > > > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2010

[Pharo-project] I would like to kill some tests

by StÃ©phane Ducasse

Hi I would like to kill some tests that do not really make the system better. testMetaclassSuperclass "self run: #testMetaclassSuperclass" self assert: Dictionary class superclass == Set class. self assert: OrderedCollection class superclass == SequenceableCollection class. testSuperclass "self run: #testSuperclass" | s | self assert: Dictionary superclass == Set. self assert: OrderedCollection superclass == SequenceableCollection. s := OrderedCollection new. s add: SequenceableCollection. s add: Collection. s add: Object. s add: ProtoObject. self assert: OrderedCollection allSuperclasses = s. let me know what you think. Stef

May 11, 2010